Range of Spektrum Telemetry Battery Capacity Sensor

[elekSENDER]

Describe the bug I use Spektrum telemetry via a Spektrum TM1000 on a Radiomaster TX16s and on a Horus X10s with an irange4in1 multimodule. The issue is with the battery capacity counting: it starts with 0 up to 127, the next value after 127 is -128 and it counts negative up to 0. This repeats, i can see only values from -128 to 127 in the Radios, so its useless for a mAh-capacity warning. The log of this sensor looks like a sawtooth. The Sensor ID is 3402, "mAh", ratio: 1.0

By the way, the same issue occurs with OTX 2.3.14 on both radios

On my request at MULTI-Module pascallanger told me: "Multi is sending the telemetry data tax to the radio firmware to be decided there. So opentx, edgetx and erskytx are doing the decoding. Therefore if there's an issue on the values, that's where you need to open an issue. Pascal"

To Reproduce easiest way: use a Capacity Sensor SPMA9605 on Spektrum telemetry.

Expected behavior capacity value counting upwards continuously

Screenshots

General information EdgeTX version: 2.6.0: tx16s-338d4d2, x10-338d4d2 Hardware: Radiomaster TX16s, Frsky Horus X10s + irange4in1 Radiomaster intern MPM: 1.3.3.7 Irange4in1: 1.3.3.7

[raphaelcoeffic]

Looks like some 8bit signed integer overflow. However, the values are declared according to spec (see page 14 here). I checked the calculation as well, and it seems correct to me. So I think we need some trace of some sort to see how the packets really look like.

[pfeerick]

I'm hoping the something in the AR637T telemetry will bug out similarly, as I have one of those ;) Otherwise, it will not be fun one :(

[pfeerick]

For reference: opentx/opentx#8896 (two lots of heads are better than one!)

[pfeerick]

@frankiearzu Do you have any thoughts on this one?

[frankiearzu]

@pfeerick: Looking at the code, it is a 16bit integer. What is strange is that the rate of change when it is negative, is much faster (i would expect the same slope on the negative side if it was a negative overflow) with a constant discharge.

Will take a look at the documentation i think there is something more than just data here. Usully computing battery capacity is not that straight forward.. is a combination if instant mhA consumption and bat chemistry, there are tables for that.

With the Spektrum telemetry modifications i did, now we have the hability to capture+log any RAW spektrum telemetry data using a LUA script to a file, then inject packets of that data into the running code to debug/develop locally without the phisical sensor. (thats how im debuging/fixing sensors that i don't have).

@elekSENDER: if we give you a script to capture the RAW data, would you be able to run it for us and send us the data???

[frankiearzu]

Other ticket that i am helping debug is also related to battery capacity and clening up other sensor calculations: #3368

[frankiearzu]

The specs from Spektrum to have them handy. The only mapping mistake that i can see is that the chageUsed should not have decimal places, that should only affect that the value will be displayed divided by 10.. Strange that in the Sensor graph/log is not shoing any decimal place.

typedef struct { UINT8 identifier; // Source device = 0x34 UINT8 sID; // Secondary ID INT16 current_A; // Instantaneous current, 0.1A (0-3276.6A) -- EdgeID 3400 INT16 chargeUsed_A; // Integrated mAh used, 1mAh (0-32.766Ah) -- EdgeID 3402 UINT16 temp_A; // Temperature, 0.1C (0-150C, 0x7FFF indicates not populated) -- EdgeID 3404 INT16 current_B; // Instantaneous current, 0.1A (0-3276.6A) INT16 chargeUsed_B; // Integrated mAh used, 1mAh (0-32.766Ah) UINT16 temp_B; // Temperature, 0.1C (0-150C, 0x7FFF indicates not populated) UINT16 spare; // Not used } STRU_TELE_FP_MAH;

[elekSENDER]

What is strange is that the rate of change when it is negative, is much faster (i would expect the same slope on the negative side if it was a negative overflow) with a constant discharge.

@frankiearzu: Dont worry to much about this, I flew different headspeeds on a heli at this log and this is far away from a constant power consumption. I think the slopes on the negative side are random there.

if we give you a script to capture the RAW data, would you be able to run it for us and send us the data???

Sure, i can try this, maybe i need some support howto use the script.

[frankiearzu]

Did a small change to the processing of the 0x34 data (Dual Flight Pack monitor).

Really could not find any major problem, except that the the value should not have 1 decimal place. Make sure you delete preivous sensors, and discover new.

In 2,9, the sensor is "RB1C" (RX Batt 1 Consumption), RB1A Amps, RB1T Temp.

The fixes here (Other Fixes for ESC values, BEC values, etc): https://github.com/EdgeTX/edgetx/pull/3615

Compiled firmware for TX16S: (NOT FOR FLYING.. JUST TESTING) https://github.com/frankiearzu/DSMTools/blob/main/EdgeTx_Firmware/edgetx_TX16S_2.9.0_DsmTelFix1.bin

[elekSENDER]

Unfortunately there is no change with the capacity issue and I discovered some more.

I did some testing with following components:

• Radiomaster TX16S with above firmware
• Spektrum RX AR9030T + 3 Satellites
• Spektrum Aircraft Telemetry Flight Pack Battery Energy Sensor SPMA9605 + Temperatur Sensor

This Energy Sensor provides to telemetry: RB1A, RB1C, RB1T Previous sensors completely deleted und new discovered.

For displaying reasonable values you have to set in the RADIO the ratio value in sensor settings : RB1A to ratio: 1 RB1C to ratio: 10 RB1T to ratio: 1 Be careful, due to another issue #2665 these ratio values will be displayed in COMPANION 10 times smaller (0,1/1/0,1).

Following issues: RB1A: above 12,8A display change to -12,8A. So e.g. 20A are displayed as -7,2A RB1C: same issue as described at the top: 0 to 127, then -128 till 127 an so on RB1T: show actual value, above 25,6 degree change to 0. So e.g. 30 degree are displayed as 4,4 degree.

screenshot with modified ratio:

The "raw" value data range with ratio 0: RB1A: -3276,8A to 3276,8A RB1C: -32768mAh to 32768mAh RB1T: 0° to 6553,6°

screenshot "raw data":

I hope you can use this information for finding the issues. If you like to, I can provide the logs to you or do some more testing.

[frankiearzu]

Something that is interesting using the "raw" values... according to the documentation, there should not have any negative values, only 0 to 32766 that uses only the lower 15bits.

Documentation: INT16 current_A; // Instantaneous current, 0.1A (0-3276.6A) -- EdgeID 3400 INT16 chargeUsed_A; // Integrated mAh used, 1mAh (0-32.766Ah) -- EdgeID 3402 UINT16 temp_A; // Temperature, 0.1C (0-150C, 0x7FFF indicates not populated) -- EdgeID 3404

For battery A, is with one decimal place, raw 32766 is displayed as 3276.6 For battery C, is with three decimal places, raw 32766 is displayed as 32.766

I am wondering if the problem is in writing the LOG or in Comapanion, and not in the radio telemetry data. Is the logger and companion respecting the decimal places??

For the other issue (#2665).. I did fix the ESC VBEC since it actually needed to be multiplied by 5 to get a decent value. For example, raw was 121, so 121*5=605, that with 2 decimal place is 6.05 that is the correct value. (and matches the Spektrum documentation, and testing with an Spektrum TX).

[elekSENDER]

I am wondering if the problem is in writing the LOG or in Comapanion, and not in the radio telemetry data. Is the logger and companion respecting the decimal places??

I do not think the issue is in the logging or companion, because i can see exactly these values in the live display of the transmitter. Both values: modified by ratio and unmodified (ratio=0).

Something that is interesting using the "raw" values... according to the documentation, there should not have any negative values, only 0 to 32766 that uses only the lower 15bits.

Firstyful i thought this an issue in firmware of the MPM, but pascallanger rejected the issue: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/issues/666

So i don´t know really, but if the data from the MPM is just provided to the EdgeTX so there must be anything wrong in the data processing?

[frankiearzu]

Guys, Some good news towards solving this mistery. Could not find anybody nearby who have the sensor, but i won the bidding for one that was at a good/decent price in Ebay, Expensive little sensor !!

Just checking what else do i need to replicate your setup:

I bought the Flight Pack Battery Energy Sensor SPMA9605. I think i can connect it directly to the AR637T.

With that setup, i can get the current and chargeUsed.
What temperature sensor are you guys using?? SPMA9571??

Im really curious why do we get that negative numbers. Hopefully will solved the problem soon!

Frankie

[elekSENDER]

Hi Frankie,

I bought the Flight Pack Battery Energy Sensor SPMA9605. I think i can connect it directly to the AR637T.

yes, directly to X-BUS.

What temperature sensor are you guys using?? SPMA9571??

yes, exactly this one.

Just for information: I wanted to be sure there are no issues with these sensors and tried the same equipment as described above with a Spektrum DX9. Results in display: no negative numbers, current up to 23A, capacity above 300mAh, temperature up to 75° Celsius.

[frankiearzu]

Finally was able to test with the real sensor. The Spektrum documentation is wrong.

1. Data is encoded in little-endian (documentation said big-endian). Thats why it was changing from negative/positive that often (changine the most significant byte quicker and reach an overflow, each 1mhA was changing x1000).

2. The temperature also was wrong is an "int16" instead of "uint16". The "No data" 0x7FFF is really for signed int16 (used by this sensor). 0xFFFF for unsigned, but was never generated by the sensor.

Looks like the Eagle-Tree manufactured sensors really uses little-endian.

I should have tried to change the little-endian before, but did not ocured to me since the documentation said big-endian.

Give it a try now without using any ratio.. should work right away. https://github.com/frankiearzu/DSMTools/blob/main/EdgeTx_Firmware/edgetx_TX16S_2.9.0_DSMTelFix2.bin

Will work on finding proper names for the sensors, the ones currently used are really for the Receiver batteries, not the Flight pack batteries.. so if someone has the two sensors, it will duplicate.

What i propose for naming is: For RX sensor: RB1A (Amps), RB1C (mAh consumed), RB1T (Battery Temp) For Flight Pack sensor: FB1A (Amps), FB1C (mAh consumed), FB1T (Battery Temp), FB1V (Volts)