Hi,
two way frsky telemetry has been supported by OpenTX since version 2.2, but ardupilot’s frsky telemetry library did never leverage such functionality.
After working on a new packet scheduler proposal for the frsky passtrough library I gained enough confidence with the code to give it a shot myself.
For a brief introduction on how frsky sport telemetry works please refer to the post linked above.
In designing the two way telemetry protocol I looked at two well established and documented working examples:
- betaflight msp
- mavlink
The former is a very good example of a complete lua stack, the latter is the “right” way to interoperate with the ardupilot system.
First goal was to design a protocol on top of sport that could transfer a generic mavlink style container with a variable length payload.
Sport packets have a payload of 6 bytes (by using frame id 0x32) so the new protocol would transfer messages in chunks of 6 bytes.
I added to the passtrough library an sport packet decoder to parse incoming bytes read from the serial port, every time a full 6 packet is received it is checked against it’s crc and if the packet’s sensor id matches the configured uplink sensor id it is passed to the next layer: the rx message parser.
The rx message parser verifies the packet sequence and builds the paylod, packet after packet.
When a complete message is found it’s passed to the message handler which processes the message according to the message id.
Outgoing messages follow a similar path, the tx message parser chunks the message in 6 bytes packets which are sent down the sport bus.
On the receiving lua side an rx parser applies the same logic to build a message from sport packets. A message handler then processes them by message id.
Once I had bidirectional variable length messages working I decided that the parameters microservice was a good candidate for a first implementation.
I implemented a light version of messages 20,22 and 23.
These messages have a variable length string up to 16 bytes for the parameter name and a float for the parameter value.
Handling floats in lua turned out to be harder than I tought since lua 5.2 does not have an IEEE 754 float packer/unpacker so I ended up writing my own in pure lua.
I also wrote a lua library and script to read/write the parameters from an OpenTX radio, I used an Horus X10 for the prototypes but the library works just fine on a Taranis.
I created frame specific tuning pages
The whole system has been bench tested on a Pixhawk1 but with the help of @marco3dr it will be soon “flight” tested.
Right now the link speed is pretty low, both the script and the ardupilot library process one message at the time, I’m sure that there’s room for improvement
First preview of the code is here, kind of rough but it’s working