So, you want to build your own RC radio system? Long range maybe? Cool, I want to do it too. Since I'm pretty deep in that topic now, I can give you a hint or two. For example, have you thought about a protocol your radio system will implement?

RC link simplified

Or rather should I say: protocols? Why plural? If you want to do a RC link that talks with popular radios like FrSky Taranis on TX side and servos or flight controllers on the RX side, it will have to implement at least 2 different protocols. More likely 3. And if you will want to add telemetry downlink, 4 or even 5...

RC link protocols

But let's keep it simple, and limit to the case when there is no telemetry downlink. Then, we will have to deal with following protocols:

Between radio and TX module

Over here we have a few choices:

  1. PPM is the most popular protocol. It should work with almost every radio on the market (that allows external TX module), but it can be a little bitchy: you have to cound microseconds between signal changes and if you do things in ISR, it can mess up PPM decoding
  2. CRSF is the new protocol introduced by Team Black Sheep together with TBS Crossfire. It is a bidirectional serial protocol. Super fast (one RC frame in less than 3ms) and can also transmit telemetry. Not all radios use it yet. If OpenTX is the choice, then OpenTX 2.1 or never is required. CRSF can also be bitchy when implementing on TX module. It requires 420000bps and AVR ATmega might have problem coping with that. I tried to implement it for Crossbow LRS, but ATmega32u4 at 8MHz was unable to read serial that fast. Maybe I was doing something wrong, who knows. Either way, STM32 will have no problems with CRSF.
  3. S.Bus another serial protocol. Also quite popular, but in OpenTX it comes and goes when dealing with external TX modules. For example, it disappeared in OpenTX 2.2 but will be back in 2.2.1. Crossbow LRS will switch to S.Bus when that OpenTX 2.2.1 will be released

Best choice? CRSF if you can. If not, then PPM.

Between RX and flight controller

Over here, it is, more less, the same case as between radio and TX: PPM, CRSF, S.Bus. But best choice is different. This time it is S.Bus for sure. CRSF would be a nice feature, but only a feature. PPM only for legacy flight controllers that can not spare and UART for serial protocol.

Between TX and RX module

In case of DIY radio link, there is where you can shine! It is up to you. You might want to reuse some "standard protocol" like FrSky D8 or D16, but you are not building your own RC link to reuse air protocol, right? That would make no sense.

When creating you own air protocol, you will have to face a few problems:

  1. Radio bandwitch is limited. Usually very limited. Usually the longer range, the lower speed. And you want to have long range and high speed. Right? Some compromises are required. Either you can send small amounts of data very fast or big chunks of data with lower frequency
  2. Range vs reliability vs speed. Some RF chipsets (like all LoRa compatible) allows you to choose: range or speed. The more range you demand (higher receiver sensitivity) the lower the speed it. The same goes for reliability. The more reliable link will be slower then less reliable one. The fact that you can have a reception at 10km does not mean that in real life conditions radio link will be safe to use at 10km. You have to leave some dB in reserve for special cases. And the more you will leave, the less range you will get. Or less speed. Another choice to make
  3. Number of channels vs channel resolution vs update rate. Single RC channel in full resolution is at least 10 bits. Better make it 11. 16 channels makes 176 bits. Add CRC, address, flags, preamble and you will end up with at least 25 bytes per one RC frame. Send it 50 times per second only for that one thing you will need 1250 bytes per second. But you have to leave some link bandwidth for downlink, synchornization, take legal requirements into consideration (allowed duty cycle) and out of nowhere it turns out that bandwitch radio chipset provides is not enough for what you want
  4. If not 16 channels at 50Hz then maybe 12 channels at 20Hz? Or 16 channels with 8 bits per channel? Or 10 channels at 15Hz with 10 bits for channels 1-4 and 8 bits for the rest and leaving some bandwidth for telemetry downlink? Oh boy... decissions, decissions, decissions....