Wiring a Nordic nRF24L01+ module to a ChipworkX devboard 1.5

NETMF & Gadgeteer
1

I’m trying to connect a nRF24L01+ on a ChipworkX devboard 1.5, but I have some trouble. I’m hoping to find guidance or tips on how to tackle this. Thanks in advance.

So here’s the setup (it’s a mesh network-like environment) :

  • 4 sensor nodes, with nRF24s and ATTiny861 uCs, broadcasting messages at about 5 seconds each
  • 1 master node with an nRF24 and an arduino board
  • 1 master node with a nRF24 and a ChipworkX devboard ()

What I am trying to do is make the TX nodes talk to the ChipworkX SoM; the arduino board was just for testing.

SPI is working just fine, because I can configure and examine the nRF24 registers alright. Addresses and channels are also alright (the same on all boards, and auto-acknowledge is off, since I perform an ACK of my own), and the arduino board is picking all packets sent by the sensor nodes. There should be no range issue either, since the ChipworkX and the arduino are about 20cm from each other and the sensor nodes about 1m away.

The problem is that the nRF24 hooked up to the ChipworkX board raises RX interrupts on what appears to be a random basis, once every 15 to 45 minutes or so, even if the packets are sent over the network at a rate of about one packet every 1 second. The packets it receives are correct.

I have also tried polling the nRF24 at regular intervals, but with no success.

The carrier detect on the nRF24 (CD or RPD) goes to 1 when sensor nodes are transmitting, so I assume the module gets them, but they never make it to the RX queue, and stays on 0 when everything else but the ChipworkX module is powered, so I assume there is no interference.

Well, here it is. Hope someone can help me out, since I have run out ou ideas.

Thanks in advance.

2

Try reversing the bytes in the address on the netmf board. The arduino samples put the address into a long, while the netmf version uses a byte array. I found this made it possible to communicate cross platform.

3

Thanks, but unfortunately, it did not work. At one point I thought there might an issue with addresses, so I used an address like 0x61 0x61 0x61 0x61 0x61, so that it’s the same one if it is read backwards.

Besides, with my current setup, some packets do come through (and are valid at the application level), so I guess the configuration is correct.

4

Are you sure auto ack is off? Multiple listeners with auto ack on on the same channel and address will cause a problem.

Do you have two netmf devices to try communicating between then to see if they can communicate? I have not tried this with 4.2 yet, but I did have it working with 4.1.

5

According to the registers, it should be off; here’s a dump of the registers I get before powering up for RX :

01:01:01 - nRF24L01 :       RF_CH : 115 / 0x73
01:01:01 - nRF24L01 :       EN_AA : 000 / b00000000
01:01:01 - nRF24L01 :      CONFIG : 059 / b00111011
01:01:01 - nRF24L01 :    SETUP_AW : 003 / b00000011
01:01:01 - nRF24L01 :  SETUP_RETR : 003 / 0x03
01:01:01 - nRF24L01 :    RF_SETUP : 015 / b00001111
01:01:01 - nRF24L01 :  OBSERVE_TX : 000 / 0x00
01:01:01 - nRF24L01 :   EN_RXADDR : 001 / b00000001
01:01:01 - nRF24L01 :     TX_ADDR : aaaaa / 0x61 0x61 0x61 0x61 0x61
01:01:01 - nRF24L01 :  RX_ADDR_P0 : aaaaa / 0x61 0x61 0x61 0x61 0x61
01:01:01 - nRF24L01 :    RX_PW_P0 : 032

EN_AA has all the bits set to 0, so there should be no auto ack.

Unfortunately I only have one netmf device (the ChipworkX), but what puzzles me, and it has for about a month or so now, is that the arduino sitting next to the ChipworkX is getting all packets.

In the begining I thought the nRF24 is faulty, even if SPI operations worked, but I once left it running for a longer time by mistake, and finally got some packets through, and they are all valid. Finally I concluded that the module is working and the config is right, but I’m left out of ideas to try.

6

Assuming you are using the standard Arduino library (RF24), I see your problem. It uses a 16-bit CRC, but you have your receiver set up for only a 8-bit CRC.

From RF24.cpp


  // Initialize CRC and request 2-byte (16bit) CRC
  setCRCLength( RF24_CRC_16 ) ;

Your CONFIG register does not have the CRCO bit set

It works sometimes, because the data gets corrupted and matches (but only rarely).

1 Like
7

Thanks, but unfortunately, I’m afraid it’s not that either. Both configs are the same. I already double-checked on that.

Here’s what the arduino is printing on the serial connection at startup; unless I’m blind, they look just the same.

      RF_CH : 115 / 0x73
      EN_AA : 000 / b00000000
     CONFIG : 059 / b00111011
   SETUP_AW : 003 / b00000011
 SETUP_RETR : 003 / 0x03
   RF_SETUP : 015 / b00001111
 OBSERVE_TX : 000 / 0x00
  EN_RXADDR : 001 / b00000001
    TX_ADDR : aaaaa / 0x61 0x61 0x61 0x61 0x61
 RX_ADDR_P0 : aaaaa / 0x61 0x61 0x61 0x61 0x61
   RX_PW_P0 : 032
[UNIT READY]

This is why it’s getting so frustrating… configs are the same, but the nRF24 hooked up to the ChipworkX devboard is not working as it should.

Here’s a couple of other things I tried

  • “shuffling” the nRF24s; when I thought some are faulty, I labelled them all and started switching them; no matter how they were connected, the one on the ChipworkX did not work, even if it previously or afterwards worked on another board
  • changing the channels, randomly
  • changing the addresses, including different widths
  • changing the configuration on CRC, data rate and TX RF power

The nRF24 library on the arduino and the sensor nodes are using modified versions of the standard libraries I could find for the module (from a tutorial on the net); the code on the ChipworkX module was originally one I found on this forum, then I’ve tried my own.

It’s been about a month now since I started, and working on this project now and then, hoping to get it to work. One last resort was to write to this forum and ask for help…

8

You have my full sympathy. I also struggled for a long time with the same trying to get the nRF24L01+ to work on a Cerberus board. No success. Eventually I used an Arduino board. Now I have found at least that these modules work very nicely also on the Medusa Mini. This is perfect for my requirements because it means I can use a $12 with most of my favourite modules and the nRF24L01+. And it uses less power so I can use battery power. If you can do whatever you need to do on a Medusa, then I strongly recommend you rather do that.

9

Well, I wanted to stick to the ChipworkX because I already spent enough on hobbies 8)
I was even planning to get a G400 module, since I think it’s compatible with the devboard.
I’d hate to have to get a new devboard, then port all the code from C#.

I think I’ll give it a rest for a day or so, or until I get a new idea to try…

10

I can sympathize with you. Back in November I almost gave up trying to use it with Panda II. But, after trying everything else I finally figured out the reversed byte order and crc length issues. I would suggest going back to the original libraries and examples. I used ping pair from the standard Arduino library. Since I only have one Arduino and it wasn’t working with my Panda II, but was working with two Panda IIs, I got out my MSP430 Launch Pad. The standard Arduino library wouldn’t work on it, but there is an Energia library for it. Two of them would talk to each other, but not to the Panda or the Arduino. The Energia library worked on the Arduino and its sample worked, so I knew the hardware could do it. I then spent a LOT of time studying the datasheet to better understand the part and played around with different settings to see how they interacted. The Energia library has some inconsistencies and says that auto ack is not available with 250Kbps. It is but you have to adjust some other registers to make it work.

I have a plan for some low cost sensor nodes, probably msp430 based, but they will be talking to a netmf node which will be internet connected. But, I probably won’t get back to that project for a while.

11

Ha ha! You sound like my wife now. :slight_smile:

Hmm this is very interesting. It sounds very similar to the project I’m currently working on. But I’m using ATMEGA328P for the nodes and Arduino Yun for the internet connection.

12

… well … then you know it is :smiley:
Actually, I didn’t want to admit she would say the exact same thing, so I said it first ::slight_smile:

13

I’ve just ordered four of these to tinker with, looking forward to seeing what you find tomorrow or the day after :wink:

14

I sure will post anything useful. I have planned a little “cleanup” today (remove all xBee circuitry and code), so I can start over again with the nRF24.

15

Well, it paid off to take a step back.
As I was clearing an old breadbord I have used for an xBee, I found a large capacitor on the Vcc pin, and I remembered reading a design guideline in the xBee datasheet that said

So I said to myself… it’s a longshot, but why not try it. So I hooked up a 1000 μF to the 3.3V pins on the devboard header through some long wires (it’s all I had at hand).

And to my big surprise, the module started to pick up about 33% of the packets.

So I went forward, and soldered a 470 μF and a 10 nF capacitors directly on pins 1 & 2 of the module (which are Vcc and GND), and everything started working exactly as it should from the beginning.

So there it is : placing a large capacitor on the power supply pins of the nRF24 module solved the problem.

Now the question is (as my analog expertise is practically equal to zero)… why ? The devboard is powered through the USB cable, which should provide a stable enough power supply; furthermore, there is a 3.3V regulator on board.

I will try to get a snapshot of the power line using an oscillosope and post it here.

16

The regulator and/or the USB power is noisy, most likely. The capacitors cleaned it up enough for it to work.

This is called “decoupling”. What you added are considered “decoupling capacitors”.

17

Thanks, but there are still a couple of issues I’d like to understand, if possible, to avoid future glitches (like this one, that almost made me abandon the idea)

  • the other nRFs are powered from other USB ports from the same computer, through a lot longer wires.
  • the other receiving nRF24, hooked to the arduino, is powered just the same.
  • the xBee, while hooked on the ChipworkX devboard, did not seem bothered by this noise.

Thanks in advance for all info.

18

In every single one of those different setups, you’re using a different processor. So that should imply that some processors /systems have different noise rejection or filtering or requirements that have different effects. The (much higher) processor speed of ChipworkX could be influencing this.

19

It seems you have solved the problem but I came across this yesterday. I know nothing about it but I thought I would pass it along in case someone can make use of it. (Maybe it’s already common knowledge for .net mf nRF24 developers.)

nRF24L01 driver for .net mf
http://nrf24l01.codeplex.com/

I found it through this company :
http://www.d6labs.com/index.php/web-store#!/~/product/category=2514189&id=10930772

20

@ skeller : this was indeed the first code I used, but switched to my own very short after

I don’t know these modules; I’ve got my first 4 from www.seeedstudio.co, then I got 100 more from a wholesale distributor at at very good price, which made the purchase of such a quantity worth it. Now if I burn one out while testing, I don’t really care anymore :wink: