Spektrum DSM telemetry-inverted field out of range

Spektrum DSM telemetry monitor: out of range / inverted black fields on Devo10 A/B/L/R/F/H vs Bat/RxV

Hello,

wanted to check with you developers about the DSM telemetry monitor behavior in "out of range" (telemetry only) scenarios where e.g the TM1000 does not send back for a short time.

When are you exactly blending over to black fields on Devo10, which means inverted?
- devo10-v4.0.1-fcd0669 (including all DSM Indigos Pull Requests merged into V4.0.1 nightly default)
- devo10-v4.0.1-4b3dc91 (Vlad'vy DSM protocol changes commit to default)
- release 5.0.0 (no DSM protocol changes since 4b3dc91)
- Indigos DSMx protocol / telemetry updates test build v4.0.1-103607a


As it seems not all monitor fields on display are inverted at the same time / always?

There seem to be a view fields like Temp/RPM and Bat, RxV which are inverted individually and are de-coupled from FlightLog fields?

FlightLog fields A/B/L/R and F/H seem to be inverted (black) on Devo10 at the same time.
Whereas I do not hold my hand in fire if maybe the two F/H fields could be inverted or switched back to normal even A/B/L/R are still black/inverted


When flying Blade 4503D/ASW17 + doing ground range tests on devo10-v4.0.1-fcd0669 nightly-build I noticed that I get occasionally some short peeps / telemetry alarms.
Hard to detect in flight. I better should use different alarm sounds.

On the ASW17 F>40 alarm was activated.
On the Blade I am not sure anymore if F>40 was activated in 2015 (probably).
For the moment the Blade heli current telemetry config is only alarm 4 Bat <=10.5V, alarm 5 RxV <=4.30V. So I would have to re-test.


Q: Is there any scenario which you know of which "Bat alarm <=10.5V" alone would maybe trigger a short beep / alarm either in any V4.0.1 nightly build or release 5.0.0?

Q: Have you done any tests for a FrameLosses >40 warning which could trigger a short beep / alarm either for 1-3 alarms or 4-6 alarms?


As you know from time to time (telemetry out of range) there are those jumping numbers / bogus telemetry data in older nightly-builds fcd0669 (have not re-tested with latest 5.0.0, nightly-build V4.0.1-4b3dc91, Indigos latest DSM test-build from 2015).
This also applies to FrameLosses field.
So maybe F>40 alarm could be triggered, even for a short time??


My latest ground test for fcd0669 nightly-build at least shows that even for a "out of range" that the Bat value stays the same and only the field is inverted / black. So no BAT number jumping like FlightLog values.
So theoretically a telemetry alarm <=10.5V should never to happen?! This would only apply if there is some bogus telemetry data like with FlightLog fields (but not for higher V value, only for smaller one).

I have to re-test for release 5.0.0/4b3dc91 and Indigos DSM test-build 103607a with and without F>40 alarm to check for any bogus telemetry data filtering improvements.....


Crash-proof 3mm CF Quad with electronics is still not ready
EPO glider ASW17 better should not crash because of any DSM code changes in nightly build 4b3dc91 / release 5.0.0 like the (maybe / unverified / not re-produced) deadlock scenario described here: www.deviationtx.com/forum/protocol-devel...d-dev-5-0-0-tx-crash

DSMx + telemetry (TM1000) worked quite fine on devo10-v4.0.1-fcd0669 so far for me (without latest DSM code changes) but with above bogus (non-filtered) telemetry out-of-range FlightLog data.

Any comments / experiences?

Best regards

Thomas