Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - ichbinsnur

Pages: [1] 2 3 4
Getting Started / Re: short circuit protection
« on: August 04, 2015, 03:29:36 AM »
On the ouptut terminals (GPIO's) you want to protect.

Getting Started / Re: short circuit protection
« on: August 03, 2015, 10:54:04 PM »
current limiting resistor?

Getting Started / Re: measure 5V and 6V with rfduino
« on: August 03, 2015, 09:26:16 AM »
Well, it depends....

What is the absolute maximum voltage you need to measure and what precision do you need?

If 6v is the ABSOLUTE MAXIMUM a simple 10k/10k resitor voltage devider will do if you double the ADC output value.
But then you loose half of the precision.

Another way will be to use an external ADC capable of higher voltages.

Getting Started / Re: Using the RFDLoader?
« on: August 03, 2015, 07:33:48 AM »
For windows i would try the free VisualStudio express edition from Microsoft.
Eclipse/gcc might also work.

I just don't know if it's worth the effort ....

Getting Started / Re: Using the RFDLoader?
« on: August 03, 2015, 03:08:06 AM »
For windows the port is known as COM10.

Yep, sure ....  :o

Getting Started / Re: Using the RFDLoader?
« on: August 02, 2015, 10:44:36 PM »
The square brackets [] mark optional parameters and the sharp brackets <> mark mandatory parameters.
Both square and sharp brackets are not allowed, and thus have to be left out in the command line string.

like : rfdloader -q -v 10 Test.cpp.hex



Support / Re: SPI Flash
« on: August 01, 2015, 10:55:12 AM »
You're welcome!

Support / Re: SPI Flash
« on: July 28, 2015, 11:39:35 PM »
Maybe have a look at these :

Adafruit SPI Non-Volatile FRAM Breakout - 64Kbit / 8KByte

Adafruit I2C Non-Volatile FRAM Breakout - 256Kbit / 32KByte

Both come with an Arduino compatible Library.

Android / Rfduino and Galaxy S3 File transfer
« on: July 27, 2015, 01:58:22 AM »
Hi all.

I want to enable my data logger based on the RFduino abble to send the logfiles (stored on SD card) to my phone.
I already got it so far, that i can send packets to the phone and receive them correctly (with checksum).

My problem is, that i'm only able to transfer one 20 byte packet correctly during each connection interval.
If i try to send more than 20 bytes (2 or more packets) the Phone recieves only garbage.
It seems the phone does mix up the received data in this case, like as if the next packet is received before
the last one is fully read.
I already tried connection intervals from 50 - 500 ms, all with the same result.

Can anyone point me out how this can be fixed?
I think it should be possible to send at least 3 packets to the phone in one connection interval.

Do i have to delay the sending on RFduino side?
Or may this be an issue on the phone side?

This is how my RFduino test code looks like at the moment :
(i ommitted the handshakeing code via OnReceive cause it already works correctly)

Code: [Select]
void loop()
  if (transferMode == true)
    if (transferACK == true)SendBlock();
    if (transferNACK == true)ResendBlock();

void SendBlock()
  transferACK = false;
  transferNACK = false;
  short cs;
  if (dataFile) {
    cnt = 0;
    memset(&sendBuffer, 0, 120);

    lastFilePosition = dataFile.position();
    while (dataFile.available() && cnt < 116-80) {

      sendBuffer[4+cnt] =;


    memcpy(&sendBuffer[0],&blocks,2); // copy block number to send array
    memcpy(&sendBuffer[2],&cs,2);       // copy chacksum to send array

    // send 6 blocks of data copped to 20 byte portions (this basically works correct, but only with one block at the moment)
    while(!RFduinoBLE.send((char*)&sendBuffer[0], 20));
    while(!RFduinoBLE.send((char*)&sendBuffer[20], 20));
    while(!RFduinoBLE.send((char*)&sendBuffer[40], 20));
    while(!RFduinoBLE.send((char*)&sendBuffer[60], 20));
    while(!RFduinoBLE.send((char*)&sendBuffer[80], 20));
    while(!RFduinoBLE.send((char*)&sendBuffer[100], 20));

    cnt = 0;
    transferACK = true;

  else {
    // if the file isn't open, pop up an error:
    RFduinoBLE_onReceive("AbortTransferFile____________________", 20);





A fully charged 3.7V Lip will have 4.2V peak.
Anyway, the 3,7v nominal voltage are also too high for the Board.

For DC-DC converters have a look here for example :

I would heavily recommend to put a DC/DC converter between battery and Rf Module.
Otherwise the voltage of a full charged battery and the voltage spikes from the switching LED's might instantly kill it!

For USB Programming almost any FTDI like USB/Serial/Logic converter will work.
But make sure to use level shifters or USB/serial modules with 3.3v logic output.

Support / Re: Two GPIO pin toggle at the same time in RFduino
« on: July 22, 2015, 10:52:02 PM »
Hi, i just dug this out from another post here on the forum :

Have a look at wiring_digital.c , it should guide you in the right direction....

For example these will set and clear a pin directly:
NRF_GPIO->OUTSET = (1 << ulPin);
NRF_GPIO->OUTCLR = (1 << ulPin);




Support / Re: Two GPIO pin toggle at the same time in RFduino
« on: July 22, 2015, 12:29:14 AM »
Is it really necessary to toggle both pins at the exact same time?
The delay of 2 digital writes is only a few microseconds.

Here is an example of writing the Port registers directly (from ATMEL based Arduino code), which gives a delay in the nanosecond range.

Code: [Select]
// write digital "high" to pin <pn> on port <prt>
#define DIGIWRITE_H(prt, pn) prt |= (1<<pn)

// write digital "low" to pin <pn> on port <prt>
#define DIGIWRITE_L(prt, pn) prt &= ~(1<<pn)

#define ledPin 1        // Arduino pin number
#define switchPin 2   // Arduino pin number
#define PORT PORTB // Arduino Port Register

  DIGIWRITE_H(PORT, switchPin);

You can also set the bitmask of the whole port register at once, to switch all pins to the desired state
in one write operation.

I didn't try this on the RFduino until now, but i think it should be doable there too.
At least somewhat similar.



Support / Re: Long time critical application
« on: July 21, 2015, 06:49:45 AM »
Nice to hear you got it to work.



Support / Re: Long time critical application
« on: July 21, 2015, 05:45:34 AM »
Okay, sounds interesting.
It might be a solution or workaround to set a higher connection interval range.

Try this with : RFduinoBLE_update_conn_interval(min_ms,max_ms);
Note that max_ms MUST be somewhat bigger than min_ms.
Try min_ms=200/max_ms=300 for example.
Maybe this will help.



Pages: [1] 2 3 4