Devo 12S DSMX Range and Telemetry Questions

I'm currently working on DSMX Telemetry problems with Thomas Heiss.

The problems are caused by data integrity issues in receiving telemetry data .

Deviation could also be transmitting occasional bad packets, so I have also added a fix for #594: Data integrity of Channels array

Anyway it would be good to have a number of people test this. Downloads are available here:
bitbucket.org/Indigo1/deviation/downloads

aMax wrote: hardware.c/2014-05-21/
Allow use of txid override on Devo7e. Devo7e will always be in telemetry mode now

Reversing that change (ie. Enabling On/Off for telemetry mode on Devo7e), makes the module file size too large (max size is 4KB). However, I found another way to reduce code size so Telemetry On/Off should now work.

Nice, ...switching off by default?

BTW , the former module size is 26 bytes larger than the size of the latest module.

Thanks Dude.

All new protocols, no buzzing and telemetry switching again(DMS2/DMSX), nice.
Will test more.

a big thanks Indigo..

Oop... power output stays at default. Not able to change ... (on both DSM and Devo protocol)

cmPang

On my 7e the power setting is working as normal.

Edit: Did you copy your old tx & hardware.ini back?

I've copied the whole new file system other than the tx.ini

Edit your hardware.ini, the PA is set to zero.

yep.. it works now

Ok, please report your experience with the build and DSMX.
You may find more occasions than me at the moment (bad weather).
I´m eagerly interested in this.(quad on the bench)

1. It is 1:46 am here in Hong Kong and so I can only perform a bench check. Setting to 100uW all seems fine. Orange LED blink at times but not frequent. Looks to be on par with my Devo receivers.

2. Sadly the 2x3 switches are gone in this build

Will perform longer range test tomorrow..

cmPang

Then you have done your switches in a different way.
...3x2 sitches are working!
They are displayed at stick input and channel output....and values change.

....hardware.ini..???

left my 7e overnight at 300uW, my orange receiver only get one red flash ...



cmPang

further test tonight.

Setting to 1mW output, the receiving signal performance is on par with the trusty Devo protocol. This comparison is based on NO red led lights up in the receiver. It does get infrequent orange led flashing tough.


cmPang

Another test with telemetry ON. Surprisingly, get the same result as with telemetry OFF above.

So would Indigo please comment, or other than get the switching function to work, you have also fixed some coding regarding telemetry?

cmPang

The received telemetry data is copied to an array where it is then used. Some values (fades,frameloss,holds) were being stored as 8bit so maximum value was 255. Thomas fixed that and made maximum 9999, but we were still getting wrong values displayed and losses going quickly to 9999. Losses were being shown as FadesL and holds as ?FadesA? caused by values overwriting adjacent memory spaces due to 32bit value stored into 16bit slot. Could these wrong fade values be triggering a channel change? This problem was with only the dsm2/dsmx protocol. This is what we fixed.

I also removed all the 16bit <-> 32bit data type conversions from stick inputs through mixer to channel outputs. It's now all 32bit, the natural data type of the 32bit CPU. With all the unecessary data type conversions removed the code size is reduced and will run faster.

Here is a summary of other changes made:

• Enable telemetry On/Off for Devo7e using dsm2/dsmx protocol
• Telemetry monitor enhancements:

1. Display automatically when each alarm sounds for first time
2. While displayed make ENT or EXT button mute the alarm
3. Make the alarm value flash
4. Make alarm self reset (eg. voltage drops momentarily)
5. Display volts to 2 decimal places when value < 10V.

Add Telemetry config enhancements:

1. >= really does mean >= unless value is zero. Zero will never trigger an alarm state.
2. Volts configurable to 2 decimal places.
3. RPM increment changed from 10 to 50.

[/ul]
The telemetry data is stored on rx and current values are constantly being sent back to the tx. You can verify this by leaving rx on and turning tx off and then on again. The same telemetry values will appear with +1 for holds. Same if you go out of range and loose binding, when you come back in range and rebind the values will be the same. If telemetry data received by tx contains error; a wrong value will be displayed briefly until the value is next updated.

To clear telemetry data you need to turn the rx off. Is there a protocol command that will tell rx to clear telemetry data???

Because Telemetry data is on the rx is should be possible to use another tx for some time (view the telemetry data) and switch off that tx and then switch on your Devo with deviation and verify that the telemetry values are the same.

If should also be possible to fly with Telemetry Off. Then afterwards turn Telemetry On to view the data collected by the rx.

Downloads (updated today) are available here:
bitbucket.org/Indigo1/deviation/downloads

a simple question is : once we switch off telemetry, will Deviation bypass all the telemetry processes in our transmitter? I mean not leaving any chance for telemetry to get in..

reason for my question is some of us have no plan to use telemetry in the near future... we just want a robust one way radio to control our model.. and that is best to us..

thx for the great job,Indigo

cmPang

Yes bypass. To answer your question, I have studied the code and this is what I found.

When telemetry is off, it skips reading that data packet and waits for the next data packet it needs. If the number of channels is 7 or less, the wait time is longer because more (not needed) packets are skipped.

When binding, if protocol is DSMX and number of channels is 7 or less it sends a different code within the binding packet. Presumably to tell rx that telemetry data is not needed.

thanks a lot. Will perform some real life test in one or two days.

Indigo wrote: Yes bypass.
When binding, if protocol is DSMX and number of channels is 7 or less it sends a different code within the binding packet. Presumably to tell rx that telemetry data is not needed.

Hi,
this thread from the DSM2 development may help to understand some of the DSM2/DSMX quirks.