DSM Telemetry support

I think the key here is to have a consistent execution time. The added parameter is so it only needs to be called once.

I can probably improve it further by making the procedure have a more consistent execution time.

Hello everyone,

Let me start off by complimenting all the fine work done on this project. I have been using Deviation on both a Devo8S and a Devo12S (with additional RF modules) for about a year and it is great!

Recently I have been adding telemetry to all of my helicopters and really appreciate all the improvements that are in the works to improve the reliability both the Devo and DSM telemetry systems. I have just created my own local code building environment and I am starting to get up to speed with the development process. Hopefully I can help contribute to this effort in a complementarity fashion - so hear goes

For the telemetry alarm page switching changes, I also find that the original alarm works best on my system. I have modified the main page to include the telemetry information that I care to see and having the page jump is frustrating (especially on battery disconnect from the receiver.) But I can appreciate that others may like this feature. So I would suggest that two type of alarms be implemented - the original 'standard' alarm and an 'advanced' alarm that jumps to the telemetry page.

One simple method to implement this would be to make the first 2 or 3 alarms works as in the original code. The remaining alarms could be configured as advance alarms and jump to the telemetry page as the new code implements.

I created some example code that implements this on the Devo12S.

src/telemetry.c
Starting at line #342
src/pages/common/_telemconfig_page.c
Starting at line #29
src/pages/320x240x16/telemconfig_page.c
Starting at line #27
I can also add the files if anyone is interested.

Thanks again to all,
Cheers

On the Model's Telemetry Config page where you configure up to 6 alarms, the compare operator ">" or "<=" is now a combo list/button control. If you click the button is will just play that alarms sound, but I'm thinking when you click the button a config screen pops up with the following:

Title: "Alarm Actions"
Options:
- Jump to screen:<No action, Telemetry monitor, Main screen>
- Play sound: <on,off>
- Vibrate: <on,off>
- [Test button]

The Test button would execute all actions except for the "Jump to screen" action, for that action just popup the words "Telemetry Monitor", "Main screen" or do nothing.

Edit: Good idea, as an interim solution make the "Jump to screen" feature work only for the last 3 alarms.
Thank's for suggesting it. I will edit the code and make the required change.

BTW. Each alarm should have its own unique music and unique vibrate pattern. PB: Are you able to fix this?

vlad_vy wrote: PB, can you change at main trunk next things?

Also, for() cycle doesn't work. It seems all values are writed to Telemetry.p.dsm.flog.fades[0].

        case 0x7f: //TM1000 Flight log
        case 0xff: //TM1100 Flight log
            update = update7f;
            //Telemetry.p.dsm.flog.fades[0] = pkt16_to_u8(packet+2); //FadesA 0xFFFF = (not connected)
            //Telemetry.p.dsm.flog.fades[1] = pkt16_to_u8(packet+4); //FadesB 0xFFFF = (not connected)
            //Telemetry.p.dsm.flog.fades[2] = pkt16_to_u8(packet+6); //FadesL 0xFFFF = (not connected)
            //Telemetry.p.dsm.flog.fades[3] = pkt16_to_u8(packet+8); //FadesR 0xFFFF = (not connected)
            //Telemetry.p.dsm.flog.frameloss = pkt16_to_u8(packet+10);
            //Telemetry.p.dsm.flog.holds = pkt16_to_u8(packet+12);
            for(int i = 2; i < 14; i+=2) {
                *(u8*)&Telemetry.p.dsm.flog = pkt16_to_u8(packet+i);
            }
            Telemetry.p.dsm.flog.volt[1] = pkt16_to_volt(packet+14);
            break; 

Guys, you start killing me

That code block has been changed a long time ago with my first posting by Mike and Indigo: www.deviationtx.com/forum/protocol-devel...port?start=100#26681

Of course it never has been merged to team repository or PB repository - not yet.
Mike and I had to put back the "1st pull request" for PB repository.

It is now fixed in dsm-telemetry branch (Indigo repository - 2nd pull request team repository) FOR AGES - fixing the overwrite.
We had two tickets open, one opened by me (code change by Mike, taken over by Indigo with further improvements). See commit log.


May I ask you in how many repositories are you now changing and testing code in parallel?
How many developers change code in parallel? Three? In three repositories? Indigo, PB, Vlad?
According to your latest threads you change code on-the-fly (in threads), locally creating test build versions?
So there are now test builds with not equivalent source code too? Only small (debug) changes?

Why do you now have to fight with wrong - already fixed - code at team main trunk??? I really get lost!!

PhracturedBlue wrote: Where is this all going?
I have to admit I'm very skeptical of the process at the moment. When I look at Indigo's code, it has a lot of change compared to the trunk in DSM and Devo protocols. I don't really understand what much of that change is buying me. In Devo, it may result in eliminating the 'Reboot' condition, but at least at the moment, it will come at the cost of major refactoring of the callback loop, and the Reboot condition itself is not causing any issues (any more). In DSM2 the code refactor may reduce Holds? I belive the original intent was to improve reception rate (eliminate invalids and bogus data)? What else does it achieve? All of that change comes with inherent stability risk to the most commonly used protocols. It makes me very nervous, especially with 9 out of 10 builds seeming to have major issues that make it unusable. I really need to see concrete gains, and then I will wonder whether those gains can be had with less change to the protocol code.

And then there are at least two to three threads too: Walkera telemetry - DSM telemtry - OrangeRX DSMx range problems.

Your question is related to DSM - but posted to Walkera thread.


To answer your question PB, I want to answer in this thread:
1) It all started with the above DSM telemetry code fixes. FlightLog DSM telemetry is / was corrupted in (PB+team) trunk - see my above first post.
2) "9999" values improvement (see tickets 180CFX, 200SRX): AR8000 can have >255 Fades too!

3) And then in all versions (starting offical team trunk, Indigos test builds) there are (still) corrupt DSM FlightLog telemetry data - see my new videos.

Indigo wrote about point 3) in another thread - I believe it was "DSMx range thread" why he did it and for what reason (separating RX + TX buffers).

Indigo was working on point 3) to eleminate bogus DSM FlightLog data. It seems it is not fixed yet - at least I missed that success posting by other developers / Indigo / re-testers.
I have not done any Flightlog re-tests since my video with new test build versions with original Spektrum RX+TM either.

Thomas.Heiss wrote: Confirm 5) Temp value '18186C' for disconnected sensor (tested on AR8000)


New error: Fades will be reset to 0 after some time (max 0xFF/255 bit counter on A for 6CH RX a problem?)
Flightlog (fades): Jumping numbers as previously described (problem goes back to nightly version 92e1705)

FlightLog test videos 36cce5c with 100uw (not 100mw) output power:
modellbau.theiss-nbg.de/Deviation-TX-Nig...5c-DSmx_TM1000_Tests

All videos finished uploading.

4) A new problem rise with (some / one) of Indigos test builds: TX + RX lockout. DSM lock with no ever changing new telemetry data.
At least I had that issue once. See one of my tests back where I even got a DSMx TX lockout (lost of bind) with my 200QX at the table.

5) Indigo had very good ideas how to further improve the telemetry monitor screen like alarming, flickering values, alarm stop by ENT button. Re-alarmings.
We also had to change code for the stepping of "1" (holds) and 10 (Fades) since the increments where wrong in the config screen in trunk. The config screen also had wrong comparator (<=0, >=0, >0) to check for holds >0!


If we can not fix points 4) and 3) we have no real benefit and we would have to rollback all changes. But we loose all new and fixed features of point 5)!
IMHO it is the wrong time to throw away all the hard work of Indigo and all the detail improvements which already went into!!! I want them!

I just can tell you that you can NOT use trunk version 92e1705 for DSM telemetry with all that bogus data and invalid stepping configurations and missing re-alarms on FrameLosses and Holds. All stuff the DX8 has - but I hate that Airware version. And I now own a Devo 10.


Point 3) bogus flightlog telemetry data is still open at my side.
Who of you could already take a deeper look in the recorded DSM flightlog telemetry vids?
What is your feedback? Did I miss it?


I had been flight testing trunk 92e1705 + 2-4 Indigo's further (early) test builds with the 200QX. Had no TX lockout during the flight(I could not fly that far away!!).

I have no idea if point 4) is something new introduced by all the new code changes or if that might even was already in 92e1705.
According to thread "DSMx range problem" problems may have already been there before we started re-engineering.
On the other side pilots even had no clue about if they had to choose 100uw/300uw/1mw for range testing before - so that might have given wrong results too?!? For Full-Range flight tests with 100mw and TX connection problems it is again different (results count).
But who would rely on test results for 3rd party Non-Spektrum RX like OrangeRX? Not me! They could have been problems because of SBEC ESC too just like I had once with DX8 and two ESCs.


One of the biggest problems:
You guys seem to have to code (almost) blind because of missing multiple original Spektrum RX, BNF quads + TM1000/TM1100. We would even have to test with 9-12CH receivers!
In the other "DSMx range problem" thread guys are testing wrong (TX lying on/above ground) or with Non-Spektrum equipment (OrangeRX/LemonRX) or without telemetry enabled (missing Flightlog DataPort).

One guy writes he wants now to test with 150mw, even within the EU only 100mw are allowed.
Why not compare each test build version with the same uw/mw and linked Spektrum TX (e.g 1mw on ground range-test) equipment.
So even all the testers - with all this different RX equipment - can not commit on a permanent testing pattern consistent over each test build version.


FlightLog Logging:
Maybe PB / a senior DeviationTX dev could tell me how to successfully record Flightlog DSM logfile data and publish all the bogus additional numbers which may or may not be an indicator of additional "TM1000 / telemetry out-of-range"?
Unfortunately I was never successful in enabling the log file and read from it in Linux once I rebooted into USB mode. It was empty always!

Because of all point 3) code improvements and re-engineering we now see values which were badly supressed before (>255 -> 255 fixed value).


I agree with PB's statement that it will probably still take a longer time to test thru all code changes by multiple testers with multiple RX equipment until we have a final working version which is ready for a public commit to team trunk.


However I am very delighted that Mike and Indigo took my code fixes and small 8bit/16bit improvements (9999 numbers).
Thank you working together!
All the "DSM Telemetry problems/enhancements" have got so many developers and testers active trying to further improve and help bugfix continuous.
I greatly appreciate all your efforts you put into.


I am sorry to see that new test builds might bring unforeseen new TX<->RX / lock or connection lost problems (when you trying to fix that initially) at this time or the code changes are already too big to be reviewed in steps and you now fear a final trunk commit. Please don't give up and keep trying.

Is there maybe any way to split the summary of "total code changes" to individual steps which may be safely committed one by one?
- Changes which are for sure
- improvements which are safe and
- RX/TX/connection/filtering code which needs to be tweaked and tested more in detail? Comparing Walkera + DSM code...

Do you have any idea how you might get away from "blind coding"?

Thanks again to all of you who stepped into helping to bugfix and trying to further improve.

Thomas

Bug Tracker / pull request links:
BT #590: www.deviationtx.com/mantisbt/view.php?id=590
BT #571: www.deviationtx.com/mantisbt/view.php?id=571
1st BitBucket pull request #7 comments: bitbucket.org/deviationtx/deviation/pull.../dsm-telemetry-fixes

vlad_vy wrote: www.deviationtx.com/mantisbt/view.php?id=611

It works fine. After Tx power off and power on:
FadesA = 45
FadesB = 255 (always)
FadesL = 45
FadesR = 255 (always)
Loss = 0
Holds = 1

Once more:
FadesA = 89
FadesB = 255 (always)
FadesL = 89
FadesR = 255 (always)
Loss = 0
Holds = 2

8bit datatypes are wrong anyways.
Fades do NOT end at 0xFF.
AR8000 can e.g display >255 Fades for FlightLog - see my previous postings.
AR6210 is max 255 for FlightLog (A and . RX stops sending data >255.
0xFF=max 255 fades should NOT be suppressed but displayed normally (not replaced by "0").

NOT_CONNECTED is 0xFFFF, not 255 (65535).
Multiple receiver show "not connected" antennas B, L or R depending on connected satellites.
Values A, B, L, R will be different depending on RX (e.g AR8000, 9->12CH RX) or same (e.g AR600).

Mapping code if >255 -> return 255 in trunk is wrong.
My 1st try code mapping was >9999.
Mike and Indigo re-engineered to let telemetry data values >9999 thru and handle NOT_CONNECTED + filtering packets differently.
NOT_CONNECTED looks to be different for some receivers (Spektrum, OrangeRX, LemonRX) too according to other threads.

- again a new coding concept / different incompatible source
- coding over and over again (by eventually missing some important points we where discussing endlessly before)
- topic for >255/>9999 packet values had been solved already in dsm-telemetry branch by three people + tested (NOT_CONNECTED still does unfortunately not work always for bogus telemetry data - see my videos)
- new code on different repository which is even not anymore source compatible with Indigos dsm-telemetry branch?

Why do you not at least take these well-done sub-code parts from Indigos branch without rewriting it from scratch?
Do I misunderstand your goals and new discussions?

Greetings

Thomas

Seems like telemetry alerts now take you to the telemetry config page when they go off. Ok, I can see why, but think maybe the telemetry monitor page might be a better option. Since there's no "search thread" option, I haven't checked to see why.

However, when this happens on the "Range Test" page, it's really annoying. In particular, since it leaves the range test page, it turns off the range test, which could lead you to thinking the range test was still going on. I can see that you might want to monitor radio losses during a range test, but other things are irrelevant. My initial reaction was that jumping to the telemetry page should be disabled during a range test, but maybe not.

PhracturedBlue wrote: Mwm,
I tend to agree that the page jump should likely not happen during range-test, though I am unlikely to be happy hardcoding inter-page dependencies like that into the code.

Maybe the page jump should just not happen? People using telemetry should be able to config their main page so they can easily figure out what the alert it is for. Either display the value that's causing the alert (whether it be a telemetry alert or a timer alert) on the main page, or configure page shortcuts to take them to the relevant pages?

Which adds the question - do we highlight the Tx battery level when that's causing an alert?

Just checked Indigo's latest build, deviation-devo12-v4.0.1-ee1b869 and he has implemented the hybrid Telemetry Alarm I suggest a couple of days ago.

It is a small code change that enables the first three alarms work as in the original code and the last three alarms jump to the Telemetry Monitor page. I think this is better for now, as it gives both functionalities. (I do not know all the history on this, but I assume that someone really wanted Telemetry Alarms to change to the Telemetry Monitor page.)

However, I would suggest that the alarm labels on the "Telemetry config" page be renamed to avoid confusion. At least a simple name change, that still fits with in the original label ("Alarm") footprint, like "S_Alm" and "P_Alm". (any other suggestions?)

Ultimately, once all the telemetry and protocol improvements are made and approved, it would be great to see the configuration of telemetry alarms enhanced. Independent configuration for sounds, color/highlighting, page jumps, durations, auto/manual resets, and logging (just to name a few) would give users some very cool capabilities.

Perhaps we should start a new thread on Telemetry Alarm Configuration?

That's a really good point that I had not consider. I completely agree that only simple telemetry alarm changes (if any) should be made now. Let's get the protocols and telemetry code stable and consider these other ideas separately.

PhracturedBlue wrote: Thomas,
The fact is that until very recently there wasn't a pull request that met my requirements that I could even review. Even now, Indigo's pull request can't be pulled as is. Even as late as last week, there were major issues being reported with them in both Devo and DSM, and I'm not sure the Devo issues are actually fixed. That pull request basically rewrites the callback functions for the 2 most critical protocols that Deviation supports, and I do not personally have the bandwidth to verify that it is more reliable than what we have. So that makes me very reluctant to include it. In the end, I understand the code as it is now. If all of the developers drop off the face of the earth, I know I understand how the current DSM and Devo protocols work. I do not want to give that up, so I am unlikely to include those changes until I do understand them and believe I can support them.

I have already explained why I'm taking this path, and I think we are starting to go around in circles now.

Hello PhracturedBlue, Hello all,

I am not sure if there may been some overlaps writing here in forum, old bugs shown by vlad, my posts, your answers, preparing telemetry branch for merge and latest merges pull request #43 on 04-25?! I was not aware of those pull request merges before.

I am glad you guys found a proper route to partial split the development work but being already able to commit Indigos basic dsm telemetry branch changes and enhancement and not having to really re-write everything from scratch and re-talk over every already fixed bug over again.

I can totally understand your toughts about the protocol changes and I agree with it to postpone and re-test them separately.

Pull Request #42 RangeTest:
Pull request comment about 100uw: bitbucket.org/deviationtx/deviation/pull.../add-range-test-page
Thread DSMx range test link: www.deviationtx.com/forum/3-feedback-que...ions?start=120#31014

100uw does not seem to match Spektrum 30-35m test range.
Even 60-65m has been successfully tested by me on AR6210 with Spektrum DX8 with "range test mode" / pressing trainer button.

Is it possible to make the range test page configurable to 1mw too and not hard code 100uw into the code?

Is it possible to include DSM telemetry monitor for the range-test just like Spektrum does it when you receive telemetry data?
So I need a "test mode + telemetry monitor" <100mw which is able to show DSM flightlog.


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).


Not sure about holds and framelosses (and jumping telemetry data).

Framelosses: should be <40 normally (best up to ~20), could go 50-90 on AR6210 or higher on AR600 with only one receiver antenna (antenna diversity still counts up FrameLosses)
Holds: <10 (0) expected

Bigger numbers on FrameLosses / Holds are "telemetry jumping numbers" or telemetry out-of-range errors?
Earlier in the thread there had been an explanation about telemetry out-of-range (that does NOT!!! mean the Spektrum receiver has lost connection / bind too) and possible high numbers.