DSM Telemetry support

I guys I just ordered from HK an

OrangeRx R720X 7Ch 2.4 GHz DSM2/DSMX Full Range Receiver w/Sat Diversity Antenna,Failsafe and S.Bus

with a temperature/voltage sensor.

I would like to know which is or should be the best release/nightly of devation to have a solid dsmx link and if it's possible a working telemetry. I have a devo10. Thank you.

P.S. The version that I have on my Devo10 and seems to work fine with my dsmx and dsm2 receivers (no telemetry) is nightly devo10-v4.0.1-9686f9e: there have been some improvements from this firmware to the lastest nightly in dsm2/dsmx? Thank you!

Hi,

I am currently using

deviation-devo10-v4.0.1-fcd0669
offical nightly-build from deviationtx team repository
with DSMx, output power set to 100mw
using Spektrum AR8000 including sat (vertical mounted) + TM1000 telemetry mode
with a Blade 450 3D CP Heli (Paddle CCPM 120 degree mixing).

Rocking stable so far for 6,5-8min flight time.

Fades A (main) < 50
Fades L (Sat) < 80
FrameLosses 0
Holds 0

Nightly version fcd0669 is based on nightly-version 92e1705 (PhracturedBlue repository) for DSMx protocol but with major telemetry bugfixes and improvements.

This nightly version does NOT yet contain the big pending DSM and Walkera protocol changes the team is working on and (still) continually testing.


I will do (repeat) some ground range tests with 100uw/1mw on fcd0669 next days to test for 30-35m and 60-65m distance and compare DSMx FlightLog of this nightly-build vs Indigo test version 36cce5c DSMx protocol changes (e.g maximum of Fades A, handling switching FlightLog numbers, handling FrameLosses/Holds from my previous test of Indigo test version 36cce5c).

Nightly-build version 92e1705 + some telemetry bugfixes has been stable for me with my 200QX quad too.
The telemetry bugfixes and improvements went into the DeviationTX team repository + test builds only.

I have plans to repeat ground + 200QX flight tests at a later time with one of the latest offical test versions the team (Indigo / vlad / PhracturedBlue...) is working on. But I will definitely not use the 450er CP heli for this. May try to reactivate a glider for this.


Changes in CCPM mixing in nightly-build:
You need to be aware that there are two (small) CCPM mixing bugs and lately changes again in the CCPM mixing.

1) Nightly version v4.0.1-fcd0669 suddenly changed normal/reversed for pitch servo (CH6).
I was flying with multiple Indigos test versions (latest devo10-v4.0.1-36cce5c) and nightly-version starting devo10-v4.0.1-92e1705 and for sure pitch servo CH6 had a DIFFERENT sign before.
Suddenly in fcd0669 my CCPM stopped working because pitch servo was travelling wrong.
After I changed the sign normal/reversed it was back working.
Had multiple flights since day 1 and all good.

Not sure why the mixing code (sign normal/reversed for servo channel) suddenly changed between nightly-build versions.

WARNING:
If you upgrade to new nightly-build versions ALWAYS test your servos before flying.
You should do this especially for CP helis anyway, for each new lipo pack you plug into before starting up the engine.


2) CCPM mixing was not working with the simple GUI in nightly build for me.
This is because cyclic channel order is wrong assigned.
I had to remap elevator servo to cyclic channel 1. Has been set to "cyclic 2" by simple GUI configuration.
When you change from simple GUI to advanced GUI you can see that the cyclic channel order is assigned wrong.

Setup:
elevator needs to be cyclic 1 (was cyclic 2)
aileron needs to be cyclic 2 (was cyclic 1)
pitch (CH6) needs to be cyclic 3

I was on a nightly-build Indigo test version devo10-v4.0.1-36cce5c before when the CCPM mixer for paddle CP heli was not working.
If the cyclic channel ordering is interchanged, you will never manage to get the up/down servos right, even not with channel reversing normal/reverted or +- in CCPM mixer.
Will re-test a new CCPM heli modell with nightly-build fcd0669 and simple + advanced GUI screens.

Thomas.Heiss wrote: I am currently using

deviation-devo10-v4.0.1-fcd0669
offical nightly-build from deviationtx team repository - linked in downloads section
with DSMx, 100mw, AR8000 + TM1000
with a 450 CP Heli (Paddle CCPM mixing).

Rocking stable so far for 6,5-8min flight time.

Fades A (main) < 50
Fades L (Sat) < 80
FrameLosses 0
Holds 0

I will do (repeat) some ground range tests with 100uw/1mw next days to test for 30-35m and 60-65m distance.

I have a Devo10. Can I read Fades FrameLosses and Holds ? Where?

With Spektrum RX with Data port + TM1000/TM1100: Transmitter menu / Telemetry monitor

Model menu / Main page config:
- Assign "Menu 1" (at the bottom) to Telemetry monitor and
- Assign "Menu 2" to channel monitor

Unfortunately with LemonRX + OrangeRX this is not going to work (missing FlightLog data port)??!??

I would also fear that the TM1000 sending is not 100% synchronized to receiving with the receiver??!
Not sure about it how that syncronization might work with 3rd party receivers. Will the TM1000 listen for itself? I heard that might work without the DataPort. So its only used to send the FlightLog data to the TM?!?

If you want a digital signal (e.g S-Bus) you better get a Spektrum 9CH receiver with proprietary SRXL protocol support which it known only to work with BeastX Plus (Pro rescue firmware) for know. Spektrum has no support for "normal SRXL" / S-Bus protocol.
Spirit System FBL is known to be working on "Spektrum SRXL" (X-Plus) for a future / next firmware update (according to a thread which I found).


IF FrSky HF-modul might work reliable I would throw away the LemonRX and use FrSky + S-Bus receiver instead as an alternative to 9CH receiver with Spektrum SRXL / X-Plus.

Thomas

Thank You. I'm waiting the orange r720x with built in telemetry. I'll try with that since I don't have any other kind of receiver with telemetry. Thank you.

Thomas.Heiss wrote: With Spektrum RX with Data port + TM1000/TM1100: Transmitter menu / Telemetry monitor

Model menu / Main page config:
- Assign "Menu 1" (at the bottom) to Telemetry monitor and
- Assign "Menu 2" to channel monitor

Unfortunately with LemonRX + OrangeRX this is not going to work (missing FlightLog data port)??!??

I would also fear that the TM1000 sending is not 100% synchronized to receiving with the receiver??!
Not sure about it how that syncronization might work with 3rd party receivers. Will the TM1000 listen for itself? I heard that might work without the DataPort. So its only used to send the FlightLog data to the TM?!?

The TM1000 and TM1100 both work with LemonRx and Orange Rx - and for that matter, Spektrum Rx's - without a data port. You need to plug them into a spare servo port for power.

You can get Rx battery and any other sensors you have plugged into the TM1X00, but you will NOT get the fades/loss/etc. data. As you say, there's no data port on the Rx t provide it. But other than that, things work fine. Or at least, they worked fine last time I tried them. That was on 4.0.1.

.

Thomas.Heiss wrote: But none of us can tell for sure if the sending signal of a TM1000 / TM1100 may disturb a LemonRX or OrangeRX receive operation just because those both units can not 100% successfully syncronize each other.
At least that is what I read on a German forum.
We do not really know how these units implement DSMx.

Using the TM1x00 doesn't really make a difference. Since we don't know how they implement DSMx, we don't know how well it will work with or workout the telemetry module. And since Spektrum doesn't support TMx00 on receivers without a data port, we don't know using the telemetry module on those won't interfere with them. Nuts, we know that some Spectrum Rxs don't work properly with deviation.

Spectrum and the forums disagree about recommending DSM2, as Spektrum said that DSM2 was fine in almost all cases.

But none of this is unique to DSMx. It is going to be true unless there is some sort of real reference for a protocol. Sources for both ends, for instance. We really needed open source receivers.

mwm wrote: Nuts, we know that some Spectrum Rxs don't work properly with deviation.

Spectrum and the forums disagree about recommending DSM2, as Spektrum said that DSM2 was fine in almost all cases.

But none of this is unique to DSMx. It is going to be true unless there is some sort of real reference for a protocol. Sources for both ends, for instance. We really needed open source receivers.

Hey Mike,

Can you link the source of reference / complain / thread which tells about what genuine Spektrum receiver were not compatible with a Devo sender and DeviationTX and what version?

Is that the final result of interpreting thread complains like "Devo 12 limiting DSMx range"??

Thomas

Thomas.Heiss wrote: Can you link the source of reference / complain / thread which tells about what genuine Spektrum receiver were not compatible with a Devo sender and DeviationTX and what version?

Is that the final result of interpreting thread complains like "Devo 12 limiting DSMx range"??

No on both counts. I can't link to it, because the problem predates my involvement with deviation. And it's not the result of interpreting a thread, it's the result of reading the manual. Open your copy, go to the DSM2 section of the Protocols chapter, and it says:

Note that many receivers with less than 8 channels require the Transmitter to send 7 or less channels.

Sure enough, if I bind a 350QX1 with an 8 channel deviation model, the 350QX1 goes crazy. Switch to 7 channels, and 350QX1 works fine. 8+ channel Spektrum Tx's work fine with the 350QX1. Horizon not only supports this configuration, but recommends using an 8-channel Tx to control their GB200 gimbal with the 350QX1, connecting a satellite Rx to the gimbal.

Since there's a trivial workaround that can be used by all but a handful of users, it's never been fixed. It may be fixed in Indigo's rework of DSM for telemetry, but I haven't tried it, and we don't know if or when that will be merged into the builds.

So you are more into talking about channel settings (correct configuration within DeviationTX) on genuine Spektrum receivers but not of LOC / LOS (loss of connection, loss of signal) with the receivers?

I will see how real-live / flight-tests go with AR6210 in an EPP material glider next months...
I may choose to fly AR600 in StrykerQ later on successful completion.

So asking again:
For AR600 / AR6210 (and others like AR6255, AR610, etc.) genuine Spektrum receivers it is not known to you
of any connection loss situations or that people wrote about that in concrete to threads (bypassing the help messages about telemetry and maybe loss of connection / deadlocks)? You did not mean that, right?
This would of course imply that someone would actually setup the model within Deviation to DSMX 6CH only.

At least my AR8000 with 8CH DeviationTX DSMx setting is working fine so far.
But I will choose to change 100mw->150mw according to vlad's HF power tests just to be on the safe side.


BTW: The 350QX2 (not 350QX1 V2) started to using a dedicated full-range AR600 - because of many range complaints to HH.
Previous QX versions only had the all-in boards with the cheap half-range copper antenna.

No, it's not a LOC or LOS issue, it's a complete and total failure to work. Yes, you can work around it by changing the configuration, but the failing configuration is one that works if you use a real Spektrum Tx. That it doesn't work means that hardware that you can fly and control with a real Spektrum Tx you can't fly and control with deviation. And yes, it uses genuine, supported-by-Horizon DSM Rx's.

The shows that there is a difference between the Spektrum and deviation implementations of DSM. Will it crash your aircraft? Who knows. The only test we have for anything is whether or not it works for you. If it doesn't, without tests using HH supported hardware on both ends, we'll never know if the problem is with deviation.

Can you provide a link to HH saying they switched to the AR600 on the 350QX2 because of range problems with the 350QX1? My understanding was they switched because the previous version didn't have channels available for gimbal control, requiring use of a satellite Rx. Of course, HH won't admit to problems unless they get really, really bad, so either or both could be the case even without a reference.

@matriyFlyer: HK does not announce FlighLog telemetry data for the orange r720x on its homepage product description?!

Thomas.Heiss wrote: @matriyFlyer: HK does not announce FlighLog telemetry data for the orange r720x on its homepage product description?!

I don't know. I just read the description but I can't find any "fligh log" in its description.

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)

vlad_vy wrote: normally fades can be up to 500. Also, if fades is more than 511, it's probably = 'Telemetry Range Warning' and has to be filtered and trigger telemetry range warning.

As you know I am currently running nightly build devo10-v4.0.1-fcd0669 with AR8000+TM1000.


My observations:
1) On telemetry range warning (created by 100-300uw/1mw output power) holds = 255 randomly popup.

2) NOT_CONNECTED Fades B/R sometimes display >1000 random numbers as you noted above vlad. Was the same for 36cce5c as written before.
Will re-test with latest test build.

3) Sometimes some fixed value 512 on B/R is displayed (AR8000).

4) With this firmware Fades A also has limit on AR8000 to 255 (does not go further).
So it's really AR8000 8-bit counter (hardware), not test build fault as of 36cce5c.
Found a thread on RCGroups which confirms that.

5) Fades A is not reset by fcd0669 to 0 once max 255 bit counter has been reached. VERY GOOD!
But that was the case for test build 36cce5c. Will re-test with latest.

6) For in-flight telemetry warnings I setup a RxV <=4.3V and Batt <=10.5V telemetry config.
I do get from time to time short beeps while (park-) flying with 450er heli. I do not know what peeps these are because of multiple telemetry configs.
The telemetry monitor popups up and I believe it may have to do something with one of those fields because of "telemetry range warning".
Can that be? I see some action on telemetry monitor for those fields with my ground range tests.


Question about telemetry range warnings:
A) @Indigo: Do you have in your latest test build telemetry DSM code yet any active range filtering function to switch telemetry monitor display fields black/inverted for packets with holds = 255?

B.) How shall we handle "telemetry range warnings" on A/L/B/R for 7-12 channel receivers which may display >255 / > 512 / >1000 just fine with 4 digit numbers on Fades? e.g AR8000 Fades L can take 4-digit numbers for real fades.

B1: Personally I have set up telemetry config warnings for Fades >80 for in-flight and I would expect in a "all working DSMx range scenario" that these numbers do not get into the >255 range.

B2: On ground tests this is a different topic:
You test Fades for 1-4 receiver antennas and compare (especially on DSMx) the numbers of max Fades for each antenna to each other.
If there are 1-2 antennas who have HIGHER / VERY HIGH Fades then (only) THIS ANTENNA is blocked by electronic, CFK & Co. and would have to be re-orientated. You then simply repeat the Fades test.

It makes therefore no sense to display the Fades as "0" after receiving e.g 512 or >1000 and at once invert the monitor fields (black / inverted on Devo 10). I really want to see those real numbers IF the 7-12CH receiver FlightLog supports it.

C) How long does it take the improved telemetry / protocol code in Indigos latest test build to blend over after recognizing a "telemetry out of range"?
D) How long does it take to recognize an successful TM telemetry re-connection and re-activate the normal monitor display?

C+D) Do you just wait for one telemetry packet and switch back and forth?
My feeling on fcd0669 and 36cce5c was that there is some delay for checking telemetry packets which might be good to have a steady telemetry monitor display?

E) Or is your concept to display the received Fades number per each field but still decide if the fields are normal or black/inverted?

F) How do we want to handle RxV<=4.3V and Bat<=10.5V warnings because of "telemetry range warning"? How is it handles currently? Has something changed in Indigos test builds?

G) Does a config Fades A + Fades L > 80 warning make sense? Will i run into an beep because of a temporarily "telemetry range warning"? Checking these + FL/H is triple safety. FL/H is double safety.

H) How do we want to configure and handle permanent "out of range" and temporarily "out of range" situations?
Some pages before I told about DX8 telemetry antenna symbol flickering on main screen.
Flickering or no active antenna symbol = telemetry out of range.
But that only means the TM1000/TM1100 got out of range.
It does NOT necessarily mean the TX signal is lost of the receiver!

I) Would there be any way to check in telemetry receive code:
Is this received number temporarily because of a bigger stepping increment comparing the new received number (e.g >512, >1000) to the last active/stored number (when there is no out of range) or is the number permanent because the increment step was normal / not TOO HIGH?

Do you maybe have an idea how to check for Fades/FrameLosses for the the wider increment steps to make specific warning/display decisions for the telemetry monitor?


Yes, I will do some tests with Indigos latest test build as soon as possible. But can't do with this AR8000/Heli in-flight
I also need to get up the DataLog recording working as PhracturedBlue explained some pages before.

Greetings

Thomas

I just got and tested the R720X S.BUS from hobbyking. On my Devo I tested (bench test) indingo 10 May release and last nightly build. Both seems to work the same.

The receiver has 7ch pwm and 8ch sbus.
With dsmx and telemetry ON I can't get a bind with 7 channel. I can get a binding with 8ch on devo10.
With dsmx and telemetry OFF I can get a bind with 7ch and 8channel.

In all the cases I need to move one of the stick of my radio to complete the binding procedure.

With dsm2 I don't need to move the stick of my radio to end the binding process.


I will test this receiver in my mini quad with latest nightly build (19 of june) but I don't know what is the better binding.

Do you get this behavior with the stock nightly builds.

Last time I looked, there were known issues in deviation as you go from 7 to 8 channels with DSM. For the most part, this is a minor matter, as binding with the maximum number of channels the Rx supports works, so you just do that. It's rare to need to bind with more or fewer channels than that.

The DSM2/DSMx protocols at some point changed to not complete the bind - the box about binding stays up, and the bind doesn't finish - until you move a cyclic stick. This is intentional. Could that be what you're seeing?

mwm wrote: Do you get this behavior with the stock nightly builds.

Last time I looked, there were known issues in deviation as you go from 7 to 8 channels with DSM. For the most part, this is a minor matter, as binding with the maximum number of channels the Rx supports works, so you just do that. It's rare to need to bind with more or fewer channels than that.

The DSM2/DSMx protocols at some point changed to not complete the bind - the box about binding stays up, and the bind doesn't finish - until you move a cyclic stick. This is intentional. Could that be what you're seeing?

Yes it's that!!! Thank you very much. So I can be confident binding with 8channel and telemetry ON. (just for the dataport value I will not connect any sensor.)

matrixFLYER wrote: Yes it's that!!! Thank you very much. So I can be confident binding with 8channel and telemetry ON. (just for the dataport value I will not connect any sensor.)

I almost through a 620X into my last order from HK. Can you tell me if you're getting both signal strength (Fades, Losses, etc.) and Rx battery values from it's telemetry? Those are the only two I need from my Rx's - for now.

mwm wrote:

matrixFLYER wrote: Yes it's that!!! Thank you very much. So I can be confident binding with 8channel and telemetry ON. (just for the dataport value I will not connect any sensor.)

I almost through a 620X into my last order from HK. Can you tell me if you're getting both signal strength (Fades, Losses, etc.) and Rx battery values from it's telemetry? Those are the only two I need from my Rx's - for now.

Everything is displayed. Even battery V and temperature if you put sensors.