Decode raw smartport CRSF telemetry

[stronnag]

Decode raw smartport CRSF telemetry

[stronnag]

Do you have a format definition for the log file (i.e. is it just the raw CRSF or does it have some timing information and / or packet size like the mwp raw logs do (formats link)

An example would help.

[marianomd]

Hi, thanks for the prompt response!

Here is the file. It doesn't have headers.

crsf.zip

[stronnag]

[stronnag]

using the now documented mwp-log-replay into mwp.

[stronnag]

Note that the time is arbitrary as there is no temporal meta-data.

• There are multiple flights in the log (this is the 2nd)
• There's some junk positions in the first flight).

And I'm really not minded to add CRSF/Sport etc etc to the bbl2kml suite, but maybe mwp could be persuaded to write out an OTX format CSV as it already knows how to do the protocol decoding (and bbl2kml suite knows about OTX CSV).

[stronnag]

FYI, from mwp's standalone crsfparser (development branch, corruption in your file revealed the need for some more validation).
crsf-decoded.tar.gz

[marianomd]

Thanks for your time Jonathan! The lack of timing information renders these logs almost useless. Now I get why the android app doesn't have a play button. Anyway, I'll explore the replay and crsfparser tools.

[stronnag]

I might be persuaded to add a CSV (OTX compatible) output to mwp's crsfparser which is standalone (and OS portable).
OTOH, CrazyDude to welcome to reuse mwp's documented raw log (which gives interoperability with a lot of mwptools) or propose a documented alternative which I would at least consider. "Documented" being the key word.

Note that mwp's crsfparser will parse both unstructured raw data (as your log) and the structured mwp raw logs.

[marianomd]

CRSF to OTX CSV functionality is exactly what we need, but, if done on the android app, we could inject the missing timing information (receive time). Do you have some pointer to the CSV format?

I've been looking at the android code, and it already parses the CRSF and handles each type of telemetry event, so it would be relatively simple to implement I think, adding a class that listens to these events and outputs the CSV.

[stronnag]

CRSF to OTX CSV functionality is exactly what we need, but, if done on the android app, we could inject the missing timing information (receive time). Do you have some pointer to the CSV format?

It really depends what you want to use it for. If you use the OpenTX / EdgeTX format then you have access to many extant OTX/ETX analysis tools (including flightlog2kml and other bbl2kml tools). The downside is that you're using OTX "sensor" packing for all fields. For example, GPS parameters are encoded into "Tmp2".

The flightlog2kml code in otxreader.go shows the fields flightlog2kml requires. Note some data extraction is duplicated; Smartport and CRSF encode some data differently (e.g. RSSI. Flight Mode, VBat).

I've attached an example OTX CSV; please note:

• This was from Smartport, not CRSF
• The locations have been adjusted to protect the guilty (it is not my log).

otx-test-log.csv.gz

The following items are the OTX headers from a ELRSv3 EdgeTX CSV log, the actual items are version dependent; a V2 log has fewer items.

Note also that the units are required.

Date         Time           1RSS(dB)   2RSS(dB)   RQly(%)   RSNR(dB)   ANT   RFMD   TPWR(mW)   TRSS(dB)   TQly(%)   TSNR(dB)   Ptch(rad)   Roll(rad)   Yaw(rad)   FM     VSpd(m/s)   GPS   GSpd(m/s)   Hdg(°)   Alt(m)   Sats   RxBt(V)   Curr(A)   Capa(mAh)   Bat%(%)   Rud   Ele   Thr     Ail   S1     6P      S2    EX1     EX2     EX3     EX4     LS    RS    SA   SB   SC   SD   SE   SF   SG   SH   SI   SJ   LSW                  CH1(us)   CH2(us)   CH3(us)   CH4(us)   CH5(us)   CH6(us)   CH7(us)   CH8(us)   CH9(us)   CH10(us)   CH11(us)   CH12(us)   CH13(us)   CH14(us)   CH15(us)   CH16(us)   CH17(us)   CH18(us)   CH19(us)   CH20(us)   CH21(us)   CH22(us)   CH23(us)   CH24(us)   CH25(us)   CH26(us)   CH27(us)   CH28(us)   CH29(us)   CH30(us)   CH31(us)   CH32(us)   TxBat(V)

Feel free to ask further questions. I'm all in favour of more inter-operable INAV analysis tools.

[marianomd]

Thank you for the thorough explanation! It will be of great help. When I get it done I'll let you know here.

It really depends what you want to use it for.

I want to use this to replay a flight, with a tool like mwp, and I would also like to overlay a nice OSD to HD video (I'm still on analog fpv, very tempted by Walksnail Avatar, but not there yet with the money)

[marianomd]

Hi! I have an initial version of the feature almost ready.

Do you have a recommendation of how often I should output a row to the csv? 100 ms should be good enough? Or too much?

Outputting a line each time I get a value would result in a redundant and large file.

[marianomd]

Already pushed it, I used 200ms for the moment.

RomanLut/android-taranis-smartport-telemetry#40