Telemetry test page rework

Right now, the telemetry test page is sort of ad-hoc: we actually have at least 3 different versions, depending on the protocol (DSM, FrSky and Devo). Some of them display more than one page. We've had to cut some of the telemetry out to fit on the 7E, and have had at least one new telemetry protocol system abandoned because of the 7E space issues.

I'm thinking that it's a test page, so we shouldn't worry so much about layout. Make sure we can put any values we want on the main page, and then get the rest in in some kind of order that makes it possible to find them.

For instance, do something like the new channel monitors page, where we check to see if a telemetry value has been received, and only display it if it has. We'd have to display label & value for each one, so possibly having units as well. This would also mean we could merge a lot of the telemetry values. For instance, we currently have at least one voltage display on each of the three protocols, so we could just have N voltages, where N is whichever is larger, and then the protocols could slot them in where it made sense for them. Or we could label them: Rx voltage, Flight pack voltage, CellN (N going from 1 to 6, or whatever) to be a bit more explicit. The GPS stuff is already partly done this way.

Just wanted to start a discussion on this issue.

Hi Mike,

Please don't forget about Spektrum DX8/DX9/DX18 Airware telemetry page(s).

We are already missing Spektrum Airwares min/max values for RX voltage and lipo flightpack voltage, height, etc.
On Spektrum Airware you can (well you must!) reset the values when you plug in a battery with the CLEAR button to start min/max evaluation and reset odd max values (from plugging in).

I believe there are more telemetry pages in Spektrum Airware (you can navigate throw with the TX roller button right) as they are in DeviationTX?

The other thing is the capacity sensor which you want to support 1-6s/12s/14s values.
Probably it makes no sense to have 12 fields displayed, or maybe on a special page? Not sure... Have not used that so far.


Spektrum FlightLog:
Don't forget about Spektrum FlightLog A, B, L, R, FrameLosses, Holds.
All need to be really really really visible on ONE telemetry FlightLog page!!

You either need that Flightlog / telemetry (test) page in-flight when actually you are first doing range test flights.
The other reason is for ground range tests.

All these FlightLog values need to be shown.
On Spektrum Airware transmitters you select the menu "RangeTest" and press down the trainer button (or not).
If you have a TM1000 connected, the RangeTest page actually shows this Telemetry FlightLog page.
Of course RangeTest reduces the power output.

We already have found out that DeviationTX "RangeTest" shall be have a customizable output power.
It is IMHO !not! the right way just to limit it to fixed 100uw.

My Spektrum ground range tests with genuine Spektrum AR6210/AR8000 and TM1000 receivers had proven that I am actually looking for 1mw output power, checking for 30-35m and max ~60m distance to original Spektrum gears (e.g Spektrum DX8).

I am missing this limited "RangeTest" option to also (temporarily) switch from 100mw to 100uw/300uw/1mw in DeviationTX firmware without having to permanent change the model protocol setup (it's true - you forget to reset it back to 100mw afterwards!!!).
I personally very much welcome your new features "RangeTest".


As FrSky and DEVO do not support these Spektrum FlightLog fields 1:1 (e.g RSSI on FrSky, DEVO missing Fades A/B/L/R, etc.) I see actually no way to remove the telemetry test pages as they are now?!?

However good idea of you to be (additionally) able to display 1-x choosen telemetry values on the main screen (configurable).
I am not sure if this is yet fully supported. Have not tried it. Probably it is already.


Full Spektrum Telemetry / FlightLog might not be that important for the smaller Devo7E which is almost always used to fly toy quads / Micro CP helis.
So I am fine to make some special Devo7E telemetry pages or leave them out on compile as you explained earlier.
When you look at Blade 200SRX, 230s, 180CFX, 200QX they only support Spektrum FlightLog FrameLosses/Holds + RX V anyway (not even flightpack voltage or Fades).

Spektrum Telemetry FlightLog is something you want to have for full transmitters like Devo10, 12s, 8s, etc. to have full Spektrum receiver support and be able to fly bigger planes / helis / quads.

We really need this feature to verify ongoing DSM protocol / filter code changes on nightyl-builds and Indigos further test builds.

I am not using DEVO protocol and telemetry so I have no experience with this.


Summary:
I want DeviationTX firmware to fully support Spektrum DSM Telemetry / FlightLog 1:1 - as best it can - with as many as telemetry pages as in original Airware HH USA firmware.


FrSky:
How many "FlightLog" values for range tests - besides RSSI - do we need and are supported (when comparing FrSky to Spektrum DSM)?

My 2cents

Thomas

No, I'm not forgetting that Spektrum is different when it comes to signal indicators. That's not really any different than any other telemetry. Devo telemetry currently doesn't have any signal strength data, and I'd no more lose the Spektrum values because it has a different set than FrSky than I would lose the FrSky values because the Devo doesn't have any.

My idea (which I in truth haven't really thought out) is to put them in some sane order, and then only display those that we've seen. So if you're using a DSM system, you'd never receive the FrSky RSSI values, so those would never be displayed. And vice versa. Like I said earlier, think of the channel value display page: if a channel doesn't have a mixer, it's value isn't displayed. This how you deal with the cell voltages: we only display as many as we get. So you only get twelve fields if you have a 12S battery.

It will mean you can't create a compact display with column labels or tailor the display to really short labels, which might make some things harder to deal with. I'm pretty sure we can get all the DSM flightlog data on one page, though.

While this might seem like wasteful, it isn't because we already have code/storage/etc. to deal with all those values. The only part of the telemetry that's not always resident on the 7E is handling telemetry packets in the protocol file. The rest of it is always there.

It isn't really going to address the issue of missing sensors at all. Just change the test page so we don't have to have a new one for every protocol that we want to support telemetry. Well, we don't do that now - some of the other protocols with only one or two values reuse the DSM or Devo test pages. Which I can see could be really confusing.

The signal strength stuff isn't much of a win, because right now they are all unique. I haven't looked at the advanced Hubsan telemetry stuff, but think it has RSSI - but we can't really can't add anything to the 7E. The saving is with things that are common. We have at least 8 voltage fields now (DSM has all kinds of voltages, so it's not clear how many beyond two to count for this) that could be reduced to 3, 7 temperatures that could be reduced to 4, 5 RPMs to 2 (just rough numbers from a quick scan), and so on. And the current FrSky telemetry stuff is missing most of the supported sensors, which issue is currently being addressed with the FrSky X protocol.

I think handling telemetry values that are the same across protocols should be consolidated the same as gps. This might involve some scaling or mapping to a common representation and naming. Perhaps there's some way to map the different signal strength telemetry to a common generic good/bad/panic indicator. The sensors unique to particular protocols would always be available.

I like the idea of only displaying active sensors, but wonder about values moving to different places as you change aircraft (or maybe in flight if you have an intermittent sensor).

I think the moving issue can be mitigated by keeping the set of sensors in a fixed order. If we group them by type and not protocol, so that fit instance the RSSI and flight log data are together, even if they are never used on the same model, then motion won't be too bad. It'll certainly be better than the current situation, where the telemetry screen layout changes between models.

The Idea of the automatic Telemetry Test Page sounds good. Yes, it is a Test Page and the Telemetry Display with Custom Boxes on the Main Screen sounds good to !
On the 7e i think is better to cut the Test Page to get some Space for the Telemetry on the Main Screen.

On Planes and Quads it is not good to watch long Time the Telemetry on Display, here is better to get the needed Info with 3-4 Big Boxes on the Main Screen .
And some new Beep Sounds for the Alarms to sort it out when Flying a Model ( Fast Beep, Long beep, Long slow Beep etc.) . So every Telemetry on the Main Screen can have an individual Beep Sound on Alarm ( user Selectable )

my 2 ct.

Alex

Have you already tried that?

How do you want to put
- (temp)
[- RX voltage: only important for telemetry alarm and showing value]
- flight pack voltage
[- FrameLosses: only important for telemetry alarm and showing value]
[- Holds: only important for telemetry alarm and showing value]]

on the main screen for Spektrum DSMx?

And then you are still missing
- Fades A
- Fades B
- Fades L
- Fades R

while for Ar6210 or AR8000 only FadesA+B or FadesA+L makes sense when others are NOT_CONNECTED. So at least +2 Fades.


Indigo introduced DSM telemetry code enhancements for jumping for telemetry page on telemetry alarms for first 3 fields.


I would configure jumping alarms for at least:
- RX voltage
- FrameLosses
- Holds

Beeps only for flightpack voltage.
Yes it makes sense to have THIS value on the main page so you can easily see it without jumping telemetry alarms or having to switch main <-> telemetry pages.

I don't really think it makes sense to put ALL available telemetry fields onto the main screen???

Where is the place on the main screen on the Devo 10 with the smaller display??
Can you show pictures?

Too bad there can't be a hardware mod for a bigger DX8/DX9/DX18 display for the Devos or a newer transmitter to run DeviationTX onto.

Thomas

I haven't tried this since I want to discuss it first. You can already use the main page editor to put most telemetry values on the main screen. Of course, you do have limited space, so figuring out what you want could be a problem. But that's left in the hands of the user, where it belongs. The only change there this proposal would have is making sure all the telemetry values are available to put on the main page.

The "jump to telemetry page" thing was buggy and a pita. Since you can have the values you care about on the main page, jumping to a different page is just confusing. I think indigo removed it in later build.

My wishes here:
Event counter event storage (not a full log needed for me), set a threshold for any telemetry value and we count those events, and can set alarm, and type of alarm on off or sound buzzer sequence for that event. In addition by default store min and max value for each telemetry field.

Lipo alarm for the lowest individual cell voltage. So if we have 6 cells, if one of the cell below threshold (f.i 3v4) set alarm.
Indeed all other thing such as min max current, mah used etc but indeed all future wishes...
Maybe can alos think of an unbalance lipo alarm or record, log show the min/max difference in cell voltage.

All counters and min max etc values may be reset after on/off of tx.

mwm wrote: The "jump to telemetry page" thing was buggy and a pita. Since you can have the values you care about on the main page, jumping to a different page is just confusing. I think indigo removed it in later build.

I still could not try his latest test build version
Removed? Really? Oh, not that I had known. Was that stated by him in DSM telemetry support thread?


The weird thing about telemetry (and Spektrum DX8 voiceless telemetry was no better) is that for any telemetry alarm you hear the same beep sound.


For the flight pack voltage I am just using vibration. There might be still FALSE telemetry alarms - temp out of telemetry range. I believe I saw that once on my testing of nightly build fcd0669, will re-test as soon as possible with newer versions and Indigos (well, probably not on the 4503D).

I believe this was one of the reasons Indigo added the jumping feature where the FlightLog field flickered? I liked it. May not be suitable for all circumstances but nice for test range flights...
You immediately saw what telemetry value has the alarm issue.

If you just put a sub-set of DSM telemetry values on the main page (I still can not think to put all of them to main page) it may be very nice to add this bordering / flickering value alarm feature too?
Have not tested too much on this so I am not sure if it is / was supported or how it behaved for main page.

Thomas

Thanks for tip FDR. I believe somewhere was even a thread for that.

Maybe it would be nice to add some configuration sound choosers for the telemetry thing where you configure value max alarms?

BTW: It's the same is for >=1 safety switches (configuration not 1:1 supported like TH, flight-mode, etc.).
Works as a charm for multiple switches once you DIRECTLY edit the model.ini safety section.

Yes, you can edit the model.ini, but within the GUI and not having to connect by USB and edit directly may be nice too.

We also need to add / further improve DSM Hold delta alarms: www.rc-network.de/forum/showthread.php/2...ewfull=1#post3952180
I will add a request / suggestion in English to DSM telemetry support thread at a later time.
This may reduce false DSM telemetry alarms for holds, but does not so for telemetry temporarily out of range warnings.

Just an idea- would it be possible to have an automatic resetting (maybe not the best term for what I'm about to describe) counter on flightlog data?
I have holds at >1 (and it almost never goes off) and fades at >100 but what would really be useful is to have an alarm trigger any time say e.g. the fades value rose >20 in a few seconds, regardless of what it was. So say you're flying around and the fade counter has slowly rose to 55 then all the sudden a real problem arises and the fades counter jumps from 30 to 58 in a few seconds, that would be a good indicator of a major issue but at only 58 it's still well below my alarm trigger of 100.

Holds >0 is the right alarm configuration, not Holds>1.
The re-alarming was implemented by Indigo / working by an hold (fixed) increment by 1 = re-alarm.

For FrameLosses e.g >40 IMHO it is implemented AFAIK (exchange with Indigo) that the configured number will take presence for re-alarming trigger, so new more 40 FrameLosses = re-alarm.
You have to give the new alarm your OK with ENT until next re-alarming. Next 40 F.

Same would work with Fades >80, but IMHO a re-alarming Fades trigger is not useful, once dailed-in (range testing and comparing A/B/L/R). I would just read the numbers on ground or in-flight WITHOUT any alarming to compare antennas qualities.


What is actually missing - you are hunting for - is the DELTA in xx seconds on FrameLosses for every re-alarming event.
Yes, we need to change / improve that code a bit more to take xx delta in yy seconds into consideration as I tried to explain with link to German description in post #44781 and talk to Mukenukem.
He already gave me two suggestions and the background to it.
We got the chance to do it right - Spektrum Airware has not implemented FrameLoss counter right as to Mukenukem.

FrameLosses >40 (e.g 50-90) is NOT enough for a single alarm or re-alam, as F might increase slowly in xx minutes.
That would be OK. No holds necessarily. No LOS. No crashes.
Besides the fact that F was most of the times either 0 or <20-40 on my Blade 4503D heli flight tests....

Thomas

We are (naturally) drifting off topic here. I'm not proposing any changes to the telemetry or alarms behavior here. While I do have plans for that - to accommodate the audio player feature - that's not what this thread is about. So asking for those to be changed here is sort of pointless. When I get back to that, I'll start or reopen the appropriate discussion for them.

TH, you seem to be confused about the main page display. This is controlled by the user, not the developers. You can add whatever telemetry values you want to the main page via the main page config menu (except on the 7E, which is missing that feature, though the emulator has it). I regularly put RSSI and Rx Voltage (which I find very useful as most of my FrSky drones don't have a flight pack) on the main page. The only change beyond layout formatting I'm considering here is making sure that ALL the telemetry values can be put into boxes on the main page, which may not be the case just yet. I believe that's a requirement if we go away from protocol-specific telemetry test pages.

may be some Changes at the 7E Main Screen.
- The Picture for the Model is not bad, but a change to big Letters like Plane,Quad, Heli or a User defined Word to save Memory for the Telemetry.
- Or no Words for the Type. I think the Model name is big enough to identify the Memory Name with the Plane
- The Trim Display Sliders should moved to the Border of the Screen to free some Space for the Telemetry Numbers, to use the center of the Display (3X3,4X4 or 1X3 with very big Numbers).

my 2 ct.

Alexandro wrote: may be some Changes at the 7E Main Screen.
- The Picture for the Model is not bad, but a change to big Letters like Plane,Quad, Heli or a User defined Word to save Memory for the Telemetry.
- Or no Words for the Type. I think the Model name is big enough to identify the Memory Name with the Plane
- The Trim Display Sliders should moved to the Border of the Screen to free some Space for the Telemetry Numbers, to use the center of the Display (3X3,4X4 or 1X3 with very big Numbers).

my 2 ct.

Well, this thread is about the telemetry screen, not the main screen, so your requests won't get the appropriate attention here.

And in any case, the entire main screen is user-definable. Because of that, none of the changes you suggest will make any difference in the ROM size on the 7E, and not be a help. If you want to make them yourself, you'll have to use something other than the 7E, as the code to edit the main page was removed to save space. The easy way is to copy your model.ini file to your desktop, use the 7E emulator to edit the main page (the emulator in the nightly build has it), then save it and copy it back to the 7E. You can also edit it by hand, but to me that's a PITA when you're trying to lay out a GUI.

Sorry then i translated i wrong.

WRT 7E image size - what happened to attempts to write a smaller bootloader (as far as I understand, current one takes 12K)?