ImmersionRC Ghost protocol inside Betaflight
ImmersionRC recently pushed out the new product known as Ghost. It is based upon LoRaWAN which gave it some nice advantages in comparison to other existing radios. ImmersionRC also created a new lightweight protocol to improve latency and some new features. This post will be more about how it is integrated into Betaflight code.
At the moment of the writing the code is located here:
If you figure out how this protocol works you can use it in your projects. With Ghost radio transmitter and Ghost receivers, you can communicate with any device you want at a distance of around 10 km with very low latency including telemetry data.
In the text below I'll describe how Ghost's frames look like. We are looking from the receiver's perspective (Betaflight flight controller). I'll divide it into two sections, receiving frame and telemetry frame.
You can see that frame has consisted of a 1-byte address, length, type, variable payload up to 14 bytes, and at the end is 1 byte CRC. This is 18 bytes for full-frame size.
The physical layer used for Ghost is UART with parameters:
- word length is 8 bits (defined in Betaflight UART driver)
- the stop bit is 1
- no parity bit
- baud rate 420000
Knowing that we can calculate [bytes/s] which is 42000.
Now we can calculate the time that is needed for one frame to be sent.
Step 1) is interrupted from UART. It is the process where the bytes of the frames are collected. For each interrupt, one byte will be stored into ghstIncomingFrame. At the process of collecting, the first couple of byte will be collected to determine what is the size of the full-frame. Once when full-frame has been collected the flag for the new available frame will be set and the ghstIncomingFrame will be copied to ghstValidatedFrame.
Step 2) is where the task scheduler will call the next function and where CRC calculation is done. If CRC is ok, and also if the address is for the flight controller (GHST_ADDR_FC) new flag for the validated frame will be set and the process request will be returned to Betaflight code.
Step 3) is the next task in the row. Since the Ghost returned process is required the process function will be called. This is where most operations are done. Depending on the type of the frame different actions are taken. Worth to mention is that Betaflight is expecting 11bit ch1to4 values and so Ghost will send those value in 12bit format but shifted for 1 bit left. This is why the code in figure 5 looks like this.
Finally, step 4) is where raw RC data is provided to Betaflight. The function call is from the same thread as step 3). The raw RC data is calculated from collected channel data inside the ghstChannelData array.
The telemetry frame is sent through UART with the same setup as the receiving frame. The only difference is the baud rate.
Telemetry supports two baud rates :
- slow baud rate - 115200
- fast baud rate - 400000
Figure 6 - Ghost telemetry frame (packet)
The telemetry frame is the same shape as the receiving frame but the payload size could be up to 20 bytes.
The protocol is still under development so check the code if anything changed.