DSM2/X protocol errors

Ok...Thank you...

I using only Orange RX and Spektrum Reciever...What you suggest? Stay on 4.01 or change to 5.0 with new DSM2/DSMX option??
I am still little confused because in my head is sentence : "If something working ok, then don't change this"

MacGyverek wrote: I using only Orange RX and Spektrum Reciever...What you suggest? Stay on 4.01 or change to 5.0 with new DSM2/DSMX option??
I am still little confused because in my head is sentence : "If something working ok, then don't change this"

Yes upgrade because of "Question about V4.0.1-nightly-build": www.deviationtx.com/forum/3-feedback-que...-nightly-build#46790

Vlad what do you think about this scenario Roland described for release 5.0.0 and his RX: www.deviationtx.com/forum/protocol-devel...d-dev-5-0-0-tx-crash

Was it really a telemetry receiving <-> transmitting deadlock or something, maybe hold?

I tested ground range 3 times on 100µw, 300µw, 1mw on AR6210 + release 5.0.0 including telemetry out of range (and re-connections).
When walking back to the plane the telemetry monitor showed in good receiving distance new TM1000 telemetry data and all inverted/black FlightLog fields where back to normal. Steering rudders still worked - after or even while telemetry out of range.
But this was only some short tests and I did not experience the deadlock I had once on one Indigos DSM test build on RX<->TX code re-write (not latest)...

Too bad Roland could not find the plane before by trying to get telemetry monitor back and all FlightLog fields displayed.
But with his TX switching off/on (failed throttle tests) as well as higher green landings he IMHO forged the FlightLog numbers (holds, FrameLosses + Fades) anyways.
I experienced once FlightLog holds (not any reception) in higher green field by doing ground tests!!

mwm wrote:

vlad_vy wrote: Protocol module for Devo 7e kill all possible modifications for DSM2/X protocol. Now I can't add even single line of code, it doesn't fit to Devo7e. Now some strange things has place with code, if I exchange two adjacent lines of code, it doesn't fit to Devo7e since protocol module size increased or decreased by about 56 bytes. Why? I don't know.

Up until 5.0, this was the case with the flash code as well. It's why the 7E may not be supported in the next release. We're no longer holding features back for the 7E. Yeah, it sucks all the way around.[/quote]
For the 7e limit, I tried an approach to generate two distinct modules, one for DSM2 and one for DSMX, from the same source file. It allowed to gain some space in both, and relieve the pressure. But the implementation of the cutting was quite dirty, and so far rejected. If someone with sufficient make expertise could help...

@vlad_vy, please, can you get a github account and submit your changes as a pull request. Your valuable modification will languish here in the group discussion - the repository is the place for development.

If you absolutely can't get an account for religious purposes (I know no other reasons not to) - I can do this. But I hate to take credit for you and explain it in comment etc. where there is a regular, established process for this.

Well, not one but individual PR's please

Probably it will get tough more and more to track changes
- against Indigo's 2015 DSM test build sources
- Vlad's BitBucket repos DSM changes 4b3dc91 (are those the end result of Indigos enhancements or what are they for?)
- and any additional telemetry filtering / bogus packets improvements (if there are any more), which may be only committed in Indigos repos until now (which you core devs have discussed back and forth in two DEVO+DSM telemetry support threads)

Yes, I have already seen the Flightlog high jumping numbers (telemetry out of range) on 100µw on release 5.0.0 too like previous V4.0.1-nightly-builds.
There was an Hold - or was it FrameLosses field? - 0-> 255 jump too, which resulted in a configured telemetry alarm.


BTW: I have plans to test Vlad's new test build first on Spektrum AR6210 in EPO glider...
Not sure when I can move up to AR8000 for 11ms high speed and Blade flybar heli - best after some successful previous basic tests (still missing tail servo + mechanical re-setup + some time). I am still missing crash-proof CFK quad electronics for first tests.

Thomas

vlad_vy wrote: Now I have short vacation by health reason, so I entertain myself by a simple programming.
Final version, I haven't ideas what I can to improve and my free time almost come to an end

Hope your health is getting better again and you recover fine.

Ideas: Maybe this?

Framelosses n delta: www.deviationtx.com/forum/protocol-devel...port?start=400#53899
or
Telemetry out of range (high FlightLog big number jumps (including 255) FrameLosses/Holds):
www.deviationtx.com/forum/protocol-devel...port?start=400#53899

You can provoke odd high jumping FlightLog numbers (probably as a "telemetry out of range" signal) - in release 5.0.0 as well as - by using output power 100µw and walking in your building with walls in between to plane.
The telemetry monitor code does not yet filter these FlightLogs accurately and also does not fast enough switch to black/inverted FlightLog fields, so it just shows these random high numbers in normal telemetry RX state.

Indigos latest DSM test release: Had this been fixed / moderated by Indigo successfully in 2015 yet? Could not test latest yet.

I would have to search for my old DSM telemetry support posting for 92... V4.0.1 nightly build and videos. I do have to repeat 100µw range video on release 5.0.0.


But IMHO way to many (almost untrackable??) source changes together at once - please do not commit just ONE big protocol file change to repository There should be a backport of your important DSM changes to release 5.0.1, shouldn't it?!

Thomas

Not so successful telemetry (AR6210, TM1000) DSMx test - frozen telemetry monitor - with version 09/28/2016: www.deviationtx.com/forum/builds/6407-de...test-protocols#54480

Thanks for your hard work Vlad!

Where it the source changes

and

three times after "parse_telemetry_packet(); which fixed the error?


Do you remember from DSM/DEVO thread discussions Vlad how Indigo DSM test build protocol changes should prevent any "potential RX<-TX deadlock", that a "potential RX freeze" can NOT hangup a TX transmit?

I would like to repeat my previous statement #54562 from other test build thread: www.deviationtx.com/forum/builds/6407-de...test-protocols#54562 :
TX transmit was NOT affected by DSM code for my 2-3+ in-flight tests, even for this happening RX/telemetry freeze (no data received anymore).


BTW: Wasn't Indigo testing with RX ABORT and stuff too, or did he remove those "tries" later again by later commits (he did remove some stuff according to BitBucket repos commit history)?

e.g I can not see any 1-3 time "CYRF_WriteRegister(CYRF_29_RX_ABORT, 0x20)" calls in Indigos dsm2_cyrf636.c source file in those code block sections
but
"{CYRF_29_RX_ABORT, 0x20}" inits in data_vals and 0x00 resets in init_vals which you had to de-activate in transfer_vals.

BTW: Vlad, did you take a look on the experimental DSMx build about protocol optimization?
www.deviationtx.com/forum/builds/5822-ex...ls-size-optimization

Maybe it would be nice to include any further possible protocol code optimizations (size) with your test builds?

Sorry, NO, I did NOT test those mentioned protocol optimizations in this experimental build yet
It seems everyone, including me, was a bit afraid to test the above linked experimental build....or has no free time?

Maybe I can assist a bit in ground range testing with Spektrum receivers and laters with in-flight tests if 2-3 core developers reviewed above optimize code.

Too bad your free development time is over Vlad...