Show And Tell: Poly - Building an RC Airplane The Hard Way

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

  • Hello John,

    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.

  • Hi Daniel,

    The original ESB lib does not include any frequency hopping algorithm. Would you elaborate more about how you do frequency hopping ?

    Thanks John