Blog 7th Sept 2018 – High Frequency Digital Communications (2.4Ghz) In my spare time in the evenings, I've been looking at an embedded system involving two 40Mhz CPU's. I'm using PIC32MX170F256D chips with a max clock rate of 40Mhz. Unlike some of the older 80Mhz 340 PIC32's I've worked with in the past, these newer 170 chips have more consistent and reliable silicon and also better packaging options. One of the really elegant features is a pin-for-pin multiplex system for much of the internal I/O, which permits the software to control which internal I/O signal(s) gets connected to which physical pin(s). If you don't need one of the UARTs for example, instead of tying up an I/O pin pointlessly you can reuse the physical pin for something else. As a result, these chips actually come in a 28 pin DIL package... which is really very rare. Anyway - one of the CPU's is set to measure modestly fast events and then report the relative timing(s) of the events to a 2nd CPU tasked with generating a pretty display and to calculate some basic stats such as the standard deviation, mean and the like. A problem was to figure out a suitable means of communication between the two CPU's, given one unit might be randomly moving around within a couple of yards of the other. 418Mhz transmitters and receivers were considered but two way comms is hard to make work well - and they have very little in the way of comms protocols for data checking and packet sending. IR transceivers were looked at as well, but bandwidth isn't great and their sensitivity to directionality made them very difficult to use.
NRF24L01 Break Out
Over the last couple of years I've seen a number of 2.4Ghz transceiver boards based around the NRF24L01+ chip and usually aimed at the Raspberry or Arduino market. Although there are some restrictions at the high end of the transmission frequency range when these are used in the US, these devices otherwise have a worldwide licence making them particularly attractive for short range comms between digital systems. In early tests at data rates of 2mbs, I could establish reliable comms out to around 30 feet - and it didn't overly matter how many walls or floors lay in between.
Hobby folks generally drive them with aftermarket driver scripts, offloading the problem of having to figure out the nuts and bolts of the chips operation. Thats all fine and good but you'll never really learn much about a chip if that's your approach. Initially I wrote my own C library to implement the small number of commands built into the chip (read/write register, read/write payload etc) in order to assess some very limited tasks such as sending a 4 byte buffer from one chip to another under interrupt control. I found it fairly easy to get them to work... but harder to make the comms robust and reliable so that millions of data packets could be successfully sent even while errors were occurring.

 

After getting around a quarter of the way through my own library I stumbled on a library written by a bunch of bright young things at Cornell university - and with no licence restrictions posted. Their library is incomplete and doesn't provide support for any of the newer ACTIVATE commands (R_RX_PL_WID nor W_ACK_PAYLOAD) which interestingly open the door to all sorts of possibilities with regard to full duplex communications (they are easy commands to add if full duplex is your bag). The library was also configured to use different SPI, control bits and interrupts than I had used in my PIC32MX arrangement... but don't let that put you off - as it is trivial to recode and the library is clear enough to make that process easy. The documentation is frankly awful (considering who wrote it), with typos and a number of very confusing mistakes, but it is adaquate enough to convey the general idea. I ditched the documentation and butchered the library ending up with a pretty reliable NRF24L01 interface in C.

 

If you have a look on fleabay or other sellers you'll find it easy to source break out boards for the NRF24L01 from any of a gazillion different manufacturers (most are Chinese). These generally low cost boards extend the I/O required to drive the chip (usually to an 8 pin berg strip) and provide a basic 2.4Ghz antenna with a decent ground plane. As with all aftermarket kit, the quality can be a little variable - and these boards often do far better if a good sized tantalum capacitor (around 100uF) along with a 0.1uF decoupler are used across the rails. The NRF24L01 supply is 3.3volt, but the inputs are actually 5v tolerant.

 

Hats off to the manufacturer Nordic for a cracking design. It certainly stuck in my mind as a candidate for future projects and so rang a bell as a potential solution for this two CPU comms problem...
The chip is controlled using an SPI bus consisting of six signals. For any engineers unfamiliar, don't worry, the heart of an SPI system only requires three signals given it is simply a shift register arrangement, extending to the outside world (a) the output from the last stage of the register, (b) the input to the first stage and (c) the clock. As the clock runs, whatever had been written in parallel to the shift register, will be serially output on the output pin, while whatever data is presented on the input pin will be shifted into the register at the same time. So n clock pulses later, the output will have sent n bits while n bits (presented on the input) will be sitting ready to read from the shift register. PIC32MX chips usually build in 1 to 4 SPI interfaces and allow variable width SPI (8, 16 or 32 bit) - but for the NRF24L01 32 bit SPI transfers are required. Three other strobes are required... two are outputs from the controlling CPU (inputs to the NRF24L01) and one is an output from the NRF24L01. The first of these is an active low chip select signal (called CSN) which is asserted by the controlling CPU whenever the SPI is being used to read or write data to/from the NRF24L01. The 2nd signal called CE (chip enable) is active high and is used to switch on the transmission / reception sections of the chip. The third and last signal is an output from the NRF24L01 and is used to raise interrupts in the controlling CPU. This signal asserts after data has been transmitted, received or when the maximum number of retries have been exceeded... yep, you read that right. This little chip has a protocol built in that demands an acknowledgement packet after a transmission and it will retry up to 15 times, with a configurable delay between retries if that ACK isn't received..
Cornell University Library
NRF24L01 Development Environment
Experiments started with small packets sent one way only after which code was extended to provide two way comms. A key issue with any comms system (and these chips are no different) is avoiding deadlock. If for example you build a very simple test system, consisting of two CPU's where CPU-A waits until it can transmit and then sends a value to CPU-B which is sitting waiting until data arrives. Once it does, CPU-B does something (ie: increments the data value) and then waits until it can transmit before sending it back. Meanwhile CPU-A has flipped into receive mode and is siting waiting until it receives data. Once it does, the whole process repeats. All well and good, but in tests, I found that if I didn't take advantage of any of the built in auto acknowledgement features, I'd see maybe 5 to 60 transfers before both sides locked up. No great surprise, for if one single transmission gets lost, both CPU's will end up fat dumb and happy waiting for the other to send a data packet... that never arrives. Deadlock...
If a data application requires data accuracy (some don’t) then three strategies help cope with this problem.
  • Take advantage of the enhanced ShockBurstTM feature built into a NRF24L01 chip. ShockBurstTM is a protocol that forces the NRF24L01 chip to wait for an acknowledgement from the far end and not to proceed until after that ACK has been received. The chip will retry a fixed number of times but if it ultimately fails to get that all important ACK, it will report the fact to the caller, which can then deal with the problem.
  • If you're using data packets much larger than around 16 bytes, you should use the larger CRC error checking value the chip allows (2 bytes instead of 1 byte). Cyclic Redundancy Checking is a simple polynomial applied to all bytes in the packet and used to detect corruption. Calculated when the packet is first sent, it is checked at the other end to establish the packet hasn’t changed. The largest number of bytes in a packet is 32 – but note that the chip can cope with variable length packets consisting of any length from 1 to 32 bytes
  • On the controlling CPU, you must not code any function so that it can lock. For example it must not be possible for an imaginary function, lets call it “GetMyData()” to sit forever polling some kind of flag somewhere that confirms if data has been received. The problem with this is that if the flag never asserts, then the GetMyData() function will loop forever. Instead, you need to frame that flag testing operation within an outer loop that monitors how long the process actually takes and forcibly aborts the process if it takes too long.
  • Another issue to consider is timing. The NRF24L01 chips will retry until ACK's are received - so effectively there are two distinct processes going on. The CPU tells the NRF24L01 to do something and then the chip will take time to complete the task. If the process fails due to the need to retry, more time will be required. Imagine you've built a system with two of these devices and where a command can be sent from A to B such that B will respond with some sort of data. Lets say A sends command N which for some reason fails. At that point if A gives up on sending command N and sends command N+1 there is a possibility that the response it will receive will actually be the older response intended for command N - given that the NRF24L01 will have been busily retrying in the background and off course, might succeed. It's a fairly standard overrun problem but it does need some thought during development. In tests on my development systems here I found this fault would occur quite randomly and usually after millions of packets had been successfully exchanged... and it was simply down to the relative timing of the sending of test packets.
 My spare time project is a work in progress, but I have to say I am quite astonished at just how good these little NRF24L01 chips really are. Good job Nordic. Comment | Back to Quick Links...