DSM Telemetry support

I couldn't get really much distance with 100uW on DSMx (some meters).

Isn't it the same test db for all Spektrum transmitters like DX6, DX9, DX18, DX10T? Not only DX8/DX7s?
It is protocol dependent?

I don't care how Futaba, Hott, MPX senders do it as the protocols are not used.
I agree with you that FrSky Taranis and FrSky protocol might be different again for output power. Same for other 3rd-party protocols.

I really liked the idea of the introduced test page feature.
It could happen that you forget to put back the model setting to 100mW, once you played around with 100uW/300uW/1mW.
A simple drop down box for output power would be OK with me. But that might confuse others (e.g newbies).

Maybe its best to hardwire the range test page output in the code or a general config screen per protocol?

Different manufacturers use different values for range test, but all the ones I've seen drop the value around 30db. That's what the drop from 100mw to 100uw gets you. I thought about drop-down boxes, and reporting things like the reduction in signal strength or range. I eventually decided that those would just confuse newbies and wouldn't provide any extra information to people who knew what they were doing.

At 100uw, I still get good reception with a 350QX1 at Spektrum's recommended range test distance of 30 paces. On the OrangeRX 610 in the Orion, I only tested it to 20 feet. Which translates to effective ranges of about 900 yards and 600 feet, far further than I'm likely to need them to work.

There was a bitbucket issue that made exactly the point you mention - that you want to be sure you don't leave it in the low power mode. Which is why I added it.

vlad_vy wrote: Indigo, about your last changes, do you think that RX_IRQ_STATUS register will be valid after Force End State?

I would expect that when receive is complete that RX_IRQ_STATUS is correct.

If not complete then error bit might not be set but it doesn't matter, The buffer will be forced empty and the number of bytes read is returned only if data is ok, Parse_Telemetry_Packet() will only get called if receive complete, no error bit set and received byte count = 16.

I would expect the DSM protocol timing is such that the receiving should have completed. If the current receive is not complete, then the faster "we discard data and clean up" the better.

vlad_vy wrote:

vlad_vy wrote: if 'Holds'=255 -> Telemetry Range Warning
if 'A' or 'B' or 'L' or 'R' not equal to its previous value and >=512 (usually =65535) -> Telemetry Range Warning

-> A, B, L, R, F, H -> not valid (must be filtered)

Probably will be worth to filter these values.

Thomas.Heiss wrote:
FlightLog 0xFF / 255 max value
Do the latest pull requests (without protocol changes), which are merged into deviationtx team repository (trunk), have some more code changes / reviews for displaying 0xFF/255 values?
Have you been already working on this Indigo?

As posted before in this thread I had the problem that the Fades A, B, L, R reset to "0" suddenly once "255" had been reached.
The valid max value (fades) for AR6210/AR600 is 255. It went no further on DX8 so it is receiver hardware.
It is fine to display 255 therefore. It is not a bad value (for fades).

AR8000 and probably 9-12CH receivers can go >255 for fades (I tested this on AR8000 on L before).

You must NOT reset or suppress flightlog data 0xFF (at least not for fades).

Is 255 reset to 0 fixed yet?

In my AR8000 + TM1000 video you can see that I successfully tested showing fades value >512 (e.g 2217) on Fades L as well on FrameLosses.


So:

"if 'A' or 'B' or 'L' or 'R' not equal to its previous value and >=512 (usually =65535) -> Telemetry Range Warning"

-> is not correct??!?? I was in range when display showed >512 (so real fades, real FrameLosses).

"F, H > x -> not valid (must be filtered)"

-> i had successfully tested F 859 in my video as a real number (real losses).

So >512 does not apply for FrameLosses too.


Do you guys have an idea why for some received (bogus) telemetry data F and H show (switch to) 0 in the monitor instead of a real number e.g 32767 or 65535?


I think we have to test it a bit more if there is any fixed number applying for F which triggers a real "telemetry range warning".

Thomas.Heiss wrote: FlightLog 0xFF / 255 max value
Do the latest pull requests (without protocol changes), which are merged into deviationtx team repository (trunk), have some more code changes / reviews for displaying 0xFF/255 values?
Have you been already working on this Indigo?

0 and 255 are displayed as a real values. If 255 overflows and becomes 0 again, it must be fault in receiver.
The min/max values in deviation are only used to limit range of telemetry alarm.

Thomas.Heiss wrote: Do you guys have an idea why for some received (bogus) telemetry data F and H show (switch to) 0 in the monitor instead of a real number e.g 32767 or 65535?

Deviation only displays the value it receives. If value is not the special "not connected" value 65535 (-32768) then it is treated as a real value (even if greater than max value, or less than min value), if real value then display "as is".
Currently as a interim measure 32767 is also treated same as special "not connected" value 65535. (I think this can now be removed)

You could always disable advanced GUI editing on the 7E. Or re-disable it, as it wasn't fitting before we switched to the latest toolchain.

I had to do that for the new toggles code as well.

Has anyone reported seeing only 7 channels in their Flight Controller? (instead of the expected

I have the LemonRx DSM2 Satellite on a nano quad, providing Serial input to Cleanflight running on a Naze compatible FC.

The TX is a Devo 12S, running Deviation v4.0.1, model configured as DSM2 / 8 Channels.

There should be an Aux 4 in this section: