Deviation v5.0.0 build with latest protocols

Thanks a lot. I love the old color icon interface so much better than the new text based one. I guess I'm just a 'point and grunt' kind of guy.

I decided to try your build on my 8S first, which had the latest nightly build. I loaded the DFU and the display was weird, so I deleted the nightly build file system from my 8S and loaded the stock V5.0.0 file system and your DFU now works great. Makes sense now that I think about it. I tested the most recently developed protocol I know of, the FQ777-124, and it worked great.

Thanks

Is any of this going to be in the nightly builds, or is this now a rebel version (lol)?

Tnx Vlad_vy for the Updates

First firmware test today with zip/dfu version dated 09/28/2016. So one day / one version behind last final 09/29/2016 version
- Devo10
- AR6210
- TM1000

Telemetry monitor (and main telemetry voltage field) was frozen at 12.1V.
All telemetry monitor fields constantly black/inverted (including main screen voltage).
When I landed and had the transmitter in near of the TM1000 the telemetry did not come back anymore as release 5.0.0 + fcd0669 did before.

So it seems I lost DSMx telemetry very soon after takeoff?!? (of course I did not constantly lookup at display as this was my 1st trim-flight after some HLW/SLW glider modifications).

Testers pllease be very careful with this DSMx version, as no low lipo voltage <=10.5V (3s) was alarmed anymore over the whole flight!

TX transmit signal was OK (no deadlock) - controlling the EPO glider was no problem over the whole flight.

Would have to track it down what was the reason, e.g any problems on TM1000, re-testing 100µw ground range and play with telemetry out of warnings or just telemetry RX lock...


Unfortunately today the Devo10 EXT/down button board got corrupted, dunno how (rain, water, etc.)?
I can not press the left side down button anymore.
I may not be able to continue a detail test.

BTW: The Devo10 board is labled WK-2410-EXT 2009.06.23.

Thomas

On Devo 10 i had a Button Problem to some Time . It was one of the Wire inside the Connector. Bad crimp job from Factory.

May be ith helps to find your Failure.

Just an FYI issue: Since you are familiar with the DSMX code, there has been a long time issue using Orange satellites on a 6 channel HCP100S and others. The problem may be obvious to you since you have been working on the DSMX / Orange compatibility. The problem is you must pre-bind the Orange sat with a 7 channel receiver if using a Deviation transmitter, but with a 6 channel receiver if using a DX6i. Also, you must fly them in 7 channel mode with Deviation even though the HCP100S receiver is only 6 channels. I had the same problem when using the Orange satellite on an iKon. My best guess (and only a guess) is there is different protocol between the sat and receiver in 6 ch DSMX vs 7+ channels and that '6 vs 7+ ch mode selection' is not being initialized properly by the Deviation bind sequence. Another guess is how unused channels are handled in Spektrum vs Deviation, maybe one still transmits unused channels as zeros and the other is not transmitting the frames at all. Here is my old post about the issue. www.rcgroups.com/forums/showpost.php?p=31775011&postcount=2108

This isn't an issue for me anymore because I don't use the Orange satellite now that I have the modules installed in my Devos. It might just point you in the direction of a compatibility issue with pre-binding with a Devo vs Spektrum. Also note that I haven't tested to see if this issue has been resolved in more recent Deviation releases, I was using V3 back then.

Also, many thanks to you and all the others that are making Deviation so great!

So it sounds like you are saying that DX6i '6 channel' DSMX' is not the same as Deviation '6 channel DSMX' because the DX6i is actually 7 channels, 6 used channels plus an empty channel, that's why Deviation has be set to 7 channels.

Thanks

The HCP100S and iKon using Deviation DSMX 6 channel mode works fine with Spektrum sats when pre-bound using 6 channel receiver, The orange sats have the channel order wrong when pre-binding with 6 channel receiver and Deviation, but correct when using DX6i. I suspect the Orange sat is ignoring the number of channel data and just always assuming 7+ channel layout.

Thanks for the info, it gives me something to think about.

Thomas.Heiss wrote: First firmware test today with zip/dfu version dated 09/28/2016. So one day / one version behind last final 09/29/2016 version
- Devo10
- AR6210
- TM1000

Telemetry monitor (and main telemetry voltage field) was frozen at 12.1V.
All telemetry monitor fields constantly black/inverted (including main screen voltage).
When I landed and had the transmitter in near of the TM1000 the telemetry did not come back anymore as release 5.0.0 + fcd0669 did before.
....
TX transmit signal was OK (no deadlock) - controlling the EPO glider was no problem over the whole flight.

Would have to track it down what was the reason, e.g any problems on TM1000, re-testing 100µw ground range and play with telemetry out of warnings or just telemetry RX freeze...

I)
Another ground test in near distance with build version 09/28/2016 AR6210+TM1000 in same room immediately got me a frozen telemetry screen.
I even had not to walk out of room / distance.

Other tests at 100uw showed, like Vlad describes, that telemetry returned once back in distance.
2nd test flight showed again the same behavior (loss of telemetry in-flight).


II) New test with Devo10 build version 02 Oct 2016 08:55:
Same behavior as build 09/28/2016.

Re-producable / repeated telemetry losses in-flight (freeze). Transmit works fine (no deadlock).
It's always just a quick telemetry connection.

So somehow in my test setup telemetry RX code creates a hangup in sporadic situations, and is always re-producable in -flight.

First 100uw ground tests were in parallel successful however, see below.

I also encountered a COMPLETE RX/telemetry freeze, just like I did once with 200QX on an older Indigo DSM test build.
Plugging in a new flight pack did not reset telemetry monitor.
I had to either turn OFF the transmitter OR switch to another model memory slot.

vlad_vy wrote: I havn't problems with telemetry (Devo8+ AR6210 + TM1000), 100uw test, with distance up to many Frame losses and several Holds. V1 =7,33V, V2=6,3V or 11,2V with different batteries, GPS show all info. After telemetry fields become black/inverted, all restored with shorter distance.

I need to do more tests.
P.S. I done several range tests, with many Frame Losses and 8 Holds, about 30 min of uninterrupted testing. Telemetry work fine, I can't get it frozen.

My 100uw first ground test on build 02 Oct 2016 08:55 (only did one) was successful, like Vlad described, too.
Out of range -> telemetry monitor black/inverted fields.
Back in range -> monitor fields back to normal + displaying new FlightLog numbers.
Typical test-case which always worked for 5.0.0 + fcd0669 before.

In-flight I lost again telemetry monitor link to TM1000 and it did not come back anymore when I landed and had the glider next to the transmitter.

Comparing builds 09/28 and 10/02 I would say that telemetry lost (out-of-range) was earlier with 09/28??
10/02 telemetry was fine for a while, I manually checked the screen if the fields were black/inverted that soon.

However, I do hope I not confuse some test and firmware upgrade facts the last 1-3 days especially 10/02
Probably will have to re-test 10/02 for some more real flights with another TM1000 (e.g turned of Bat main screen, etc.).

---

I am not sure anymore if either TM1000 or Devo10 HF-module maybe got damaged, e.g rain before when first tested build 28/09/2016.
Could that be?
But well then probably it should not even work a little bit and all 100uw telemetry distance ground range test should also always fail???
Will try to swap TM1000....

I will have to go back and re-test with release 5.0.0, which always worked - like V4.0.1-nightly-build fcd0669 (BitBucket) - once I fix this glider fuselage (little bit of trouble with bad sight / cloudy / dark as of today).


Are there any code changes since 5.0.0 Vlad which may get the RX side out of sync with the TM1000 even there is new telemetry data received?
I thought fixes were just a little bit of channel hopping table, CYRF reset, etc... New reset code can't be telemetry freeze, right?
Isn't the RX state / register checking in builds 09/28 to 10/02 the same as of before in release 5.0.0?

What possible code changes could trigger a complete RX freeze - like I experienced once with Indigos older test build (200QX used, not TM1000)?
But Indigos older test build protocol rewrite-code was much worse at this moment as the TX side also run into a freeze / no bind anymore, no control), not so with your builds 09/28/2016 or latest 10/02/2016. Transmit no hanging. Good!


My problem does not have anything to do with any possible voltage error, right?
www.deviationtx.com/forum/protocol-devel...port?start=400#46638
I am on 3s btw. Never had any problems before.
It's not the main screen, but also the telemetry monitor. And ALL fields are black/inverted, including Bat voltage.

I can not remember exactly when I put the Bat telemetry field onto main screen. I guess that was already with 5.0.0. But I am not too sure.
I will try to re-test without bat field on main screen as well was with 5.0.0.
With build 10/02/2016 my test was with configured Bat telemetry alarm on #4-6 jumping slots, so I should have noticed.
With build 09/28/2016 my test was with configured Bat telemetry alarm on #1-3 non-jumping slots.

Lot's of open questions and more tests todo...just hope I get my fuselage fixed.

Will keep you updated.

Thomas

Wow, congrats Vlad!

Will try to re-test next weeks.

Devo7E test build 11ms request by Kaligula: www.deviationtx.com/forum/protocol-devel...pported-or-not#54333
Not sure how many 7E users are out there who could participate in your test build, e.g telemetry, 11ms, DSMx corrected channel hopping...