I've been looking for an excuse to write a low-latency, Enhanced ShockBurst (ESB), radio protocol that I can reuse when building remote control toys. Although Bluetooth is great for a lot of use cases, working with the Nordic radio's proprietary mode offers additional flexibility -- in this case, this means achieving lower latencies and streaming packets in a UDP-like manner (versus BLE's reliable transport). I recently found an opportunity to scratch this item off my list when the girl agreed that it would be fun to surprise my nephew by turning one of his giant, polystyrene gliders into a proper RC airplane.
Documentation and photos of the build are located here. Additionally, here are some Devzone-appropriate takeaways for those of you that don't enjoy looking at photos of polystyrene as much as I do:
We conducted some informal range testing in the park and worked up to a little over 100 yards line-of-sight without losing control. I'll update this post in the future if I work up the courage to determine the actual maximum range.
Although the nrf_esb module doesn't have its own frequency hopping implementation, it does allow you to change frequencies quite easily. So when you power up my transmitter it reduces its output power and starts broadcasting a packet on a fixed address and frequency. This packet includes the "transmitter channel" and update rate -- each "transmitter channel" specifies a radio address and a list of frequencies to use. When the receiver gets one of these packets it sends an ACK back to the transmitter and the two are now synced. From then on, both transmitter and receiver use a timer to decide when to turn on their radios. After a packet is received (or missed!) both sides move their radio to the next channel in the list and the process is repeated.
So the idea is to set the update rate to higher than what you actually need to maintain control of the receiver -- this provides some redundancy in case a packet is lost. One packet is sent per channel and the channels are spread out across the 2.4GHz band so interference in a particular part of the band probably won't cause consecutive packets to be dropped. You can get as fancy as you want but I find that constantly moving through the channels works really well.
The original ESB lib does not include any frequency hopping algorithm.
Would you elaborate more about how you do frequency hopping ?