X14 with ext. ELRS Module constant sensor lost

[glipski50]

There have been similar issues #2684 and #3010 from last year.

I am using
TW X14 with Ethos with Ethos 1.5.7
ext. ELRS Modul BetaFPV tx nano with ELRS 2.4.0 RC4
receiver Radiomaster ER8 with ELRS 2.4.0 RC4 with HoTT telemetrie
Sensors YGE LV35T and GPSLogger3
Sensor announcement delay 10s
Logging intervall 100ms

During flights I get constant error messages "Sensor Lost", about every 2-3 minutes. In the logfile it looks like the telemetrie data is written into the wrong column for a short time and some data is 0.

Also after an error message the vario signal that was working fine suddenly has a constant tone. After the flight I could see that in the special function for vario the source was empty although the vario sensor was define before the flight and the vario worked fine until the sensor lost message came up. This behavior is also reproducable.

Using the same setup with the same ext. ELRS module on a TX16s / EdgeTX transmitter everythings work fine and no error messages come up.

[mawzthefinn]

Does it still occur if running ELRS 3.3.2 (I know you will lose the HoTT telemetry).

That it's moving columns makes it look like there's some sort of timing issue in the communications. ETHOS in general is stricter about serial protocol timing and telemetry spec than EdgeTX is.

[glipski50]

Since the sensor lost error message seem to relate to the HoTT sensors I think going back to ELRS 3.3.2 would not make sense. I can try to run 3.4.0 without HoTT telemetrie activated and than, if the sensor lost messsage still occurs, I can go back to 3.3.2. This will take a couple of days.

[glipski50]

@mawzthefinn Any comment on my second point I wrote above. In the special functions the source for the vario tone was defined with the Vario sensor and worked fine until the sensor lost message. After that a continous tone only, no vario tone. After the flight I checked the special function and the source field was empty, the defined source obviously got deleted. How can that happen?

[mawzthefinn]

It looks to me like your sensors might be disappearing in the telemetry stream. So I think the two issues are actually the same one, expressed differently.

[glipski50]

I don‘t thing that sensors get lost in the telemetry stream. Those are standard CRSF packets that are transfered from the module to the handset. As I wrote above EdgeTX has no problems with those CRSF packets, where you mentioned that Ethos is more critical about serial protocol timing.

I am more under the impression that there is a general problem in the communication between RF and Ethos. When you read postings in RCG and the issues here in Github you can find a lot of other issues and reports in relation to sensor lost messages. In #3774 for example I reported recently sensor lost messages using a TW receive with different sensors and even with Frsky sensor of the ESC Neutron II I got sensor lost messages. In the case of third party sensors like Unisense-e I always had the needed AppID defined to avoid conflicts but still got sensor lost messages.

After revisiting a lot of sensor lost reports here to me it looks like my ELRS sensor lost issue above is yet another instance of a general sensor handling problem in Ethos.

[robthomson]

Couple of things to check.

1. Make sure your baud rate has no errors listed next to it. Not all modules can handle higher speeds - as a result you may need to reduce the crsf speed to avoid errors.

2. what telemetry rate is elrs / rx combo using? Its quite possible to get warnings if you are on a low speed update - simply because they did not turn up because the rx is sending them so slow.

I use elrs extensively on ethos and never have telemetry lost issues. but.. if I set the telemetry rate to slow.. then yes. you will get them.

@bsongis it may be worth revisiting the elrs config sometime to put a param in to not trigger if rx on slow update?

[glipski50]

Couple of things to check.

1. Make sure your baud rate has no errors listed next to it. Not all modules can handle higher speeds - as a result you may need to reduce the crsf speed to avoid errors.
2. what telemetry rate is elrs / rx combo using? Its quite possible to get warnings if you are on a low speed update - simply because they did not turn up because the rx is sending them so slow.

I use elrs extensively on ethos and never have telemetry lost issues. but.. if I set the telemetry rate to slow.. then yes. you will get them.

@bsongis it may be worth revisiting the elrs config sometime to put a param in to not trigger if rx on slow update?

Which ELRS and which Ethos version do you use? Also which baud rate and telemetry ratio.

I use
Baud rate 921k (the BetaFPV module works as well with 1.87M)
Telemetry ratio 1:8
ELRS 3.4.0-RC3

[mawzthefinn]

@glipski50 the reason I mentioned timing is specifically because of the Unisens-E issue you noted above. That was due to the Unisens-E firmware not obeying the S.Port timing spec and thus being unable to communicate with any of the newer receivers which can assign S.Port to a channel port (they require strict timing for FBus encapsulation).

OpenTX/EdgeTX play very loose with the telemetry specs, in particular both do not sanity check telemetry data per the spec (not in CRSF or S.Port/FBus). ETHOS does sanity check data. This has been a recurring theme over the development of ETHOS. A sensor/device works in OTX, Doesn't in ETHOS, when investigated it's discovered that it's sending data that's out of bounds for the sensor type it's encapsulated as, or in some other manner it's out of the spec.

Remember, you're using a beta ELRS build here. I'd suspect the HoTT translation in ELRS 3.4-RC3 you are depending on is still a little buggy, in some way that's good enough for OTX/ETX but not for ETHOS which is stricter on spec adherence.

[Thomasa66]

Got Sensor Lost message too, every few minutes even if TX and RX is in the same room. (Could reduce the messages frequency by increasing the telemetry ratio)
Also I receive the Sound-Message RF SIgnal critical from time to time, though TX and RX are in the same room.
(This makes me think some telemtry values jumping around randomly from time to time like seen in the Log-> first post)

(OpenTx 2.3.15)
FrSky QX7 with R9M ACCESS 2019 -> flashed to ELRS 3.4.1 (set to 100mW)
FrSky Receiver R9Slim+ OTA -> flashed to ELRS 3.4.1

[robthomson]

Issue here I think is that ELRS due to its variable telemetry ratio will sometimes not get the message through.

I have always resolved in the past by setting ratio to 1:2 or 1:4

Clearly this is not what others will want to do.

It may be that the long term fix is:

if protocol == crsf {
sensorTimeout = averylongtime
} elseif protocol == sport or protocol == fport {
sensorTimeout = somethingok
}

or maybe.. add a param on the radio to allow the end user to choose their own timeout for sensors?

In the end - this is more an ELRS issue - but I think it could be masked.

[bsongis-frsky]

All sensors have their own timeout in Ethos

[robthomson]

This is true...

I may make a lua to adjust that value across all for elrs

That being said.. it is set at 10s by default.. which should be more than enough

[Thomasa66]

If I would have to guess (without having a plan of the CRSF protocoll) I would try locate the problem near the package checksum,
if there is any. Because the checksum should prevent using a inconsistent data package to feed datas to the wrong variables.
(Just a vage guess.)

[Freshprinc84]

#4107

[glipski50]

The logfile problem above was a problem of Dataexplorer, with Companion logviewer the logfiles shows no problems.

But still with ELRS 3.4.2 I receive sensor lost messages every few minutes. Nothing has changed there.

[robthomson]

There are allot of elrs users not experiencing these issues.

So this points to this being something else that needs to be found as the reason for this.

What telemetry rate are you using?
What module?

Full details may help.

[glipski50]

I am using
X14 Ethos 1.5.9
BetaFPV nano TX (V1) ELRS 3.4.2
or
Vantac nano ELRS ELRS 3.4.2
Radiomaster ER8 ELRS 3.4.2
ESC YGE 35 LVT latest firmware
sm-modellbau GPSLogger3 latest firmware

packet rate 333 Hz telem ratio 1:8
or
packet rate 100 hz telem ratio 1:4

Sensor lost messages in all combinations, sometimes more, sometimes less

Works well with Boxer / EdgeTX which mazw explained above with lose santiy check and timeing of EdgeTX vs more accurate sanity check of Ethos.

Ethos unfortunately does not provide any event logging in case if telemetry lost so finding the causing sensor value is not possible.

For example I also get sensor lost messages when using TWIN / TWR8 and the YGE ESC with a Texy. But this is a different story. Sensor lost seems to be a endless Frsky story, independent of transmission protocol. I hear them since I used my frist X20 and Ethos 1.0.x.