Telemetry Data from LemonRX DSMX/DSM2 module

Kernowmcrae wrote: The persistent 'binding in progress, please wait' message is still very much present - as I mentioned before, it can sit for over a minute at '0 seconds remaining - that can't be right!

Is this the behavior you're describing? DSM binding procedure doesn't end until you move the cyclic because of the way the protocol sets failsafe values.

Some testing is required

I suspect LemonRX uses most significant bit for sign +/-, that's why we see the number 32768 (representing -0 'negative zero'). Spectrum in there telemetry data use -0 to represent a 'Not connected' sensor. Deviation should display this as 0 in the inverted colour.

However a negative integer in C on this hardware would use what's called one's compliment; where the negative representation of a number is the same number with all bits flipped, so -0 is 0xFFFF (65535).

I need your help to confirm this. I want to see negative values (eg. altitude, temperature). If I'm right negative values will be values > 32768, so when going from positive to negative it will suddenly change from a small value to a value slightly larger than 32768.

First I need someone to test LemonRX for negative values on telemetry, and second for people to test negative values on other hardware. If you're able to test one or the other that would be most helpful, thank you.

Kernowmcrae wrote: I've bound with telemetry enabled, and no glitchy servos or random flashes from the rx.

Has this definitely improved? I've kept the change for now..., really need others to test and comment. If there's no definite improvement I will restore it back to what it was previously.

Kernowmcrae wrote: I've also dropped the signal strength for you indigo, and have got varying values in the fades box - ranging from 100 (which is at full signal) to 0, to 65532 when I had barely any control. It also turned red at one point, with a value of 0 displayed.

Sounds different to other brands, but also sounds like it's working correctly. The value 65532 was probably 65535 = telemetry range warning.

Kernowmcrae wrote: One final thing, Am I right in saying the battery labels are the wrong way round?

Yes, my mistake. That is now fixed.

The 'not connected' sensor values (32768) has been fixed. These were sometimes displaying as normal values instead of always in red. This is now fixed.

hexfet wrote: Is this the behavior you're describing? DSM binding procedure doesn't end until you move the cyclic because of the way the protocol sets failsafe values.

The receivers I have been using have failsafe buttons on their sides, which you depress once the bind process is complete, and the bind plug is still in - I don't think it's linked to the persistent binding message. I've had the 'bound' chime sound minutes after the menu has disappeared!

@ Indigo, well done on the changes - I'm sure the Lemonrx manual states what data the telemetry module does and does not send, here's the excerpt - tried to upload the PDF but the forum won't allow it?

"Signal
Indicator
The Lemon system does not report Frame Losses (F) and Holds (H) since this is data generated only by
Spektrum systems. Nor does Lemon report individual packet losses on up to four separate
receivers/satellites (A, B, L and R) as Spektrum does.
However the Lemon unit does use the “A” display for a
Signal Indicator value. This is calculated from the number
of packets lost in transmission. A reading of 100 means
that no packets have been lost in transmission, while
smaller numbers indicate losses.
The value is based on the number of packets received
about every half second. In versions of the Lemon unit to
date, it is of limited use and tends to give readings that
range between 85 and 100. Note that, as with some other
telemetry systems, if the data communication link is broken, the last known Signal Indicator value will stay
on the screen until data communication is restored.3
As noted previously, the B, L and R satellite receiver fields are not used by the Lemon system, nor are the
F (Frame loss) and H (Hold) fields. Receiver voltage is displayed on the same screen as the Signal
Strength indicator."

HOLY FONTS BATMAN



I gave the last version you posted a spin Indigo, and something's changed in the font size and bold settings.. my fonts are going mad!



I've attached a couple of screen prints to show what I mean. I'd assume that one of the nightlies contained experimental font changes that snuck in there?

I thought this may have been down to me flashing the firmware without the library, so tried with the lib provided with the same (entertaining) results.

The labels are the right way round on RX voltage and Battery, but i'm now seeing:

no red on GPS data that isn't getting any data -

Battery Pack voltage appears red constantly

Temp appears red constantly



I Feel like i'm making things worse by interfering!

Looks like I really messed up that last one.

Try this one:
bitbucket.org/Indigo1/deviation/downloads

Looks like I really messed up that last one.

The fonts going mad (showing single character) is the result of text being right justified. Caused by me not restoring the 'default font' back to left justified.

I also found problem with vertical alignment of labels on Datalog page (Devo6/8/12) caused by me doing a major rewrite of "label.c" and failing to retain an obscure bit of the original functionality.

Anyway, all should now be fixed:
bitbucket.org/Indigo1/deviation/downloads

No not at all, you're helping by road testing my changes.

It's very hard to test telemetry without loading it onto a tx. Although I tested the right justified fonts using the emulator, I didn't change to other screens to see there was a problem.

The fonts going mad (showing single character) was the result of text being right justified. Caused by me not restoring the 'default font' back to left justified.

I also found problem with vertical alignment of labels on Datalog page (Devo6/8/12) caused by me doing a major rewrite of "label.c" and failing to retain a bit of the original functionality.

Anyway, all should now be fixed: bitbucket.org/Indigo1/deviation/downloads

Hopefully, the right boxes will now appear red.

I tested a pull of your dsm-telemetry branch through 4b39c378853e. You've made a commit since then. It also included my not-yet-finished new toggle code. All this was on a Devo 10, as the toggle code isn't finished for color screens. If you would like testing on a color screen, let me know and I'll try and get something done in the next day or so.

First test was with a Blade 200SRX, so it's got a Spektrum Rx with telemetry, but it isn't transmitting RSSI data. It uses the ABFLRH signals to communicate either vibration data or gyro setting info. That worked much better than either the PBR nighlies or the changes that were in my original pull request.

I also noticed that if I bind in DSMX mode with telemetry enabled, the Rx light flickers after the bind, which I believe indicates a poor connection. In DSMX mode with telemetry disabled or DSM2 mode either way, I get a solid light. I believe this is an change in the DSM2 mode with telemetry behavior, but I'm not positive. If I bind in DSMX mode with telemetry disabled, I still get a solid light if I enable telemetry. There's a thread talking about this behavior with the 7E.

I then dug out the spare parts, and tested with both an OrangeRX or LemonRX Rx, a TM1000 or TM1100 Spektrum telemetry module, and an OrangeRx or Spektrum SPM9645 satellite Rx. Those two Rx's are both DSM2, so that's all I could look at. You can thank HH's refusal to admit that the GB200 didn't work as advertised for the odd collection of Rx bits.

Anyway, I got the same behavior in all 8 configurations. Rx voltage was fine. F, H & R were all 0's. A & L were pegged at 32677 and 32768, respectively. Since those two Rx's don't have data ports, this isn't really unexpected, but the difference is odd. Battery voltage would stick at the Battery level I got when I first applied power to the Rx. It was also always rendered in the alarm/no connection font. The battery voltage ×100 showed up in the B slot, which is clearly wrong.

Hi team, evening. I've flashed the latest version tonight- fonts are back to normal, things are looking nice again. It appears that the red bits are red when they should be, although the battery voltage labels appear the wrong way round again!

I think we're pretty much there though.

Thanks in advance Indigo!!

Thanks for testing this.

mwm wrote: I also noticed that if I bind in DSMX mode with telemetry enabled, the Rx light flickers after the bind, which I believe indicates a poor connection. In DSMX mode with telemetry disabled or DSM2 mode either way, I get a solid light. I believe this is an change in the DSM2 mode with telemetry behavior, but I'm not positive. If I bind in DSMX mode with telemetry disabled, I still get a solid light if I enable telemetry. There's a thread talking about this behavior with the 7E.

The remedy should be binding with 8 channels. Can you please try doing that?
Is there a way to automatically detect a poor bind and then rebind using the other parameter. Maybe we should just change the Telemetry Off/On option for DSMX to Off/On[A]/On, because when telemetry is enabled with < 8 channels, some tx's bind best using code 0xa2 but others need code 0xb2 instead.

mwm wrote: Anyway, I got the same behavior in all 8 configurations. Rx voltage was fine. F, H & R were all 0's. A & L were pegged at 32677 and 32768, respectively. Since those two Rx's don't have data ports, this isn't really unexpected, but the difference is odd. Battery voltage would stick at the Battery level I got when I first applied power to the Rx. It was also always rendered in the alarm/no connection font. The battery voltage ×100 showed up in the B slot, which is clearly wrong.

I've made changes which I hope will rectify this. Fingers crossed

@Kernowmcrae - Thanks for the photo, it's good to see it almost correct.

Today's version has more checks to detect "not connected", I wonder if RPM will now show in red. The number 32768 should now be replaced with zero.

Hi Indigo and the rest, I'm pleased to let you know we've got some progress, as far as the main points that bothered me are concerned, I think we're pretty much there.

One slightly odd behavior is that the altitude jumps around a little - anything less than 0 feet and I get a red indicator, which is probably part of the latest changes, but i've also had a number in the region of -2500-3000 ish appear?

I've also tried to load into my Devo 10 the latest telemetry firmware, and it boots, but if I try to enter the main menu, the software draws the 'main menu' text, and the scroll bar on the right, but nothing else - the unit then restarts - just something to mention for the next round of fiddling!

I've also noticed something - on the telemetry page on my 12s, the altitude value is only displayed for the GPS section, which means there's nowhere to display the altitude value from my telemetry units barometer - the only way is to add a box to my model page and display it there. There's plenty of space on the telemetry screen to add another small box marked Alt, and maybe change the section below to GPS Altitude?

thanks again!

almost forgot, fades and holds are now being displayed as red zeros too.

I'm using a Devo10 and it works fine.

In reference to the official releases: www.deviationtx.com/repository/Deviation-Releases/

If your upgrading from Nightly Builds version 4.0.1-92e1705 (Aug 2014) or later unofficial nightly's, then you only need to flash firmware using the DFU file.

But if you're upgrading from something much earlier like the Official Release version Deviation v4.0.1 (Jan 2014) then you will need to put your transmitter into USB mode (power on while holding right button ENT) and copy on the system files. In my Devo10 download will be a filesystem folder and inside that a Devo10 folder. The contents of Devo10 is what we're after. Copy all files and folders except the modelico and models folders - you don't want to loose you model icons or model files. You should keep a backup of these folders somewhere.
. You probably also want to keep the files hardware.ini (hardware mods file) and tx.ini (knobs & sticks calibration file).
Update the system files and your Devo10 should work fine like mine.

oops, that'll be a case of RTFI! (Read the flippin instructions) - flashed it this morning, works fine.

Thanks again, I'll look forward to the next update.

Next update is now available here .

Revised handling of negative values and detection of "not available" values - those shown in red (or inverted on B/W displays)

Added Altitude-Max
Added support for sensors:

RX Pack Cap sensor (SPMA9604)

Flight Pack Cap sensor (SPMA9605)

Variometer sensor (SPMA9589)

Telemetry screen still only shows: Flight Log values and GPS sensor values

Currently the only way to display data from other sensors is to add a box to your model page and display it there.

Hi Indigo, tested this one out tonight, and the barometer altitude value that appears is -3276, not sure if that's of use to work out what's going on? Fades B L R loss and holds fluctuate now between red and white, all the while showing zero - obviously my module doesn't broadcast the data, hence the zero value, but I thought it was interesting that the colour would change. I tried to test if I cause a repeatable pattern of causing it to go red, but it appears completely random.

Hope this is useful!

Very useful, thank you.

I had pruned away as much code as I thought I could in order to make it fit on the Devo7e. which is why I keep swapping RxV and Bat labels.

I was about to upload new version and saw your post. Then pretty much restored related code back to what it was.

This new version includes a 2nd Telemetry "On" option for those who have binding problems or flashing led on rx.

I hope this one works flawlessly: bitbucket.org/Indigo1/deviation/downloads

Hi Indigo, evening - I did reply earlier but I think it must have got lost in the site being down.

I've tested the code that you've put out on the 15th, and have still got the alternating altitude figure from the barometer even though them model is static- ranging from 0.5 to -3276. I have also noticed that the altitude is always displayed in meters, regardless of whether meters or feet are selected? I don't know if this is linked somehow to the -3276 number or not!

The red 0 values are still present, and still fluctuate between red and white- it's not a problem to me, but thought i'd better mention it.

Are there any parts you'd like me to specifically test?

Thanks,

I'm working on major upgrade to the DSM protocol. I've converted all the 8bit code to 16bit and some to 32bit. Ideally it would all be 32bit.
It's not currently working, but I should have it sorted by Saturday.