Frsky telemetry instances shifted

[55Laurent]

Is there an existing issue for this problem?

• I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

on 2.9 and frsky protocole frskyx2 D16 some telemetry values doesn't work anymore, need to delete and discovered new then telemetry data are back but their instances are shifted by a coef +224.
Strangely, some telemetry from receiver still work even with the shift, but for exemple those from external sensors like gps, esc are affected.

Expected Behavior

no instances number shift

Steps To Reproduce

just making a comparaison of yml files for exemple between 2.8.5 and 2.9 all instances for this protocol are with +224 offset then widget values show wrong datas, if telemetry are used in specials functions or logical switchs they do not work anymore.
I don't know if other protocoles are affected, I check for Hott, it's ok no shift.
This issue seems to be in 2.9 since long time, I can see it already in a nightly sd back-up from 25 april.

Version

2.9.0

Transmitter

Radiomaster TX16S / TX16SMK2

Operating System (OS)

Windows

OS Version

Win10

Anything else?

No response

[raphaelcoeffic]

Some things have indeed changed for FrSky S.PORT sensors. In 2.8.x, we had a strange situation where internal and external modules were using the same "instance ID", and would thus overwrite each other.

Normally, the instance ID is formed as such:

bit 6-7	bit 5	bit 0-5
Receiver ID	Module ID	Physical ID

In 2.8.x, Receiver ID and Module ID bits were all set (binary 1s) for D16 module sensors, but they were set properly for ACCESS sensors.

Now we have Receiver ID always 0 for D16 (only 1 receiver per module) and Module ID set to 0 (internal module) or 1 (external module).

If you don't want to re-discover your sensors, you could simply use "Ignore Instance ID", so that the 3 MSB (bits 5 to 7) would not be used to match the sensor.

What looks like a "shift" is actually the receiver & module ID set properly.

Let's looks at how a random sensor used to form its instance ID:

240 = 1111 0000

Now we have (internal module):

16 = 0001 0000

Or (external module):

48 = 0011 0000

Please that if using a internal MPM, and either an external MPM or XJT, you could have the same D16 sensors multiple times, with the Instance ID being the only difference. This was previously not possible in 2.8.x, but it now.

[55Laurent]

ok, many thanks for those explanations, I think I understood ;o) . I will try to test your proposal to ignore instance ID, but I need to find a previous 2.9 back-up, because on my sd I already made the changes with new discover, screen setting, and spe functions updated. And I'll try to explain that on rcgroup forums. Is there somewhere else an explanation that I can advice to other? It seems that several people are looking about a solution, not only on rcgroup, but also on facebook

[Arvycka]

Turning "Ignore Instances" ON makes telemetry work again without the need to re-discover.
Re-discovered sensors ("Ignore Instances"- OFF) do not work with INAV Telemetry widget (or possibly other LUA widgets too).

[raphaelcoeffic]

@Arvycka thx for testing. Regarding the iNAV widget, I'm quite puzzled as the code retrieves the sensor ID by name and then uses only the ID, which addresses a sensor directly (should work even with re-discovered sensors).

@stronnag Any idea why that would matter?

[Arvycka]

So the widget is fine after all - it needs to be deleted and added again after re-discovering sensors. then it works as usual. So all of this is only a problem for "old" models when upgrading from v2.8 ant not an issue when creating new models.

[raphaelcoeffic]

Is there somewhere else an explanation that I can advice to other?

@55Laurent you mean apart from this very issue? I don't think so. It seems that's something we should have documented in the release notes somehow.

[Arvycka]

@Arvycka thx for testing. Regarding the iNAV widget, I'm quite puzzled as the code retrieves the sensor ID by name and then uses only the ID, which addresses a sensor directly (should work even with re-discovered sensors).

@stronnag Any idea why that would matter?

I will test more later. Maybe the widget needs to be re-added. But it only shows 1 or 2 sensors after simple re-discovery.

[stronnag]

@stronnag Any idea why that would matter?

No. For the record, D16 on MPM, after installing 2.9 over 2.8.x:

• Without Ignore Instances very few sensors shown (on the sensors page)
• After selecting Ignore Instances , all the usual sensors shown, and active in the INAV widget.

The INAV widget has done nothing in this area for as long as I can remember (at least from ETX 2.5).

[55Laurent]

I checked with an old sd back-up (2.8), ignore instances ID, solve the issue on Frsky.
I cann't check for Inav because I don't have any old version prior to 2.9.
Should I closed this issue?

[raphaelcoeffic]

Should I closed this issue?

I'll move it to the Q&A.