DSM Telemetry support

Hi, sorry my english it's not korrekt,
i am use the Devo 12S with deviation-devo12-v4.0.1-70993a8.dfu.
Ar400x and tm1100
Telemetrie on dsm2 mode work fine
Telemetrie on dsmX mode work not

eraf wrote: Hi, sorry my english it's not korrekt,
i am use the Devo 12S with deviation-devo12-v4.0.1-70993a8.dfu.
Ar400x and tm1100
Telemetrie on dsm2 mode work fine
Telemetrie on dsmX mode work not

Please download again: deviation-devo12-v4.0.1-70993a8.dfu

What's new in deviation-devo12-v4.0.1-70993a8.dfu ?

I checked August nightly and code B2 is used when telemetry = ON. So the exception is A1 (not B2).

Therefore I changed 'B2' option to 'A1'. Responding to confusion about this option, the setting is now only for DSMX when number of channels < 8.

Fixed: Bat + RxV is switched (on Devo10/7e)

Thomas.Heiss wrote: -> previous collected and shown "fades" (e.g A/L) where erased to 0 after connection was re-established

The values displayed are what the rx is transmitting. If the rx moves outside range or is switched off, the display will show the last received values.

If rx is switched off, when it is switched on again, initial (zero) values will be displayed because rx was reset.

If rx is left switched on, and comes back into range (or tx is switched off and back on). The displayed telemetry values will be the same, except holds will be increased by 1.

Of course I did NOT turn off the RX in the test
Just the HF-link with 100uw output power was gone for a short time.

For Spektrum there is even a difference between:
- HF-link signal quality (RX)
- TM1000 telemetry signal quality

How can I test that? What output power is good for this?

On the DX8 display there is a telemetry bar in the upper left corner.
- bar flickering: no perfect TM1000 signal
- fixed displayed bar: good TM1000 signal
- count of elements on the bar: show how good the RX HF-link quality is (e.g only 2 vs full 5 bars); can't remember the max. elements (e.g 5??) of the bar


Of course I agree with your explanation Indigo.
Fades, FrameLosses, Holds...all should be sent from RX FlightLog IF TM1000 signal is not disturbed.
If telemetry signal (TM1000) is, at least RX FlightLog values should be back when telemetry link is back.

Therefore I can not explain why suddenly the RX FlightLog resets fades to 0 when A/L had been counted up before. Numbers there before...suddenly away??? Weird. What might I be doing wrong?

It was a live (always RX on) test with moving the Devo10 about 3-5meters away thru door/wall/stairs.

I will try to make some more tests soon.

Can't explain it to myself at this time.


What is this new telemetry code about wrong / error packet filtering?
Only for the TM1000 case (RX still connected)? TM1000 telemetry re-connect link?

Thomas

I can't explain it either. The tx only displays the values it receives. All I can say is the rx reset those values.

The Spektrum DX8 display of signal strength is interesting, thank you. I will have to experiment with fetching RSSI value and display a signal strength indicator bar.

Thanks for testing and posting your results. I thought I had fixed those things. The results sound more like the old firmware.

vlad_vy wrote: Try to use 'B2' option for DSMX protocol (Telemetry: OFF, ON, B2)

The B2 option is now A1 for reasons explained 4 posts back. If you have been using the B2 option, after upgrading to new version you will need to change that option to ON.

Try to use 'B2' option for DSMX protocol (Telemetry: OFF, ON, B2)

Thanks for support for my problem.
I switch B2 on my devo 12 and i'm happy.
DSM2 and DSMX works fine with TM1100 and AR400x
Thank you on all programmer

Indigo, what was our idea about alarm muting with ENT button in DSM telemetry monitor?
Should it stop the flickering on a field (e.g frameloss) too?
It does NOT (version c0b203a)!

Do you want to let the DSM telemetry monitor continue flicker the alarming fields? If yes, probably it is meant for immediate landing and RX reset?


With my DX8 I had e.g >40 FrameLosses, no holds, so I could continue flight
after stopping the DX8 alarm (clear button).
The FrameLoss alarm sound just re-armed after xx new lost packets were displayed.
I am not sure how Spektrum solved that in the Airware firmware.
Checking again for at least new 40 FrameLoss packets makes no sense.
Not sure what the packetloss limit for a 2nd, 3rd alarm trigger would be the requirement.
For Fades an alarm sound >80 may make no sense, if it is triggered on first test flights. Was always <80 on new DX8 HF modul, new ESCs...Was 255 with bad equipment.
(Some / All?) smaller Spektrum RX seem to have a max of 255 fades anyways.
At least AR6210.

Indigo wrote: Thanks for testing and posting your results. I thought I had fixed those things. The results sound more like the old firmware.

Well it was a short test only...


What I can confirm till now is, that NOT_CONNECTED values still are able to switch to different real numbers. Should be NOT_CONNECTED all the time...

Personally I like your new NOT_CONNECTED value connected concept.
Fields with "0" value, black / inverted on Devo 10.


I was thinking some weeks ago about an alternate packet filtering concept for NOT_CONNECTED. But I was not sure if it is worth the effort...
I am not sure if that matches already in some kind your new code / packet filtering improvements.


My idea:
Store in variables / flag, what flightlog data (fades, rpm, temp sensor, etc.) is NOT_CONNECTED.

Will never be for:
- framelosses
- holds

For AR8000 NOT_CONNECTED is e.g B + R fades.
Only A + L are active.

If FlightLog/TM1000 choose to send new (wrong) fades, we simply filter out previous marked not connected fades. This is because we permanently store and know what fades (A/L/B/R) are active / inactive on 1st RX connect.

This would prevent showing randomly fast-switching TM values for fades B + R depending on distance.

Spektrum 12CH RX can have multiple SATs connected.


However that does not stop showing randomly unreal-values on A + L (AR8000).
>9999 for the previous firmware I tested.

I am not sure if 5-digit numbers even more confuse a user like max 4-digit value 9999 on telemetry range issue.


Probably I need to re-check what FrameLosses + Holds are displayed on TM1000 out-of-range problems.

If that could be tracked down to a concrete number, maybe it would be possible just to temporarily blend out fade A/B/L/R number changes?
I would blend out with "---" + black / inverted fields on Devo 10.


How far is my idea away from your current code?
Did you pickup any parts for your new code filtering?
How did you re-engineer not connected behavior?


Still not sure how I can test
- RX out of range (that would result in >40 FL + 1 hold at least)
- TM telemetry out of range (no hold necessarily)

separately on ground / in room just by changing output TX power 100uw and above (<100mw).

Greetings

Thomas

PS: 200QX DSMx flight testing was fine. No issue with loss of signal and stuff like this (version c0b203a).

Thomas.Heiss wrote: Indigo, what was our idea about alarm muting with ENT button in DSM telemetry monitor?
Should it stop the flickering on a field (e.g frameloss) too?
It does NOT (version c0b203a)!

Do you want to let the DSM telemetry monitor continue flicker the alarming fields? If yes, probably it is meant for immediate landing and RX reset?

When an alarm condition is met: the alarm sounds, the telemetry screen is displayed automatically and the alarm value is made to flicker to get your attention. So you know immediately what the alarm sound is about.

The mute buttons stop the alarm sound but the alarm state continues so the value continues to flicker. I hadn't considered stopping the flicker also, but I tend to agree with that; because if another alarm is triggered you would then have 2 values flicker. The new alarm is for which value? you might glance at the wrong value and not notice the new alarm state.

Any NOT_CONNECTED values should remain so. I did consider filtering the data somehow but found the CYRF6936 detects errors in a received packet and sets a flag. So I just check that flag and if set not process that telemetry packet. So wrong values being displayed should not occur.

To help me work out what might cause the wrong values you see, are you able to give me any more info?
Are they displayed normal or inverted?
Do all values change to wrong at same time?
Or 2 values change to wrong at same time, like 2 values are linked somehow?
Same values display wrong often (data conversion error)?
Only these particular values are affected (eg. fades)?

Did one more test today with 70993a8 flying Blade 200QX. No DSMx range errors / crash.


Thanks for your feedback about flickering.


I guess best is that I will take some videos with 100uw?
- AR8000
- AR600
- AR6210

And then describing in detail what I encounter.
Probably easier to remote diagnose or even get an idea.
I also need to do some new telemetry configuration for warnings.

I guess it's enough complex even WITH visualization?

Maybe I can also capture / demonstrate the sudden loss of information of "last lost fades" (reset to 0) for my test scenarios.

Not sure when I can do that...may take a while.


PS: Is there any way to improve the timer tone / signal / vibrate on Devo10 just like it works on DX8 countdown?
I can open a separate thread.
I would love to see some improvements in one of the latest trunk / nightly build versions once we get DSM monitor running.

Thomas.Heiss wrote: What I can confirm till now is, that NOT_CONNECTED values still are able to switch to different real numbers. Should be NOT_CONNECTED all the time...

A new version is now available (412a):
bitbucket.org/Indigo1/deviation/downloads

What's new:
- More checking of received data error flags to discard bad telemetry packets.
- Telemetry OFF/ON option B2 replaced with A1 and now placed between OFF & ON.
- Telemetry alarm source code update to reduce size.
- Alarm muting with ENT button in telemetry monitor will now also stop the flickering.
- Improved (less random) flickering of alarm value.

EDIT:

Thomas.Heiss wrote: PS: Is there any way to improve the timer tone / signal / vibrate on Devo10 just like it works on DX8 countdown?
I can open a separate thread.
I would love to see some improvements in one of the latest trunk / nightly build versions once we get DSM monitor running.

In Telemetry config the <= is now a sound test button and each telemetry alarm should play a different sound. However, even though each alarm now requests different music to play, currently all requests result in the same music??? I don't know how to fix this.

Indigo wrote: A new version is now available (412a):
bitbucket.org/Indigo1/deviation/downloads

What's new:
- More checking of received data error flags to discard bad telemetry packets.
- Telemetry OFF/ON option B2 replaced with A1 and now placed between OFF & ON.
- Telemetry alarm source code update to reduce size.
- Alarm muting with ENT button in telemetry monitor will now also stop the flickering.
- Improved (less random) flickering of alarm value.

Wouldn't it be a good idea, to put this in the test-builds section on deviationtx, together with the above explanation?

"More checking of received data error flags"
Is this true only for DSM?

Test-builds would be a good place, but the description there contains no formatting, not even carriage returns. A list of changes without carriage returns is messy.

Also, I wish we could have one entry with multiple files attached.

"More checking of received data error flags" is true for both DSM and Devo.

Thank you very much for your reply.
I appreciate this type of "What's new" explanations.
So the testers have an idea what to look for.

Indigo wrote: "More checking of received data error flags" is true for both DSM and Devo.

OK, so it is worth trying with Devo protocol as well.

Is the complete DSM work merged into the team nightlies?

No yet. It must first be approved by another developer.

Pull request has been updated...