The protocol description from FrSky indicates that telemetry values should be grouped in frames. As far as I can see, the only way to break received data into frames, is to look for a frame tail (0x5E), followed by frame head (0x5E) of the next frame.
I'm working on devices that puts out D-series telemetry, and also has the ability to read telemetry data from another device, and forward it to the Rx (chaining). I believe the best way is to receive the complete frame before passing it on, but the above method for detecting frames means there will be a delay (waiting for head of next frame). For GPS data this will be one second.
Currently I know the data ID for the last value in frames, and terminate frames based on this.
I have seen, and run, code that uses head and tail for each value, and can't see that this creates any problems.
Can someone clarify a bit regarding data flow from sensor to Taranis?
Fred
FrSky HUB protocol "Frame"
Re: FrSky HUB protocol "Frame"
0x5E serves as header, separator and tail so I believe you can simply consider any Hub telemetry value to be 0x5E+3 bytes. Everytime you receive a 0x5E you consider that's the start of a value, and your "frame end" is 3 bytes later. If that 0x5E was a tail it doesn't matter, you'll simply receive nothing until the next "header" 0x5E that will simply reset your state machine again.
Whether the data your device puts out needs a tail or not to be understood correctly and whether the actual frame grouping matters needs testing. I know that in our implementation of the hub protocol for the 9x it didn't matter at all, but the Taranis never sees a hub data packet as the RF module converts that to smart port format on the fly, and we have no idea how it does it and what it expects.
Whether the data your device puts out needs a tail or not to be understood correctly and whether the actual frame grouping matters needs testing. I know that in our implementation of the hub protocol for the 9x it didn't matter at all, but the Taranis never sees a hub data packet as the RF module converts that to smart port format on the fly, and we have no idea how it does it and what it expects.
Re: FrSky HUB protocol "Frame"
Thanks. I will try the value-at-a-time reading for the external HUB protocol source and pass them to the RX as frames.
Just realized it would make more sense to sort them by value ID, and enrich the current frame1 type data (where only values for Acceleration, Altitude and Cell voltage is missing). Then see what's best for the rest (GPS related).
The idea is to have Current/Voltage/RPM/Temp1/Temp2 data, joined with FrSky telemetry from MultiWii FC or other sources.
Just realized it would make more sense to sort them by value ID, and enrich the current frame1 type data (where only values for Acceleration, Altitude and Cell voltage is missing). Then see what's best for the rest (GPS related).
The idea is to have Current/Voltage/RPM/Temp1/Temp2 data, joined with FrSky telemetry from MultiWii FC or other sources.
Re: FrSky HUB protocol "Frame"
Just an update:
My final solution to this was to terminate each frame with a 0x0D. The receiver doesn't seem to care when connected directly to it, and the main/multi-purpose sensor can easily detect end of frame and pass it on to the Rx. By adding the same to multiwii, I now can get voltage, current and RPM, together with Acc and GPS data from multiwii.
Fred
My final solution to this was to terminate each frame with a 0x0D. The receiver doesn't seem to care when connected directly to it, and the main/multi-purpose sensor can easily detect end of frame and pass it on to the Rx. By adding the same to multiwii, I now can get voltage, current and RPM, together with Acc and GPS data from multiwii.
Fred