Reset_telemetry SF generates unwanted "telemetry connected" alert

[RC-SOAR]

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

In ETX 2.10.4, a "Telemetry connected" alert sounds whenever a 'Reset Telemetry' SF is triggered, even though telemetry was not lost. This appears to be new behaviour.

(With DLG's, as it's common to reset the altititude telemetry when hitting the Launch button, and the alert is distracting.)

Expected Behavior

The "Reset telemetry" special function should not trigger a 'Telemetry connected' alert, as in previous versions.

Steps To Reproduce

As above

Version

2.10.4

Transmitter

RadioMaster Zorro

Operating System (OS)

Windows

OS Version

---

Anything else?

No response

[philmoz]

The 'telemetry connected' sound and logic was added in 2.10, it did not exist prior to that.

[3djc]

It is not illogical for this alert to pop up, since the values triggering it are valid (it would trigger the same way alerts in SF). If you want to reset alt, you don't have to reset the full telemetry, you can just reset alt sensor, therefore not triggering other sensors alerts

[RC-SOAR]

If resetting telemetry casues it to be connected, shouldn't there also be a 'telemetry disconnected' alert immediately preceding the reset?
Whatever the logic, the change in behaviour will be annoying to users. Also the 'reset ALT' fix is telemetry dependent which means it cannot be baked into a setup at creation time.

[pagrey]

It is reasonable to assume that a reset means the connection has to be established again. If the sound is distracting telemco.wav can be removed from your radio. Personally I have changed the sounds to telemetry connected, signal lost and signal recovered. You can tweak the setup however you want but as a default setup the current configuration seems fine to me.

[RC-SOAR]

System alerts are fine if they convey useful info, but not for confirming expected behaviour from a user-defined SF. After all, we don't have a 'sound played' alert for PlayTrack. If we're going to have an alert it should be if the reconnection fails, not if it succeeds.

[pagrey]

Reset means just that, telemetry is reset. So you want it a little bit reset but not all the way? Reset has to mean start over as if you are starting from scratch and if you start over from a clean state that means you get a telemetry connected alert.

If you don't want that it is very easy to fix but most people want reset to mean really reset.

For example, arm motor -> reset session -> switch warning. This is expected behavior.

[RC-SOAR]

The first change of state following the special function triggering is a disconnect. So, if we're going to be consistent, we should hear 'telemetry disconnected' followed by 'telemetry connected'.

Alternatively, and what I would favour, is an error alert only if the reconnect fails. Or revert to the old behaviour, so people aren't confused by these alerts.

[pagrey]

I get that you don't like how it works now. The old system had the wrong alert first, telemetry recovered. Everybody had to deal with the wrong alert first, we aren't going back to that just because a few people don't want to make simple changes to work around this issue.

There is no need for a telemetry disconnected, you initiate that action. It always happens and needs no alert although you could add one yourself. When you start telemetry the connected alert isn't always going to happen, it depends on a connection so it provides useful information.

You are trying to carry information over a reset, specifically the connection status. That makes no sense, the telemetry is reset so the telemetry connection status is also reset exactly like the switch warning on the session reset.

[RC-SOAR]

The old system had the wrong alert first, telemetry recovered.

No! A 'reset telemetry' SF did not issue any alert at all. That's the whole point of raising an issue.

DLG pilots using the same template for years are now hearing 'telemetry connected' when launching their models.

[pagrey]

The way the switch warning works makes sense on session reset. It makes sense to have all this stuff work in a similar manner. I'd understand your request if the existing features worked the same way and they obviously don't.

Saying you want it the old way because you don't want to change your templates isn't something I'd consider a valid reason.

The way it works now makes sense, when telemetry resets it needs to connect. You haven't give a reason why this alert isn't valid other than you don't like it. If that's it then it's on users that don't like the alert to turn it off.

Every change impacts people, for quad pilots this is a big plus. For these template users it's a headache but an easy one to fix. I hope at a minimum you understand why the change was made. I'll leave it at that.

[RC-SOAR]

To the devs: the issue is also mentioned in #5214, see comment #5214 (comment)

I use reset telemetry at the start of every flight, triggered at the same time as starting the flight timer so that I can review the min/max values at the end of the flight. Under 2.10.1, this results in a distracting 'Telemetry Connected' call out just as the glider leaves my hand. [...]

[lshems]

Reset means just that, telemetry is reset. So you want it a little bit reset but not all the way? Reset has to mean start over as if you are starting from scratch and if you start over from a clean state that means you get a telemetry connected alert.

I do think people want a partial 'reset', meaning a reinitialisation of all values depending on the start of the telemetry 'session'. There is no need to reset the telemetry 'connection' for that.

You could even argue that theses values, like min and max, are 'reset' at each session 'automatically'.

Just make a new function 'clear telemetry registers' for that.

P.s. Why would you want to reset the telemetry connection? And that shouldn't even reset the min max if you refer to reset as only the connection.

All semantics and lack of definitions in this discussion, and no listening to hear the real issue.

Good luck...

[zsjoska]

I also use DLG and the same template. I've read though this discussion and would like to add some points.

• it is easy to make the change if we think on one model. Considering 3 radios and 6-7 models, to maintain the right telemetry is bigger effort
• telemetry discovery order is not predefined and sometimes I have to re-discover all telemetry sensors
• "Telemetry disconected" and "Telemetry connected" are the first signs of weak signal, I don't really want to hear that when I throw my model, neither when I fly.
• I don't really see the point for a "Reset Telemetry" special function which resets the telemetry connection. If is not meant to be used during fly, there is a shortcut on main screen for that.
• I would use this function to reset the altimeter when the AGL shifts from 0 due to air pressure change, but it is not suitable for that.

[pagrey]

There are three alerts and three real internal conditions in EdgeTX. There used to be two alerts. I think the names are confusing people.

Telemetry connected means there are telemetry packets and telemetryState=TELEMETRY_INIT. After a packet is received and the alert happens telemetryState is set to TELEMETRY_OK so you don't hear the telemetry connected alert again.

Telemetry lost means there are no telemetry packets received and the previous state was TELEMETRY_OK, telemetryState is set to TELEMETRY_KO.

Telemetry recovered means there are telemetry packets received and the previous state was TELEMETRY_KO, telemetryState is set to TELEMETRY_OK.

When you reset the telemetry it sets telemetryState=TELEMETRY_INIT so modules like spektrum know to reset their values. This is also the initial state when you select or reset the session.

Telemetry connected means the TELEMETRY_INIT flag has been set and a packet has been received. If you don't want to know the system has been reset and received a packet then just disable the telemetry connected alert.

People should learn what the alerts mean, they are tied to real internal conditions. Reset actually sets an init condition that is sent to other telemetry modules in EdgeTX.

Maybe there should be a checkbox to ignore the init or telemetry connected alert along with the ignore the telemetry alerts but I think for now if people don't want to hear the alert they should just delete the wav file. Previously, as I mentioned in the beginning, there were only two alerts for transitions between TELEMETRY_OK and TELEMETRY_KO and there was no alert that a reset had been sent out.

[lshems]

Everybody talking nobody listening. Funny to see. Especially things like 'people should learn'...

What is the use of disconnecting and then reconnecting a working link? And if the link is not working, the only difference is getting a telemetry connected or reconnected message.
Resetting the min and max for instance has nothing to do with resetting the link.

Clearly some people are asking to be informed about disconnection and reconnection, and some other people just want to reinitiate the values of the telemetry history like min, max, zero for altimeters, etc.

These are two completely different things. I might not want to loose my min values on voltage while i might want to reset the min and max on altitude at the start of a new flight.

Don't try to make veggies eat meat. Create a menu with choice.

Have fun and just fly!

[pagrey]

It's not that difficult, telemetry connected doesn't mean that anything was disconnected, it's just the first packet received after a reset.

[RC-SOAR]

Then why is the alert needed in the context of a reset SF?

[pagrey]

Because a telemetry reset was called and a valid packet was received after that reset.

The special function reset doesn't just clear registers you care about. It also sends a reset to the code that controls spektrum and crossfire receivers. Everything works, you just don't personally care that those other systems got the reset signal. There is no reason to change around all the code just because you don't care about those other things. Everything works fine, if you don't want one particular telemetry update I think it's on you to delete that sound. What about telemetry recovered, what if that bothers me? What about switch warning or throttle warning? If I'm going to be picky it's kinda on me to take care of it.

[RC-SOAR]

I think I'll bow out of this one.

[pfeerick]

Lets bring this back to the topic somewhat:

In ETX 2.10.4, a "Telemetry connected" alert sounds whenever a 'Reset Telemetry' SF is triggered, even though telemetry was not lost. This appears to be new behaviour.

This is correct. 2.10 will announce telemetry connected on

• power on and telemetry link established
• model switch and telemetry link established
• telemetry reset - whether via SF or via the reset menu option

Previously, on some, if not all of these cases, it would trigger the "telemetry recovered" state.

It does not reset the "link" or "connection"... only the state machine and values on the handset.

If you don't want that notification, the expected resolution at the present time is to simply remove the sound file /SOUNDS/##/SYSTEM/telemco.wav) if you only want the telemetry recovered and telemetry disconnected prompts. Since a telemetry reset is that - it is a reset of the telemetry session.

I do see merit in the reasoning that it should not play the sound since the telemetry link is not actually lost/connected/reconnected, but instead was a session state reset, but don't know if the code can be massaged into being that nuanced, until have time to review it again.

[RC-SOAR]

Okay, thanks for the clarification.