Is there a way to capture max Telemetry value?

I have purchased a Lemon Rx LM0052, with built-in altimeter and vario. I'm getting the telemetry values on my Tx, but of course glancing down at the Tx to see my current altitude is a recipe for disaster. I'm not especially interested in knowing my altitude as I'm flying, but it would be nice to be able to see the max altitude reached during my flight, after I've landed.

Before I start trying to hack up a forked version of the code, I wanted to be sure that there isn't some established means of capturing the max altitude (this is Vario Altitude, not GPS Altitude and the accompanying Max GPS Altitude. that a GPS Rx would track..) via established mechanisms involving virtual channel sorcery or such.

I'd ideally treat this much as I treat my flight timer - have a switch that starts/stops the tracking of max altitude (much like it currently starts/stops the timer), and another switch that can be used to reset the max altitude before my next launch (just as I reset my timer before each launch). This is on a DLG, FWIW.

Suggestions on what I could possibly do via the standard firmware, before I go down the rabbit hole of trying to hack at a forked copy of the source code? (I'm a software developer in my day job, so I'm somewhat confident that I could probably put together some hacky solution, but I'd rather not, if its avoidable.)

Use the Datalog feature. The script datalog2csv.py (in the repo utils directory) can be used to parse the datalog.bin file.

Thanks - great suggestion for after the flying session, but I'm hoping to be able to see the max altitude (or some approximation thereof...) at the end of each individual flight.

In looking at that parsing util script, it appears that the only altitude value being extracted is GPS altitude, but this Rx is not GPS-capable, so I'm wondering if the non-GPS altitude is even being logged? (if so, it would appear that the current version of the parsing script isn't parsing it out, at least not by any name involving 'alt'. There do appear to be some 'TELEM_*' fields, so maybe it'd be in one of them?)

I'll definitely check out my data log following tonight's flying session, and see if/how that vario-based altitude is being logged.

Thanks!

According to the code the vario sensor reports both altitude and max altitude values. Don't have dsm telemetry to try it, but that sounds like the sensor sends max altitude probably until it's powered off.

The non-common telemetry values are covered by the telem_extra element. Using the emulator to create a capture with only alt and alt.max selected, the values are labeled TELEM_11 and TELEM_12.

Awesome, I'll take a look at that!

Does anyone know if there's a way to mock-up telemetry data for consumption by the emulator?

So, after much arm waving (with glider at end of arm), and numerous trips up and down the stairs at home (now with data logging enabled... Capt. Genius here forgot to actually enable data logging before his evening flying session...), it appears that the LM0052 is sending telemetry for:

Altitude
Vario Altitude
VarioCR1 - VarioCR6

Unfortunately, the Alt-max value is being logged as 65526, which if my ancient recollection of 2's complement is correct, is a integer value of -10 (It also appears that altitude values are representative of a decimal value, so -10 would actually correspond to -1.0 All values logged for this data item are 65526, so I'm assuming that means that this field is not being sent.)

Does anyone know the purpose of having 6 different Vario Climb Rate data fields? They tend to vary by one or two units across the 6 raw CR values, but they're generally trending in the same direction, despite differences between the fields. (This value, displayed directly on the transmitter screen, tends to bounce around a fair bit, just holding the plane in your hand, so it doesn't surprise me that these 6 values would differ a bit, I just don't understand the purpose of having 6 of them...)

Interestingly, the Altitude and Vario Altitude values sometimes differ by a unit or two, so it seems they're both being sent, or that there is enough latency between logging the the same value twice (as the two different log fields) that the actual altitude has changed.

One item of note is that I was getting kicked out of the datalog2csv.py script with a "Cannot handle API version 0x02" error message. The first byte in the DATALOG.BIN file was 02 - I took the liberty of commenting out that check in the python script, and it now runs, and returns what appears to be valid data, but I don't know if that is having any bad effect on the data coming out of that script, or not...

So, it appears that I'm not going to be able to make use of the Alt-max telemetry field, which is a bummer, as that would have been a whole lot easier. It would seem that the next step is playing around with my own fork of the code, just for the sake of seeing if I can implement my own 'Alt-max' tracking on the transmitter, and hopefully show that as a value in one of the boxes on the display, with the ability to reset that value via a switch between flights. (This is where it would be supremely handy to have the ability to feed mocked up telemetry data to the emulator - for the sake of testing out the code to track the max altitude following a switch-based reset of that value. I can probably figure out how to feed some data into the emulator, but if there's a clean, established way to do that, I'd much rather make use of that than to jam it in there in some ugly way, myself.

The version mismatch may cause a problem, but don't recall the script details to say for sure. The last update was to support the change from 12 to 16 channels. Best to either upgrade to the latest nightly (which will generate a version 3 file), or use the previous version of the script (commit e0e868d964455161b5ce5641d485509503dfd84c).

There's no standard way to emulate telemetry data. An example is in fryskyx_cc2500.c.

Does anyone know the purpose of having 6 different Vario Climb Rate data fields? They tend to vary by one or two units across the 6 raw CR values, but they're generally trending in the same direction, despite differences between the fields. (This value, displayed directly on the transmitter screen, tends to bounce around a fair bit, just holding the plane in your hand, so it doesn't surprise me that these 6 values would differ a bit, I just don't understand the purpose of having 6 of them...)

Ah... Failure to adequately RTFM strikes again. This is from the Spektrum XBus Telemetry Spec: ( www.spektrumrc.com/ProdInfo/Files/SPM_Te...Developers_Specs.pdf )

>>
//////////////////////////////////////////////////////////////////
//
// VARIO-S
//
//////////////////////////////////////////////////////////////////
//
typedef struct
{
UINT8 identifier; // Source device = 0x40
UINT8 sID; // Secondary ID
INT16 altitude; // .1m increments
INT16 delta_0250ms, // delta last 250ms, 0.1m/s increments
delta_0500ms, // delta last 500ms, 0.1m/s increments
delta_1000ms, // delta last 1.0 seconds
delta_1500ms, // delta last 1.5 seconds
delta_2000ms, // delta last 2.0 seconds
delta_3000ms; // delta last 3.0 seconds
} STRU_TELE_VARIO_S;
<<

So, the different CR values are deltas over differing periods of time - very cool, as you can then choose the level of sensitivity that you want to alert on. (I'd been using CR1, which is a delta of 1/4 of a second - no wonder it was hopping around all over the place.

Also from the spec:

>>
//////////////////////////////////////////////////////////////////
//
// ALTIMETER
//
//////////////////////////////////////////////////////////////////
//
typedef struct
{
UINT8 identifier;
UINT8 sID; // Secondary ID
INT16 altitude; // .1m increments
INT16 maxAltitude; // .1m increments
} STRU_TELE_ALT;
<<

So, that explains why I'm getting back the 2 separate values for altitude, though I still don't know if that's 2 readings from one sensor, or 2 separate readings from 2 separate sensors.