Choosing or desiging an NRF24L01 protocol

If you were going to design an integrated-radio flight controller for a tiny quadcopter from scratch, what protocol would you use?

For cost and availability reasons I'm targeting the NRF24L01 and its workalikes such as the BK2423, since they are multi-source, the steps for on-board integration are fairly well documented, and RFM73 modules are a cheap and featherweight temporary substitute if the RF circuitry proves troublesome to get right.

With all of the experience of reverse engineering and implementing different protocols here, which of the existing NRF24L01+ schemes seems to be the best?

Or alternatively, if starting with a clean sheet of paper, which decisions made by various protocols seem particularly wise or unwise?

I'd like to do something fairly simple and efficient for primary flight controls, with a number of spare channels and flag bits for entertaining features, a mental plan for tunneling extensions such as tweaking a PID value through an option byte, and to potentially ultimately get some telemetry back.

I thought about going with something based in the open source world like crazyflie, but have a strong (if mostly aesthetic) objection to the way they seem to be transmitting floating point encodings. Going with something existing - v2x2, yd717, whatever has the advantage of just being able to implement the receiver for now and fly it with deviation or one of the arduino code bases, but a clean sheet also seems like an opportunity to fix mistakes made in the past... Many of the past year's toy quads used the semi-incompatible XN297, but watching these regularly lose signal at 50 feet or so makes them something I'd like to avoid - though the protocols used with them may not be without lessons (I'd skip the emulation of their unique scrambling though, since interoperability with them is not really a goal)

I guess at a most fundamental level, a lot of the performance of a protocol should come down to the wisdom in how often it hops, and under what criteria - but which bitrate to use also has some interesting tradeoffs - a higher data rate should be more susceptible to channel noise, but also more likely to get a packet through before being stepped on by interference from another agile system...

FDR wrote: I'm also interested in a receiver fw using a nRF24L01 based protocol implemented in deviation.
I only found this H8 mini fw posted here by Fernandez, which implements the Bayang protocol:
github.com/silver13/h8mini-testing

Although you can by jumping through a lot of hoops transmit that with an NRF24L01, it's actually an XN297 protocol. Where the receiver is going to be an NRF24L01+ or something relatively compatible like a BK2423 rather than an XN297, that isn't really a fit. Though the encoding scheme if transmitted in ordinary NRF24L01 fashion could be a possibility.

Edit: nonetheless, taking out the emulation of XN297 oddness from this seems a viable quick-and-dirty solution, in that I have an Arduino + NRF24L01+ transmitter talking to another NRF24L01+ wired to a mockup of my receiver board, receiving data. This approach doesn't really have anything to recommend it, but working as a placeholder isn't a bad thing, until a lasting protocol can be chosen on the technical merits.

Personally, if I ever find the time to get to it, I'm going to throw out all the old protocols and start from scratch. A lot of what's going on in current protocols grew out of the old FM analog radios, and it's not clear how much of them make sense with digital technology. So throw it all out, and just see what works if you use network techniques instead of FM radio techniques.

Instead of sending a fixed-size array of channel values with channel 1 being the first value, channel 2 the second, etc., I'm going to send channel #/value pairs. Header information includes a size, sequence number, simple checksum, and a sequence number being ACKed (the protocol requires an ACK). Packets going back to the TX are symmetric, carrying telemetry information.

The logic in the receiver is straightforward. You get a packet, test the checksum. If it's good, you update all the current channel values that came in it and ACK the packet number. If it's bad, you just discard it. Maybe a NAK as well if you want to trigger an early resend. But until you decide how to handle a NAK in the Tx, there's no point.

The Tx is more complicated. You have to keep track of all the channel values so you can note when they change. You also need to note the first outbound packet number that includes the current value. Outbound packets include all channels that have changed since the most recent ACK'ed packet, but no other channels.

The channel/value pairs are interesting. A naive implementation would be just two fixed-size numbers, giving you hundreds or thousands of channels. A more interesting version would be to create buckets of channels with different sizes. For instance, let the first two bits encode the length of the value: 00 -> 2 bytes of value following the channel number, 01 -> 1 byte value following the channel number, and a leading 1 meaning the remaining 7 bits encode both the channel number and value; say 64 1-bit values or 16 3-bit values. You probably want 16-bit channel 0 to be a different channel than a 1-bit channel 0, but maybe not.

I have no idea how well this would work in practice. The network protocols I've built using this kind of technic all worked great, though. Like I said, at some point I plan on giving it a try, but there are lots of other things to do before then.

One problem is that the network link is usually symmetric - you can rely on ACKs if there is actual transmission from TX to RX. In the radio the TX chip is usually more powerful and while the forward packets can go through the telemetry and ACKs can be missing. But I like the idea to send only actual changes - some channels change so rarely it does not make sense to send them always. On the other hand - some can be so important - throttle hold for instance - that you better send them several times at least for reliability.

I have also some ideas like that, but i am not a good coder.......

Indeed would the future protocol be more of a transparant data link, the protocol basic settings must be selectable on the TX.

So for RC car racing you might want two cannels only, but with very low latency.
For an acro Heli you might decide to send the first 4 channels at higher rates than the 6-8 channel?

Basically the transmitter protocol must have has an unlimited nr of channels, but flexibily configured on the TX how to send your data, indeed it will affect the latency or possibly the range, for high bitrate or low bitrate. Same for the digital switches, this must be just a bit not a channel.

An idea could also to devide the link in "data slots". Which are repeating as frames the tx can fill the slots in a way you want only one channel, or 1-100, then repeat? Same some slots for bits.

It might also be an option to have some option to switch the protocols on the linkto tranparant, therefore enabling configuration of escs, flight controllers from the Tx, etc when not flying.



If you brainstorm more out of the box on aTx itself you could see it as an huge look up table (FPGA like), all the inputs on one side switches, pots, sticks > depending on combination of those stored in a table > there will be generated an out put for the servo throw and digital switches.

The software around should be clever to fill the lookup table inputs/outputs in a clever way.........
But this is all very out of the box and might be impossible, but it would be a system which can make any mixes or what ever en do technically anything you can imagine.....

Since we're discussing custom hardware and software, we can spec hardware that has symmetric range. One of the reasons there NRF24l01 is popular for arduino robotics applications is that it is symmetric that way - at least in their setups.

When I screwed up the LNA enable on a NRF24l01 install, the V222 protocol range went to hell because the acks weren't getting picked up, so I believe that protocol depends on having a reliable handshake. While this strategy won't work for any hardware combination, I think it'll work for a properly configured NRF24l01 receiver.

Nice as it would be, I don't think symmetric range is going to be possible on the tiny quads I'm currently working with. Or let me correct that - there will be symmetric range, but only because the transmitters won't have a PA either (or an LNA). Presumably if flying with a better TX that does, the LNA may slightly offset the aircraft's lack of a PA, but it would probably be more a case of telemetry (or ack) dropout being a warning to get turned around and fly back into range.

The idea of sending channel numbers paired with values at first struck me as wasteful. But now that I think about it, channel data fits oddly into bytes anyway - one probably wants 10 bits of resolution, which is wasteful if sent in two bytes, and ugly if bit packing multiple channels across a smaller number of bytes.

So how about this: The protocol is organized in terms of 16-bit words, or paired bytes. The highest few bits of each word (probably 4 but varies) designate the channel, and the remainder is the value. But the number of bits is variable - say reserve 8 of these 12-bit channels for high precision primary flight controls, while some of the remaining slots could designate a greater number of lower-precision channels. All the way down to at the end, having a range of single-byte flight-control registers that can be "poked" one at a time.
For multi-byte registers the scheme would probably be something like a new value is buffered as it comes in byte by byte and only gets applied if and when all 2, 4, 6 or whatever bytes values are received.

Idea #2 is to just define a packet format byte, and intermix flight control packets with optional packets handling extras. Or, perhaps have the first half of every packet should be primary flight control data, while the latter half can have a format code and then arbitrary payloads. The transmitter would then queue these extra messages and push them through the protocol as 2nd-half hitchikers on the steady stream of flight control packets.

---

In many ways though, what is of most immediate interest is settling on a robust channel hopping scheme. Questions such as what data rate, how many channels to use - and particularly for the receiver, how it should scan channels to attempt to "recapture" a transmitter that it hasn't heard from after several scheduled hops (there are persistent-bind protocols where you can turn the transmitter off and back on again, and keep flying, at least in the fixed-wing case)

I wonder if some form of error correction and/or redundancy might extend range and improve non-symmetrical connections.

Richard96816 wrote: I wonder if some form of error correction and/or redundancy might extend range and improve non-symmetrical connections.

Most receive implementations will use the last valid received data for some short period of time before going to failsafe/shutdown.

This likely gets invoked "all the time" on a chaotically shared band like 2.4 GHz - sometimes the packet gets through and sometimes it doesn't but most failures are too brief for human notice.

Displaying success rate metrics could be interesting though.

The point of sending the channel numbers is to allow you to not send values that haven't changed, so that you can have many (as in hundreds or thousands) of channels yet still have a sane frame length. But at this point, calling them "channels" is a bit silly. If you're only sending changed values, then your proposed format is very much like the one I proposed, just packed better for small values.

If you're not skipping unchanged values, but always sending every channel, then sending the channel number is redundant, and hence wasteful. You can use your bitpacking without that, though. Instead of using the high order bits in your high precision channels for the channel number, use them as values for higher channel number that have less precision. Say eight channels with 10 or 12 bits of value (newer transmitters are using 12 bit DACs on their gimbals, so let's be ready for it), the first four have channels 9-12 in their upper four bits, the next two have channels 13--16 in those bits as 2 bit values, and the last two have channels 17-24 as single bit values. This is similar to what the WLtoys protocols do.

One of the existing protocols probably has a channel hopping scheme that will work fine. Any of them that are legal under current EU regulations is probably a reasonable starting point, but I haven't really looked at those.

mwm wrote: If you're not skipping unchanged values, but always sending every channel, then sending the channel number is redundant, and hence wasteful.

I kind of feel like the 4-6 primary flight control channels should be sent all the time - coming from analog sticks they'll probably have some noise/dither anyway so will only occasional qualify as "unchanged". But yes, I'd send the "register pokes" only when unchanged until acked, and probably the same for the auxiliary channels.

This does blend a little bit towards idea #2, where because the primary flight channels are always sent they don't need numbers (at most a format code for the block, to define what is there in what order). The channel/register numbers can then only be used for those actually being changed.

One of the existing protocols probably has a channel hopping scheme that will work fine. Any of them that are legal under current EU regulations is probably a reasonable starting point, but I haven't really looked at those.

They mostly work, but I don't think they are anywhere near equal. My original intent was to start a discussion about which of the schemes in use (or not yet in use) is best, and why.

I had the same thought : design my own protocol with NRF24L01.
Purpose : make cheap receiver for plane and only NRF24L01 for muticopter. With telemetry.
But... it seems Devo has problem to switch between rx and tx (cause CE pin is always high). It can be done by reseting the nrf24l01, but it is a bit slow

So... i change my mind and go for A7105 : they are harder to find (always backorder on banggood), expensive, but the FlySky IA6B (the B version, not the older one) is a well built receiver : RF shielding, and STM32 processor, 10$. I HOPE they have PA and LNA (for 2 ways communication). But I don't know if the stm32 can be flashed on that receiver (i hope so).

If going that route why not just implement the flysky afhds 2a protocol as used in all new flysky equipments and us that, it seems to be very good?

cheap rx's, long range, diversity antenna, telemetry over a bus, cppm out, up to 14channels.
There is a topic open on it, someone took the dump with logic analyser, on it but it seems it was never catched up.

You are right. I don't even think of it. I planned to analyze this protocol before trying to flash the receiver. But i don't have the time to do it right now (and i need to borrow the transmitter of a friend). I wil need sensor to analyse the telemetry protocol. I'm just afraid i can't transport some data from flight controller