nRF2401 Lessons Learned

Wireless & IoT
1

I have finally made a pair of MiRF’s work. It has been a pain. There are some things that I have learned that might benefit others.

The following comments apply to the MiRF, but I believe they will generally aply to any device using a nRF2401. I am driving them with the AVR ATtiny2313 programmed with GCC.

  1. Timing is critical. Look on Table 19 of the data sheet, and methodically check every timing parameter against the software. The one that caused me problems was the duration of the clock strobe. I used a SetBit() followed by a ClearBit() command to pulse the strobe. I did so because the SF sample code used a similar technique. I failed to take into account the fact that the SF code was running on a PIC. The AVR is faster than the PIC. The AVR executes one instruction per machine cycle. With the internal oscillator at 8MHz, it should take 2 machine cycles or 250 nanoseconds to pulse the clock. The timing parameter for the clock duration is 500 nanoseconds.

When I finally checked the clock duration, I discovered that it was, indeed, 250 ns. I extended it with a delay between the SetBit() and the ClearBit().

Look at the timing diagrams in the datasheet and pay close attention to the device will not work if the timing is off, and it will not give you any indication why(my biggest gripe with it).

  1. The data sheet tells you to clock data in and out at a rate less than 1Mbps. It uses 10kbps as an example rate, but it does not state that this is the best rate or highest rate. I was clocking data in and out at 800 kbps. I cannot say what the highest rate allowable is, but it is way slower than 800kbps. I slowed it to 10kbps and it worked.

  2. The nRF2401 will do very wierd things when the timing is off. I saw it give me false DR1 indications when I was driving it too fast. I also saw mountians of false data on the DATA pin. This too, was caused by attempting to clock data in and out too fast. I would recommend starting with 10kbps. If that is too slow, slowly raise the rate and watch the chip behavior.

  3. I tried using an ATMega 16 as a uC. This is a 5 volt device. I used zeeners to drop the rail voltage to 3.3v for the nRF2401. It did not like this at all. I switched to a ATtiny2313 because it will run fine at 3.3v.

Good Luck, you will need it

Jim Lake

2

jimlake:
I have finally made a pair of MiRF’s work. It has been a pain. There are some things that I have learned that might benefit others.

The following comments apply to the MiRF, but I believe they will generally aply to any device using a nRF2401. I am driving them with the AVR ATtiny2313 programmed with GCC.

  1. Timing is critical. Look on Table 19 of the data sheet, and methodically check every timing parameter against the software. The one that caused me problems was the duration of the clock strobe. I used a SetBit() followed by a ClearBit() command to pulse the strobe. I did so because the SF sample code used a similar technique. I failed to take into account the fact that the SF code was running on a PIC. The AVR is faster than the PIC. The AVR executes one instruction per machine cycle. With the internal oscillator at 8MHz, it should take 2 machine cycles or 250 nanoseconds to pulse the clock. The timing parameter for the clock duration is 500 nanoseconds.

When I finally checked the clock duration, I discovered that it was, indeed, 250 ns. I extended it with a delay between the SetBit() and the ClearBit().

Look at the timing diagrams in the datasheet and pay close attention to the device will not work if the timing is off, and it will not give you any indication why(my biggest gripe with it).

  1. The data sheet tells you to clock data in and out at a rate less than 1Mbps. It uses 10kbps as an example rate, but it does not state that this is the best rate or highest rate. I was clocking data in and out at 800 kbps. I cannot say what the highest rate allowable is, but it is way slower than 800kbps. I slowed it to 10kbps and it worked.

  2. The nRF2401 will do very wierd things when the timing is off. I saw it give me false DR1 indications when I was driving it too fast. I also saw mountians of false data on the DATA pin. This too, was caused by attempting to clock data in and out too fast. I would recommend starting with 10kbps. If that is too slow, slowly raise the rate and watch the chip behavior.

  3. I tried using an ATMega 16 as a uC. This is a 5 volt device. I used zeeners to drop the rail voltage to 3.3v for the nRF2401. It did not like this at all. I switched to a ATtiny2313 because it will run fine at 3.3v.

Good Luck, you will need it

Jim Lake

I’m afraid your experience is quite the opposite of my experience (and my group’s experience). First off, we used both the RF-24G modules, and we reflowed our own boards with our own (quite poor) monopole etched antennas. While it is annoying that the nRF2401a doesn’t give any feedback, you can get around this. For example, using the Direct RX mode is quite handy to test if the device is actually working. You will see the DATA pin (and the CLK if you change the driving pin on the microcontroller to an input) toggle. The CLK pin will toggle at the set rate (1MHz or 256kHz) and the data pin will show random RF received.

Next, we were able to talk consistently (for instance we were streaming audio and voice over our 2401a’s with a sampling rate of 13kHz and 12bit samples) to the nRF2401a at just under 1Mbps. We spent many weeks playing with the nRF2401a and testing the system with both a oscope and a logic analyzer. Your problem may not have be caused by the clock rate but rather an incosistent clock rate. We found that if you interrupted the data transfer (paused, for example, to handle a data sampling interrupt) for more than a clock pulse the nRF would begin acting oddly. I’ll say again, it wasn’t the speed but how accurately you drove it. Any small blip would cause a significant problem. Keep in mind this has a very basic FIFO.

We used an MSP430 with SPI implemented in hardware. This and a few other gadgets on our MSP allowed us to provide a consistent clock sampling data.

I just wanted to point the issue out about clock rate as most of the implementations I have seen (on this website) involved bitbaning the nRF. This method seems to be inefficent as most people have had to communicate with the nRF at a significantly slow data rate.

One other FYI, the throughput limit of the nRF is ~320kbps. We calculated this with all the delays in the datasheets, and then found this to be true. We also confirmed this with nordic engineers.

3

I am glad to hear that you did not have the problems I did. I work alone, and I had no RF experience, so I felt a steep learning curve.

I am still playing with the timing, but I seem to get good clean data. You may very well be right about the clock pulse issue. I need to look back over some of the software revisions.

Do you mind posting your routine for clocking out received data from the DATA pin? I am having a problem where I see no errors on the DATA pin, but lots of errors in the same data in the uC. It works fine in the AVR simulator, but maybe I missed something.

It sounds like I can push the speed up to around 250k and Shockburst at 1Mbps without problems. I will try that.

Thanks for the comments

4

jimlake:
I am glad to hear that you did not have the problems I did. I work alone, and I had no RF experience, so I felt a steep learning curve.

I am still playing with the timing, but I seem to get good clean data. You may very well be right about the clock pulse issue. I need to look back over some of the software revisions.

Do you mind posting your routine for clocking out received data from the DATA pin? I am having a problem where I see no errors on the DATA pin, but lots of errors in the same data in the uC. It works fine in the AVR simulator, but maybe I missed something.

It sounds like I can push the speed up to around 250k and Shockburst at 1Mbps without problems. I will try that.

Thanks for the comments

I would love to post my code, but I don’t know if it’ll help you. We were using an MSP430 that implemented SPI in hardware (so we didn’t have to bit bang it). We just started the SPI interrupt and let it empty out a data buffer.

One other “trick” I remember is we had to phase shift the clock and our data. Look at, if you can, where your rising edges are for your clock and your data. We found that they did not look like the datasheet, so we told the hardware module to phase shift the clock.

5

I also had no problems with higher clock speeds (both 1Mhz and 2MHz ok but I use 1MHz normally). But this is also with hardware SPI (AVR mega 32 and mega 48/88/168). Code is in the AVR Code forum here.

/Lars

6

Lajon:
I also had no problems with higher clock speeds (both 1Mhz and 2MHz ok but I use 1MHz normally). But this is also with hardware SPI (AVR mega 32 and mega 48/88/168). Code is in the AVR Code forum here.

/Lars

From those clock speeds I gather you are using the nRF24L01 and not the nRF2401a.

7

From those clock speeds I gather you are using the nRF24L01 and not the nRF2401a.

No it is the nRF2401 as in the RF-24G module. It would probably not be ok to use close to or over 1 MHz in a product but it worked fine for my experiments (telemetry and remote control).

/Lars

8

When I started this project I intended to go in the SPI direction, but I changed when I saw the SF sample code. I went with the bitbanging mehod because I wanted to get it going and that was a proven way to do it.

Now I am reconsidering that decision. Of course, the ATtiny2313 does not have a SPI, it has a USI, but there is no reason I could not change to a small outline Mega16L, for example, which has all the bells and whistles. It just needs to run on 3.3 volts. I will look on the AVR forum for the code to see how it has been implimented.

9

Really it’s quite a bit easier. The only catch is you can end up in interrupt hell.

10

…change to a small outline Mega16L, for example,

Have a look at the Mega 48/88/168 range, good value and a newer generation than the Mega16. Super easy to switch between them also if you need more memory or a cheaper (less memory) part. They are all 32-TQFP (or 28 PDIP).

/Lars

11

JimLake:

Someone posted this link to the Seattle Robotics club. It has assembly code for a Motorola 'HC12.

http://www.seattlerobotics.org/encoder/ … /index.php

12

Falcon X:

jimlake:
I have finally made a pair of MiRF’s work. It has been a pain. There are some things that I have learned that might benefit others.

The following comments apply to the MiRF, but I believe they will generally aply to any device using a nRF2401. I am driving them with the AVR ATtiny2313 programmed with GCC.

  1. Timing is critical. Look on Table 19 of the data sheet, and methodically check every timing parameter against the software. The one that caused me problems was the duration of the clock strobe. I used a SetBit() followed by a ClearBit() command to pulse the strobe. I did so because the SF sample code used a similar technique. I failed to take into account the fact that the SF code was running on a PIC. The AVR is faster than the PIC. The AVR executes one instruction per machine cycle. With the internal oscillator at 8MHz, it should take 2 machine cycles or 250 nanoseconds to pulse the clock. The timing parameter for the clock duration is 500 nanoseconds.

When I finally checked the clock duration, I discovered that it was, indeed, 250 ns. I extended it with a delay between the SetBit() and the ClearBit().

Look at the timing diagrams in the datasheet and pay close attention to the device will not work if the timing is off, and it will not give you any indication why(my biggest gripe with it).

  1. The data sheet tells you to clock data in and out at a rate less than 1Mbps. It uses 10kbps as an example rate, but it does not state that this is the best rate or highest rate. I was clocking data in and out at 800 kbps. I cannot say what the highest rate allowable is, but it is way slower than 800kbps. I slowed it to 10kbps and it worked.

  2. The nRF2401 will do very wierd things when the timing is off. I saw it give me false DR1 indications when I was driving it too fast. I also saw mountians of false data on the DATA pin. This too, was caused by attempting to clock data in and out too fast. I would recommend starting with 10kbps. If that is too slow, slowly raise the rate and watch the chip behavior.

  3. I tried using an ATMega 16 as a uC. This is a 5 volt device. I used zeeners to drop the rail voltage to 3.3v for the nRF2401. It did not like this at all. I switched to a ATtiny2313 because it will run fine at 3.3v.

Good Luck, you will need it

Jim Lake

I’m afraid your experience is quite the opposite of my experience (and my group’s experience). First off, we used both the RF-24G modules, and we reflowed our own boards with our own (quite poor) monopole etched antennas. While it is annoying that the nRF2401a doesn’t give any feedback, you can get around this. For example, using the Direct RX mode is quite handy to test if the device is actually working. You will see the DATA pin (and the CLK if you change the driving pin on the microcontroller to an input) toggle. The CLK pin will toggle at the set rate (1MHz or 256kHz) and the data pin will show random RF received.

Next, we were able to talk consistently (for instance we were streaming audio and voice over our 2401a’s with a sampling rate of 13kHz and 12bit samples) to the nRF2401a at just under 1Mbps. We spent many weeks playing with the nRF2401a and testing the system with both a oscope and a logic analyzer. Your problem may not have be caused by the clock rate but rather an incosistent clock rate. We found that if you interrupted the data transfer (paused, for example, to handle a data sampling interrupt) for more than a clock pulse the nRF would begin acting oddly. I’ll say again, it wasn’t the speed but how accurately you drove it. Any small blip would cause a significant problem. Keep in mind this has a very basic FIFO.

We used an MSP430 with SPI implemented in hardware. This and a few other gadgets on our MSP allowed us to provide a consistent clock sampling data.

I just wanted to point the issue out about clock rate as most of the implementations I have seen (on this website) involved bitbaning the nRF. This method seems to be inefficent as most people have had to communicate with the nRF at a significantly slow data rate.

One other FYI, the throughput limit of the nRF is ~320kbps. We calculated this with all the delays in the datasheets, and then found this to be true. We also confirmed this with nordic engineers.

How did you connect the SPI between the MSP430 and the nRF2401? Did you use the connections described in the Nordic white paper “Interfacing nRF2401 with SPI”?

Leon

13

Exactly. We just used two 10k resistors pulled off from DATA that went to SOMI and SIMO.

14

I have some questions regarding thruput:

  1. Is 320kbps bits or bytes per sec?

  2. Are you in direct or shockburst mode?

  3. What type of distance are you spanning.

George

15

ggallant:
I have some questions regarding thruput:

  1. Is 320kbps bits or bytes per sec?

  2. Are you in direct or shockburst mode?

  3. What type of distance are you spanning.

George

320 kbits/sec.

Shockburst. While Direct mode has some interesting possibilities, you really need a beefier processor than an MSP.

Max throughput (and accuracy) is always going to be at a small distance. This was at a distance with a max of around 10-15 meters. Not great, but this was using our own etched (and extremely poor) monopole antennas.

16

802.15.4 radios out now such as MaxStream XBee ($20@1) and XBeePro are inexpensive, trivial to interface to (serial port logic level) and have very good range. Esp. the XBeePro which is 60Mw.

There are other vendors for similar modules.

Most of these vendors’ modules have a “transparent serial port extension” mode, where they send serial data wirelessly upon receipt, automatically. So your software just sends to serial port, nothing more. And vice-versa on the other end.

Of course, you can choose to use “AT” commands to address transmissions to whatever destination radio. Or move up to ZigBee meshing as an option.

17

The one drawback, however, is the datarate is not as high correct? I didn’t think the Zigbee standard was designed for large data rates.

18

Correct, while the 802.15.4 radio can sustain 250kbps (over-air bitrate), the Zigbee protocol stack was designed to transmit at 1% duty cycle for sensor readings and such. I don’t know if there’s any reason that it couldn’t transmit more with that protocol

19

Theoretically yes, but to start transmitting at those speeds at 100% duty cycle and with an increased distance you have to sacrfice speed for accuracy. Especially if you are streaming music.

20

Be sure to keep 802.15.4 and ZigBee separate. ZigBee is an optional network layer. It’s not needed for many applications.

With or without ZigBee, 802.15.4 can run 250Kbps all day long constantly an be US FCC legal. Not so with the 300-400 MHz band rules.

The 1% duty cycle you’re thinking of may refer to battery powered end-nodes - to save battery power.