DSM Telemetry support

"a hold occurs when 45 contiguous (one right after the other) frame losses occur. This takes about one second."

1. Alarm sounds when FrameLosses is 40 or more.
2. When ENT is pressed to mute the alarm, the value at that moment in time is stored. That value is now subtracted from received telemetry value and the adjusted value is displayed instead of the actual value. So for example the FrameLoss value when in alarm state will appear to be reset by ENT key.
3. When ENT is pressed only values in an alarm state shall be reset. If no values are in an alarm state, nothing happens.
4. Alarm is triggered each time the displayed value exceeds the alarm value.
5. When no more telemetry values are received (ie. when rx is switched off) and the telemetry display values change colour, the actual last received values are then displayed. -- So you can then see the actual totals (instead of adjusted values).

"When ENT is pressed any values in alarm state will be stored. The stored value is then subtracted from real value before comparing with set alarm value.

Thomas.Heiss wrote: Tested re-occuring holds with test build devo10-v4.0.1-72057cf:
How do you detect a flight-pack disconnect? How is it different from a telemetry temporary out-of-sight disconnect which also may take 2-3 seconds?

When I turned Devo10 OFF + back ON, re-alarming seemed to work fine.

• Alarms should sound at the right time.
• Alarms should reset automatically when required.
• Mute keys ENT or EXT should always work.
• Alarm <= 0 will now fire on a received zero value. Previously zero would never trigger an alarm.
• After time-out when all fields go inverted all alarms are now reset. eg. when changing RX battery.

Indigo wrote: New version c810bb4 available here:
bitbucket.org/Indigo1/deviation/downloads

Alarm <= 0 will now fire on a received zero value. Previously zero would never trigger an alarm.

Indigo wrote:

After time-out when all fields go inverted all alarms are now reset. eg. when changing RX battery.

Thomas.Heiss wrote: Hi Indigo,

Thanks for update.

Indigo wrote: New version c810bb4 available here:
bitbucket.org/Indigo1/deviation/downloads

Alarm <= 0 will now fire on a received zero value. Previously zero would never trigger an alarm.

"on a received zero value"?
What alarm would that be for? Can you give an example?

Thomas.Heiss wrote:

Indigo wrote:

After time-out when all fields go inverted all alarms are now reset. eg. when changing RX battery.

Can you go into more technical details?

I seem not to understand how you can check in DeviationTX if the RX is reset / permanently disconnected.
Can you reset the previously stored alarm values just in that case?
What is a time-out (yes I see sometimes that the fields go black / inverted; switching intervals vary)?

Thomas.Heiss wrote: I would be very OK like I did with DX8:
You had to hit the CLEAR button for zeroing values (specially true for min/max RxV, battV, temp,...) after you plug in a new flight pack.
For FlightLog it worked out of the box without CLEAR (but I would not matter).

Thomas.Heiss wrote: What happens in this scenario with auto-reset on time-out:
- telemetry warning is configured for >= 20 FrameLosses
- displayed FrameLosses is 35 (monitor)
- 1st FrameLosses warning has been already issued on 21 FL and supressed with ENT button
- telemetry signal suddenly is temporarily disonnected for 1-3 seconds (TM1000 out of range)
- DSMx connection to RX is however NOT LOST
- telemetry signal is back (in range)

-> previously stored value 20/21 (supressed 1st alarm) MUST NOT be reset

-> if you reset the alarm values for re-occuring events just on a telemetry connection signal problem or lost (flickering 0,x-1 seconds, 1-3 seconds, etc.) re-alarms for FlightLog will not work?? Or do they?


One have to be involved very low-level technical spoken and read / written some code parts to fully understand how DSMx + telemetry works.

Sorry for asking.

Thomas

• telemetry stops working after a while.
• high rate of frame losses.

Indigo wrote: My latest builds c810bb4 and 093e33f suffer from some sort of bind or rebind problem.

If it looses binding for more than half a second it takes forever to rebind, and when it does rebind it easily looses binding again. Could this be a sync problem?

Up until the first long Hold occurs it works great, but then

Thomas.Heiss wrote:

Indigo wrote:

After time-out when all fields go inverted all alarms are now reset. eg. when changing RX battery.

Can you go into more technical details?
...
Thomas

• there are 3 alarm states: off = 0, on = 1, mute = 2.
• when you mute an alarm, the alarm state is still true (just silenced).
• if a received value is not an alarm value, the alarm state is set to 0 (off). So alarm will self reset if received value is ok.

        if (value >= alarm_value) {     // if alarm condition is true
            if (! alarm_state[k]) {     // if alarm_state = off, then make alarm_state = on
                alarm_state[k]++;
            }
        } else {                        // (not an alarm value)
            if (alarm_state[k]) {       // if alarm_state = on/mute, increment alarm_state
                alarm_state[k]++;       // on -> mute -> mute -> 4
                alarm_state[k] &= 3;    // value of 4 becomes 0 (off)

vlad_vy wrote: For Indigo,

DSM telemetry errors:

1. Data type = 0x16 and 0x17 GPS Sensor - all bytes swapped. GPS sensor sends bytes with different order = first LSB, next MSB.

Latitude always = N 0 00' 00.001"
Longitude always = E 0 00' 00.001"
all others values have not any sense (wrong values).

2. Data type = 0x15 JetCat Sensor - also has different bytes order = first LSB, next MSB.

3. Data type = 0x34: Flight Pack Cap Sensor (SPMA9605) - also has different bytes order = first LSB, next MSB.

4. Data type = 0x18: RX Pack Cap Sensor (SPMA9604) - also has different bytes order = first LSB, next MSB.

Spektrum sensors can have different bytes order (MSB+LSB or LSB+MSB). Now it difficult to control at code, since buffer has integer format with unknown bytes order.

5. Also, 'Temp' with value '18186C', if sensor is disconnected, confuse me.

For DSM telemetry: If (Temp <-40 || Temp > 538) Temp = 0; //(-40F~1000F or -40C~538C)
For Devo telemetry: If (Temp > 220) Temp = 0; //(-20C ~ 220C)

6. Telemetry module (TM1000) now do not work (do not bind) with 6ch DSMX Rx (Spektrum AR6210) with any protocol options (OFF. ON, A1).

7. For me, will be better display 'Speed' as 'km/h', but not as 'm/sec'.