Jumper T8SG Plus + iNav telemetry over AFDHS 2A

Hi All,

I have a flying wing with a Matek F411-WING FC board in it running iNav 2.1. The receiver in the plane is an IA6B and is connected to the Matek FC by IBUS for both servo output and telemetry input (using the resistor + diode IBUS port sharing trick in the iNav documentation). All the extended iNav telemetry comes back to my Turnigy i6s as displays fine.

However, as soon as I bind the same system to my Jumper T8SG Plus running a recent nightly of Deviation 5.0.0, the telemetry appears garbled in the "Telemetry monitor" screen. What I see is that:
1. The standard telemetry value that the IA6B receiver always sends (RX supply voltage) appears stable.
2. The extended telemetry values from iNav are coming though but keep overwriting each other in the telemetry monitor.

There seems to be some problem where Deviation is not able to understand the IBUS sensor IDs reliably and aliases multiple sensor values into the same cell in the Telemetry monitor. For example, these are some of the values that I see cycling through in the telemetry monitor:
Cells 1:
- 12.1V (my lipo voltage - INav sensor 2)
- 0.86V (not sure what this is)
- one or two other values that are too quick to read
Cells 2:
- 151V (first part of my longitude - iNav sensor 15)
- 0.66V
Misc 4:
- 274R
- another value in the range 0-5R
Batt 5:
- 12.1V (my lipo voltage - iNav sensor 2)
- 1.68 V

The documentation for the iNav telemetry is here:
github.com/iNavFlight/inav/blob/master/docs/Telemetry.md

Are there any known bugs in Deviation TX with extended telemetry over AFDHS 2A? Am I doing something obviously wrong?

Please try the telem_flysky test build (57638be) . This adds support for more ibus sensors. It may help. The changes are untested. The user who originally requested them didn't post any results. Code is here .

I can confirm that after installing 57638be the behaviour is different but still very much broken. All the lipo voltages and GPS location fragments I reported above are gone and in its place the Misc 4 cell is flashing between the values 66R and 6801R. Not sure where these numbers are coming from.

If I wanted to get in there and debug this how would I do it? Is ST-LINK + GDB the recommended way? Is there some kind of serial debug log available over the USB that I can printf to?

One of the other devs reports the code for extended telemetry values is not correct, and points to here for something to try. I'm traveling so won't have any update till next week. Maybe you can give it a go.

I've not yet had to hook up an st-link. Build with environment variable TYPE=dev to enable printf out the trainer port, or make a build that sends data out with the serial driver (see FrskyX for example). For telemetry a good strategy is to capture the received data and then develop with an emulator build.

Test build is updated ( e83b2e8 ). This adds support for the "AC" type telemetry frames. But that's not the issue with the changing values that you see

The cycling values I believe are due to the interaction between the INAV ibus_telemetry_type CLI setting and deviation's telemetry handling. Please set the CLI value to 3 or 4 and then check the telemetry display behavior.

According to the INAV telemetry page you linked, the default INAV behavior is to report multiple sensors with the same type but different sensor numbers. This does not match well with deviation telemetry handling, which just supports one sensor of each type (with a few explicit exceptions). Setting the CLI ibus_telmetry_type to 3 or 4 causes INAV to use a different sensor type for each reported value.

That still won't be a complete solution because currently the ibus sensors are being displayed with the frsky telemetry definitions. But there's not a 1-to-1 correspondence. Need to add an ibus telemetry definition to deviation to support all the ibus sensors.

Looking at this again after a break. I can confirm no change in behaviour using ibus_telemetry_type 3 or 4.

I have been playing around in the code to see if I can figure out what is wrong with ibus telemetry.

Quick question about that: I'm developing on MacOSX. When I get the resulting .dfu file the tx doesn't boot if I flash it using dfu-util. It does boot correctly if I flash it using the Java utility DeviationUpload0.9.jar, which is supposed to be largely a Java port of dfu-util. So what is the extra thing that DeviationUpload0.9.jar does that dfu-util does not, and can I get dfu-util to do that extra thing with an appropriately constructed command line?

At the moment I am invoking dfu-util this way:
dfu-util -a 0 -D ts8g_v2_plus.dfu

Update: After a bunch of debugging (I haxored the telemetry monitor screen to show a bunch of new debugging info) I have discovered a problem with the Afdhs 2A handling code in Deviation. Not all of the telemetry packets are been reliably read from the a7105 radio.

I am now working on why and whether it can be fixed.