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:
- The source code for the protocol that I came up with is posted here. It is documented reasonably, has seen a bit of testing, and was well-received by the few people that I've shared it with so far. The basic features are: a simple binding protocol, 5 different "transmitter channels", customizable payloads, transmit rates between 10 and 500 hertz, and channel hopping.
- I chose this nRF52 Sparkfun board because it accepts up to 6V on VIN and its form factor is small enough to be carried by the airplane. The "Hookup Guide" for it explains how to use an nRF5x-DK as an external J-Link programmer. Note that this board does have an LFCLK XTAL installed but it does NOT have the components that are necessary for enabling the nRF52's DCDC converter.
- The Electronic Speed Controller and servos on RC vehicles tend to have a 5V interface. The GPIOs on the nRF52 aren't 5V-tolerant so I recommend using level-converters like this one.
- The form factor of the remote control isn't critical so I used an nRF52840-DK board to take advantage of the nRF52840's +8dBm radio output. The asymmetry between the output power of the transmitter and the nRF52832-based receiver (+4dBm) would be a problem with Bluetooth but is fine here because the receiver does not acknowledge packets after the binding process is completed.
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.