fix(telemetry): don't override protocol defined distance and precision definitions

[mha1]

CRSF VSpd is defined with cm/s resolution (PREC2) but after sensor discovery is listed as PREC1 (dm/s).

EdgeTX overrides precision definitions to PREC1 for all distance and speed units if a precision > 1 was defined. If definitions made in the protocol decoder are wrong they should be corrected there but there shouldn't be a general override of protocol decoder settings.

[pfeerick]

@3djc I think this makes sense, no? thus, i.e. for CRSF sensors

https://github.com/EdgeTX/edgetx/blob/main/radio/src/telemetry/crossfire.cpp#L43-L80

the removed block is preventing the sensors themselves to presenting their own default precision.

[3djc]

I think I recall this was added for user confort, as more precision means a bit meaningless audio announcement when you play that value

[mha1]

I think I recall this was added for user confort, as more precision means a bit meaningless audio announcement when you play that value

I just tried this with VSpd on 2.12. Edited VSpd to PREC2 and made sure the sensor deliver 2 active digits after the decimal point. SF Play Value on calls 1 digit after the decimal point. Seems like audio is already taking care of this

[3djc]

Then it it seems ok :)

[mha1]

Then it it seems ok :)

I think we really are ok. TTS for some languages like EN can only output single decimal places because they use .wav files for ".0" to ",9" (167.wav to 176.wav). Other languages like DE restrict numbers to one decimal place.

[pfeerick]

I think I recall this was added for user comfort, as more precision means a bit meaningless audio announcement when you play that value

Yeah, especially as it makes things longer. Given that particular bit of code is 10 years old now, I think if we do have to revisit it, user options would be better (and more doable now).

I just tried this with VSpd on 2.12. Edited VSpd to PREC2 and made sure the sensor deliver 2 active digits after the decimal point. SF Play Value on calls 1 digit after the decimal point. Seems like audio is already taking care of this.

Thanks for checking this, lets see how we go with this for now then.