search

iNavFlight / inav

INAV: Navigation-enabled flight control software
https://inavflight.github.io
GNU General Public License v3.0
3.11k stars 1.47k forks source link

Several values in LTM are permanently zero #5057

Closed slowcoder closed 5 years ago

slowcoder commented 5 years ago

Current Behavior

When writing a LTM decoder, I've noticed that several values are constantly zero, even though other telemetry and the configurator sees non-zero values.

Steps to Reproduce

  1. Have an FC with GPS, Crossfire RX and Telemetry radio connected
  2. Configure inav for serial rx (crossfire) on one UART, and LTM on another
  3. Compare data in LTM packets with CRSF telemetry and what configurator sees
  4. Several values are zero

Expected behavior

LTM reports the same thing as CRSF telemetry and configurator

Suggested solution(s)

No idea

Additional context

Some of the values that are zero: Function G, Sats Function S, Battery consumption Function S, RSSI

There might be others. Tried with FC armed and disarmed.

version

INAV/NOBSF722R03 2.2.1 Sep 7 2019 / 20:14:42 (66428cebb)

GCC-7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

issue-label-bot[bot] commented 5 years ago

Issue-Label Bot is automatically applying the label BUG to this issue, with a confidence of 0.95. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

stronnag commented 5 years ago

This is most likely a bug in CRSF (which has well documented bad behaviours using "transparent" serial prior to CRSF firmware at least v3).

Or perhaps it's your decoder.

LTM works perfectly using a reliable serial device (and has since forever), and well tested decoders (mwp, ezgui).

slowcoder commented 5 years ago

Well, a little was due to my decoder. My structs weren't packed properly.

So, I've got sats reporting correctly now. Battery consumption was negative, which was capped to 0. Still getting a solid zero on RSSI though. Is the RSSI supposed to be the RSSI ADC value, or whatever is read from the CRSF RX ?

The CRSF transparent serial bridge isn't perfect, but when the LTM packets checksum matches, I'm fairly sure it's not its fault.

stronnag commented 5 years ago

RSSI is whatever the FC sees as RSSI.

Seems to work as well as it has for the last four years with reliable transport / decoder ... image

digitalentity commented 5 years ago

LTM calls the same getRSSI() function as everything else (MSP, OSD):

https://github.com/iNavFlight/inav/blob/master/src/main/telemetry/ltm.c#L194 https://github.com/iNavFlight/inav/blob/master/src/main/fc/fc_msp.c#L563 https://github.com/iNavFlight/inav/blob/master/src/main/io/osd.c#L523

In MSP and OSD RSSI is known to work properly, so it's related to either your setup (FC doesn't read RSSI properly) or your LTM decoder.

digitalentity commented 5 years ago

What are the setting for rssi_source? It defaults to AUTO (auto-guessing ADC or CHANNEL). CRSF may report it natively (check by setting rssi_source to PROTOCOL) - we never checked if that works. Alternatively you can inject RSSI into some channel (CH16 for example) and set rssi_channel accordingly.

slowcoder commented 5 years ago

Injecting it on a channel and asking iNav to pick it up from there leads to the number being exposed in LTM. Oh well, time to close this issue due to PEBKAC.