DSM Telemetry support

The Telemetry data display includes Altitude and Speed (ground speed) from GPS sensor.

I'm thinking that data from a specialised barometric altimeter should replace GPS Altitude and data from a specialised speed sensor should replace GPS Speed.

Does anyone have any reason why these values should not be overridden by another sensor? If not I will go ahead and update the code to override these 2 values.

Calibrating barometric altimeter
I guess, if GPS Altitude is available then calibrate altimeter from it. But what if no GPS sensor?
Should the initial value read become the "adjustment value" so that the displayed value is always zero initially? So then displayed value is difference from starting value.

Why do you want to replace it? Looking through the HH web site, you get two different values from them.

The GPS systems gives you altitude above mean sea level and ground speed. The various specialized sensors give you altitude above ground level and air speed. They aren't the same things, and I can see a reasons for wanting all of them. At the very least, they should both be available for alarms & main page display boxes. Given how much data shows up in a GPS sensor, I can't see how adding a couple more would make much difference on the telemetry display page.

As for barometer calibration - I suspect that depends on the sensor. The Spektrum ones I looked required no user calibration. Are their Tx's doing that for the user, so we need to duplicate it? If so, say do what the Spektrum ones do, which is to record the first reading as ground level. Copying it from the GPS data would convert your barometer altitude from AGL to AMSL, making it a copy of the the GPS data modulo errors. Keeping AGL is almost certainly more useful. If nothing else, changing the behavior of the barometer readout when you add a GPS system seems counterintuitive.

Thank you, that answers a lot. No special handling required = less work & more play

With so many different Telemetry sensors available and many combinations of sensors, I think each sensor should present its data within a separate frame; with name of sensor as the frames title eg. GPS, GForce, PowerBox, Variometer, etc.

Each frame would have different width x height; and would either be visible or hidden depending on whether or not some telemetry data has been received. Then some smart display logic would need to look at what frames are visible and workout how to best arrange and evenly space them within the bounds of the LCD screen.

On the Devo10/7e they would appear in just one long scrollable list and would look similar to the tx configure page.

I've just noticed that there is no code to handle a negative GPS Altitude in DSMX protocol.

Here is the code:
The sign for Latitude and sign for Longitude is stored in packet[15], would the sign for Altitude also be stored in packet[15]??? I'm guessing it will be in the 4th bit

Can someone please find the answer for me?

Thank you.

The 3rd post in this thread: www.rcgroups.com/forums/showthread.php?t=1725173

shows some VB code with AltitudeSign coming from MSbit of 2nd altitude number and a valid range of +/- 1000 m/s. I'm inclined to believe it because I've found that other signed numbers in DSM Telemetry use that same bit for the sign.

Yes, you're right, there is no bcd encoding so that's not the gps altitude. Thanks.

Is this issue you reported still current? Should I remove second part of patch?
Devo 7e - voltage telemetry unstable

cmpang wrote: I confirm that Indigo's fix ON DSM2/X for RF lock out under Telemetry ON works great.

Nevertheless, seems similar RF lock out on DEVO protocol has not been addressed so far.

cmPang

Thank you cmPang. I have now applied the same change to DEVO protocol. Can some Devo people please test this and report back. Thanks
bitbucket.org/Indigo1/deviation/downloads

And I'll soon upload a second version in case this first one doesn't work at all.

Indigo wrote: Thank you cmPang. I have now applied the same change to DEVO protocol. Can some Devo people please test this and report back. Thanks
bitbucket.org/Indigo1/deviation/downloads

And I'll soon upload a second version in case this first one doesn't work at all.

Hi Indigo,

I've just done a quick test of your version "Devo10-devo2-dsm-telemetry.zip" 01389e8 on Devo10.
I can confirm that #533 is fixed.
I want to do more tests especially about #525 , but that will take some time, so please be patient. See 21247

Update crash:
- load new model
- goto "1. model menu" - "2. Telemetry config"
=> reboot

Greetings
Manfred

Hi, thanks for testing this.

linux-user wrote: Update crash:
- load new model
- goto "1. model menu" - "2. Telemetry config"
=> reboot

I works fine for me, so I'm thinking it must be something in your model file.
Being able to reproduce bugs make them much easier to find.

Can you please post the model file?

Indigo wrote: Hi, thanks for testing this.

linux-user wrote: Update crash:
- load new model
- goto "1. model menu" - "2. Telemetry config"
=> reboot

I works fine for me, so I'm thinking it must be something in your model file.
Being able to reproduce bugs make them much easier to find.

Can you please post the model file?

Uhh, I am afraid that won't help, as it happens with the files in your *.zip.

I have an Idea:
I am using small fonts from sbstnp (/media/config.ini)

Update:
no crash with standard (big) font.

Greetings
Manfred

Hi,

I've found some minor issues with Devo telemetry so far.
1.) datalog doesn't seem to work anymore, which is a pity as most of my former tests rely on it. (at least datalog2csv.py can't read it)
Very minor:
2.) I've tested telemetry with MiniCP which only supports Temp1 and Volt2.
In telemetry monitor (on page1) all the other values are shown as 0.
Shouldn't the non available values be displayed inverted as is the case with the GPS-values (on page2)?

A big thank you, they were good finds.

A new version is now available for download.

All issues fixed (I hope)

Hi,
I've only updated the dfu-file (version cedb50d). Hope this is OK.

First the good news:
The crash is fixed.

And now the bad news:
1.) previous-version (01389e8): I left the TX running over night without bound RX.
- plugged in heli this mornig, but didn't bind. I think it should with fixed-ID.
- needed to power-cycle TX to bind RX.

2.) current-version (cedb50d) Telemetry monitor:
- Temp2, Temp3, Temp4 are inverted as is expected - good.
- Volt1, Volt3, RPM1, RPM2 still showed "0", although these aren't supported by the RX.
- even worse: one time I saw random numbers of (I think) all values.

3.) datalog still isn't working for me.
Could it be, this isn't working any more since a long time?

Updating the dfu-file only is fine.

1.) Is this a new problem? I don't think my change would effect binding in any way.

2.) That's good, I only upgraded how temp was handled. Volt and RPM appears to be 16bit values but only 8 bit is read. It looks wrong but it must be producing correct values, so I left it. Random numbers of all values - I think I know the cause of that.

3.) The datalog I looked at all changes and found a mistake with one, fixed it and hoped that would be fix the datalog not working. Ok, I need to look into further.

It's getting late here, so I'll leave this until tomorrow.

Thanks for testing and providing feedback.

linux-user wrote: 1.) previous-version (01389e8): I left the TX running over night without bound RX.
- plugged in heli this mornig, but didn't bind. I think it should with fixed-ID.
- needed to power-cycle TX to bind RX.

Indigo wrote: 1.) Is this a new problem? I don't think my change would effect binding in any way.

Hi,
well, I am afraid I can't reproduce this, and I don't think that you have introduced this issue. This may be related to #525
It is more, that I hoped that your changes have prevented this "lock out".

I have uploaded a new version

I have added to Devo protocol the same change I made to DSM protocol which I think will fix #525.

This release (dfu-file only) is latest nightly merged with latest telemetry.

I have uploaded a new version which I think will fix #525.

This release (dfu-file only) is latest nightly merged with latest telemetry.