[Feature Request] Generate KML from OpenTX logs

[stronnag]

No description provided.

[stronnag]

I have very few OTX logs and due to weather I'm unlikely to accumulate many at the moment, so contributions of sample logs would be appreciated. Currently, the unfinished implementation seems to work in both FlightMode and RSSI mode for the few logs I have, SBUS and CRSF providers.

[skorokithakis]

Certainly, I can enable logging on my radio and send you some.

[stronnag]

There are some test binaries in the archives below (MacOS, Linux Windows), with a separate otx2kml application (this will probably get merged back into a single BBL/OTX application in the future; for now it's easiest to keep them separate).

There are a few outstanding issues, the first of which need OpenTX 2.3.11 to be resolved:

• CRSF logs in OpenTX 2.3.10 do not record the FM (Flight Mode) field. This makes it impossible to determine flight mode, or even if the craft is armed.
• OpenTX creates a log per calendar day (IIRC), this means there may be multiple logs in the same file. Delimiting these individual logs is less than trivial, to some degree due to the prior CRSF issue which means arm / disarm is not reliably available. Currently, otx2kml assumes that a gap of more than 120 seconds indicates a new flight. This also means a break in telemetry of more than 120s will cause a new KML/Z to be generated. At some stage I'll make this interval configurable. It is of course possible to dream up ever more complex heuristics for this situation, but I'm reluctant to do that, as there will inevitably be some missed corner case, especially as OpenTX 2.3.11 is imminent (and the nightlies are stable / reliable).
• No summary statistics, no current / voltage etc in popups. Work in progress.

Other than that, for the small sample of logs I have, the following is working:

• for S.port logs, Flight Mode and RSSI mode
• for CRSF logs, single (assumed Acro) flight mode and RSSI

Reports of both success and failure are solicited; for failure or errors it would be useful to have the original log (CSV) and an indication of what you think is wrong; corroborating information such as a matching BBL would be a bonus. Please also provide the inav and OpenTX versions if known.

A CRSF 2.3.11 (or recent nightly) log with multiple flight modes, especially nav modes) would be useful too (as would an prior CRSF log before FM got broken).

bbl2kml-0.2.0+otx-pre1-macos.zip
bbl2kml-0.2.0+otx-pre1-win32.zip
bl2kml-0.2.0+otx-pre1-linux-x86_64.tar.gz

[stronnag]

Note that the OTX implementation also suffers from #8 at the moment.

[stronnag]

Thanks to @wilco1967's sample files / testing, here's a new set of binaries which should be functionally correct, albeit still lacking summary functions (i.e addresses #8).

otx2kml-0.2.1+otx_Linux64.tar.gz
otx2kml-0.2.1+otx_MacOS.tar.gz
otx2kml-0.2.1+otx_Win32.zip

[stronnag]

release 0.8.0 / 59015dd should address this feature request, so I'm closing this issue.
The one outstanding question is completeness of support for CRSF sourced logs; this requires a sample CRSF log where the FM field is not consistently "0".