DSM Telemetry support

Will turn out signal level the RSSI OrangeRx R620X V2 receiver doesn't show on the equipment?

Not necessarily on topic here but seemed like the best place to post it (that a search could find)...

I was hoping to use a cheap $8 APM power module on my OrangeRx Rx20X series of telemetry receivers as the current meter since it's about $28 to get an orange current module from a US shipper (about $22 shipped from hong kong). Anyway I was looking at the board and the current module connector (which is one of the typical SPEK SAT 3-pin 1.25mm pitch connectors) had GND / 5V and one more pin which didnt seem to go to any sort of voltage divider or anything obvious so I was hoping it was just a ADC input but regardless of the load (from 1 - ~50A) it didnt register anything for the current value on devo. I'm going to trace out the board and see exactly which MCU pin that input goes to, who knows maybe it's a serial protocol and the Orange current sensor has a uC on it too.


Again I know this isnt exactly on topic but I just wanted to report my findings somewhere. If I do get it working I'll report back.

Here are my DSMx ground tests - will update my posting for outstanding further tests:
- repeating AR6210 + AR8000 +1mw range tests
- latest nightly-build firmware updates on DSM protocol changes (vlad changed DSM code in nightly build 4b3dc91 after this fcd0669)
- Indigos DSM protocol latest test build (big DSM code changes) - checking for same/different behavior for 100µw-1mw range tests and FrameLoss / Hold behavior (I had once seen in his previous test builds)

Devo10 on nightly build 4.0.1-fcd0669 - in-flight live test: www.deviationtx.com/forum/protocol-devel...none&start=340#33913
LOS = complete loss of signal (rudder test) = >0 holds
300µw = ca. more +12-13m distance compared to 100µw


Devo10 with Spektrum AR600 + TM1000:
* 100µw ~33-34m/max 35m with no LOS / 0 holds (at that big distance for 100µw there are many (>40) FrameLosses and telemetry out of range warnings)

* 300µw ~45-47m/max 48m with no LOS / 0 holds (at that big distance for 300µw there were very many (>40) FrameLosses and telemetry out of range warnings)

* 1mw (=Spektrum range test ~30-35m) to be re-tested: I had up to ~60-65m with no LOS / 0 holds / not that many FrameLosses on AR600/AR6210/AR8000 last year.

Thomas

Hello all, Hello vlad_vy,

Despite the fact that I am kinda short on time - like you guys - I have got some questions regarding CYRF reset and telemetry error detection code (e.g RX and TX improvements against a possible deadlock as well as bogus packet checking) enhancements for DSM2/DSMx.


Coming from recently posted "brown-Out thread": www.deviationtx.com/forum/6-general-disc...s?limitstart=0#42117
I really feel I should re-ask these questions to you experts.
...Before I do firmware upgrades next months or fly my models like 450er heli with my older nightly-build version.


Part I (error message on submit "too many links" - I could not post my reply):

Vlad_vy fix 572e350 RF channel on CYRF reset fix is only about devo_CYRF: bitbucket.org/deviationtx/deviation/comm...da07ab84befd1d48ae9a

On 2015-07-29 Vlad_vy commited DSM protocol changes 4b3dc91:
bitbucket.org/deviationtx/deviation/comm...034d5e0db071828bf291
Related thread: www.deviationtx.com/forum/protocol-devel...etry?start=420#32286

This was between Indigo, Vlad_vy, PB, Indigos ongoing DSM protocol changes in test-build.
I guess the RX error state detection is just the above code from 4b3dc91?

PhracturedBlue extra error checking: www.deviationtx.com/forum/protocol-devel...etry?start=200#30562

Now in the brown-out thread you are all talking about nightly-build end of April 2015 is fine / fixed and you are speaking for all protocols including DSM??
Well this was then only needed for the DEVO telemetry side?!?

But the real truth is that Vlad_vy DSM changes on 2015-09-27 4b3dc91 come later than 04/2015.

Google site:deviationtx.com 4b3dc91:
www.deviationtx.com/forum/protocol-devel...none&start=360#36787
www.deviationtx.com/forum/3-feedback-que...been-fixed-yet#36873

- continued as part II -

- Part II continued (too many links error message) -

My testing on nightly build fcd0669 2015-05-30 did not even include Vlad_vy DSM protocol changes (RX error state checking???) from 2015-07-29.

So my statement on both threads for build 4b3dc91 may be true, but does not reflect full truth: www.deviationtx.com/forum/6-general-disc...-outs?start=20#44216


What is the full truth about DSMx protocol code for:
- triggering a needed CYRF reset (e.g when DSM telemetry is on) just like with DEVO
-> the fix was "to set the missing RF channel", so the reset trigger in the C protocol code is something else??
- RX error state checking (e.g bad state)
- avoiding possible RX (telemetry)<->TX deadlocks (never happend to me so far with my tested nightly-build versions)

Is that only in Indigos test-build (I know very many code changes)?
I had one of those DSMx RX/TX-deadlocks in an older test-build from Indigo (tested with 200QX on ground).
I still could not test Indigos latest


May it be true if I say that this code changes on 4b3dc91 are part of Indigos test build and DSM code changes and have already been pushed by Vlad_vy to default/trunk?


I dislike commit log 4b3dc91 "DEVO and DSM protocol updates" as this tells you nothing if thats the RX error state checking improvement (for telemetry) you guys where talking about earlier or what this is for (critical???).
Does it add a CYRF reset for the DSMx protocol?

Wouldn't it then have explicitly to be mentioned on forums and range/telemetry problems (fix), even in a sticky thread?


The other commit log problem for 572e350 "Set RF channel after CYRF reset." is that it does not even include the keywords "Walkera" or "protocol". You simply do not get it listed in commit log search as "very important fix".

Was trying all the time to get it listed searching for "DSM", but of course it's just RX channel on Walkera CYRF protocol, not DSM CYRF.


I am just trying to get myself the big picture - as a Non-C developer and without knowing the register CYRF states - for some more further DSM tests in the future and of course being on the safer side when flying my models.

Thanks so much for all your efforts.

Thomas

Hi, I am having a MAJOR issue with DSMX voltage telemetry. Please see bug tracker 0000670 here

Very scary as the model usually falls out of the sky around 13.5v

From Failsafe Devo10 thread: www.deviationtx.com/forum/6-general-disc.../52560?quote=1#52560

RoGuE_StreaK wrote:

mwm wrote: Indigo's DSM changes

Mike did they only come in on 5.0, or were they implemented before that?

Some parts of Indigo went into V4.0.1-nightly builds -> 5.0 release.
See my "DSM telemetry support" two page listing.

ADDITIONAL fixes in a later nightly (+5.0 rls) by Vlad from DSM+DEVO telemetry support threads for state checking, which might also be included "somehow" in Indigos test build (I did not check sources).

Indigos test build was MUCH more than V4.0.1 nightly build merging (basic telemetry stuff).
No, it did not went 1:1 into 5.0 release (especially the bigger source part).


Indigos test build was about a major protocol re-write including RX<->TX code (separate buffers), (more) register error checking.
Trying to further improve DSM telemetry, filter / get rid of bogus DSM telemetry packets, etc.

I had plans on my TODO list to test intensively his test build for DSM telemetry improvements (e.g out of range, bogus numbers, fast switching fields, etc.).
Have to further put that back because of missing EPP planes / quad electronics and time.

Thomas

Change-/enhancement request: Counting FrameLosses n delta in 5-10sec time interval
www.deviationtx.com/forum/7-development/...amelosses-time-delta

Telemetry out-of-range / handling of inverting monitor fields: www.deviationtx.com/forum/protocol-devel...d-out-of-range#54090

First 3 successful EPO glider flights on Deviation release 5.0.0 with DSMx, AR6210, TM1000 and EPO glider: www.deviationtx.com/forum/protocol-devel...5-0-0-tx-crash#54105

www.deviationtx.com/forum/protocol-devel...port?start=400#46358

Thomas.Heiss wrote: Hello all, Hello vlad_vy,

Despite the fact that I am kinda short on time - like you guys - I have got some questions regarding CYRF reset and telemetry error detection code (e.g RX and TX improvements against a possible deadlock as well as bogus packet checking) enhancements for DSM2/DSMx.

- Part I -

Vlad_vy fix 572e350 RF channel on CYRF reset fix is only about devo_CYRF: bitbucket.org/deviationtx/deviation/comm...da07ab84befd1d48ae9a

On 2015-07-29 Vlad_vy commited DSM protocol changes 4b3dc91:
bitbucket.org/deviationtx/deviation/comm...034d5e0db071828bf291
Related thread: www.deviationtx.com/forum/protocol-devel...etry?start=420#32286

This was between Indigo, Vlad_vy, PB, Indigos ongoing DSM protocol changes in test-build.

Now in the brown-out thread you are all talking about nightly-build end of April 2015 is fine / fixed and you are speaking for all protocols including DSM?? Well this was then only needed for the DEVO telemetry side?!?

- Part II continued -

What is the full truth about DSMx protocol code for:
- triggering a needed CYRF reset (e.g when DSM telemetry is on) just like with DEVO
-> the fix was "to set the missing RF channel", so the reset trigger in the C protocol code is something else??
- RX error state checking (e.g bad state)
- telemetry monitor jumping high FlightLog numbers which are shown in normal monitor state instead of telemetry out of range warnings (including xx->255 jumps (not 0xFFFF 65535) for FrameLosses/Holds) in release 5.0.0
- avoiding possible RX (telemetry)<->TX deadlocks (never happend to me so far with my tested official nightly-build versions)

Does it add a CYRF reset for the DSMx protocol?

I can now answer my own question for CYRF DSM reset: No, it did not.

Vlad implemented new DSM CYRF reset:
www.deviationtx.com/forum/protocol-devel...rrors?start=20#54328
www.deviationtx.com/forum/protocol-devel...rrors?start=20#54338

Release 5.0.0, despite Vlad's 4b3dc91 (BitBucket repos) state handling commit, still contains some telemetry monitor field sporadic jumping / shown high Spektrum FlightLog numbers (not 100% filtered).

In-flight it was OK to me so far (only 255 Fades A (power cable near antenna, max bit counter) on AR6210).

I may try latest Indigos DSM test build from 2015 to compare telemetry monitor FlightLog handling against this behavior as well as.

Thomas

Found older posting from Indigo in 2015 describing what we were exactly working on for DSMx FlightLog / telemetry data: www.deviationtx.com/forum/3-feedback-que...tions?start=40#28156

www.deviationtx.com/forum/3-feedback-que...tions?start=40#28224
Maybe some telemetry monitor descriptions from 2015 by Indigo could be copied over to Wiki for release 5.0.0 feature explanation?

Have to find my V4.0.1-nightly-build 36cce5c posting and recorded videos for FlightLog jumping numbers / bogus data myself
On my TODO list is to re-record a FlightLog video or do some FlightLog CSV logging with release 5.0.0 and latest test build from Vlad.

I am flying an Oxy 2 with uBrain 2 and Spm4649t and get voltage, rpm, fades back to my Devo 6s via Srxl.

Cool device that Spm4649t. What Flybarless are you using?
I'm still using an old fashioned receiver (AR6210) on my Heli-Pro Alien, together with a TM1000 for Telemetry. Much more cable, much more weigth. I get the receiver voltage, fades/loss and battery capacity (measured by a rctronix.de current sensor) on my Walkera Devo 10/12E