V120d02s-V2 lost binding mid flight

Today on a nice winter day ~0C° the motor of my V120d02s suddenly stopped during flight.
When I picked up the heli the flybarless seems still working (servos moving when shaking the heli) but no control anymore.

On the TX side nothing unusual, so the issue may be on the RX side.
I pressed "Re-Init" on the TX, power cycled heli, and control was back but when I tried to lift off heli tilted.
TX off-on rebound heli and did a successful test-flight.

- Devo10 with deviation 4.01
- TX-power set to 10mW
- TX Battery ~10V
- Telemetry Display ~3.6V

RX2636H-D (V120d02s-V2)
- firmware V1.1
- telemetry on
- flight time ~5min
- distance ~20m
- no fixed ID

---

Update 2014-04-10:
(Summary, if you don't want to read the whole thread)
1.) A major contributing factor to the issue was a hardware fault of the CYRF6936 module in my Devo10.
This leads to:
a) poor range for telemetry (~ 10m or even less)
b) every now and then implausible telemetry data (i.e. 19.73 Volt)
c) eventually a loss of binding - the higher the number of corrupt telemetry data the more likely the loss.
I was able to reproduce the "loss of binding" within a few hours of operation.

2.) After changing the CYRF6936 module I couldn't reproduce a "loss of binding", and I couldn't see bad telemetry data anymore.

3.) My conclusion at the moment:
If you want to use telemetry, do a range test for telemetry and watch for implausible data in telemetry monitor.
With my new module I am getting range for telemetry of at least 50m
If you are getting random implausible data, you may have a faulty module - then switch telemetry off to be save.

A more complete summary could be found on posts 21247 and 21524

BTW:
Q: Do you know anything about the firmware V2.0 for the RX2636H?
Answer I found from other posts:
V2.0 is only for Futaba compatibility. It may be used with Devo as well but seems to disable telemetry.

I believe the only public info is that V2.0 allows you to add the Futaba Satellite receiver.

@FDR thank you for the hint with the fixed-ID.
After some more testing I was able to reproduce the incident on the bench.

Now I can pinpoint the fault on TX side, so we ALL should be CONCERNED.

Test environment:
- RX2636H-D powered by junsi iCharger with constant Voltage of 3.5V resp. 3.0V
- Devo10 with deviation 4.01, logging Timer2 and Volt2 every 30sec.
- some WLAN's nearby
- TX powered with 12V power supply

Incident:
- leave Devo10 and RX2636H-D (v120d02s) bound for a long time.
- after some hours control was lost.
- LED on RX2636H-D constant solid amber
- press "Bind" on the TX -- no help
- switch TX into USB-mode and back -- no help
- power cycle TX -- control was back !!
Note: at that time the RX2636H-D was constantly powered with 3.0V and not touched.

The error occurs very sporadic but is likely to happen within ~10h of operation.
I don't know if the error is hardware or software.

If someone with deep knowledge of deviation could provide some debugging code I am willing to do more testing.
When you watch the above values of the datalog, keep in mind that the voltage at that time was constantly 3.5V
How robust is deviation when receiving telemetry values way off?

Attached datalog.bin and errors.txt at the time of the incident.
edit: try with *.zip

PhracturedBlue wrote: Hmm...If 'Bind' doesn't work and cycling the Tx does, it sounds like the hardware gets into an irrecoverable state. The 'Bind' button should do exactly the same thing that a power-on would.

I did some more observations:
1.) Pressing "Bind" while control is there, doesn't interrupt control.
you see the countdown "binding ... 11 .. 10 .. 9 .. 8" but contol stays there all the time.
2.) When power cycling the TX, the time it takes to control comming back varies greatly. - from instant, to 20sec to even infinite.
Most of the time it takes less than ~5sec.

PhracturedBlue wrote: the tx chooses new transmit channels each time it is powered on..

But pressing "Bind" doesn't change channels right?

PhracturedBlue wrote: I'd be interested in whether you see the same behavior with telemetry disabled.

I'll give it a try, but that will take some time. (it is difficult to tell the absence of an error

PhracturedBlue wrote: Doesn't the light start blinking on the rx when you lose bind state? I assumed you could just check on it every couple hours to see if it is still bound or not.

Yes, usually the light is blinking when loosing connection. But I don't rely on this, as during my tests I have seen anything (off, on, blinking)

For me the easiest thing to do is simply move one of the sticks and watch (or hear) the heli. That is what I've done during my tests to tell if control is there.

No extra transceiver modules installed in my TX.

I shall do this test over the weekend with a Devo8s and DSMX - report back on Monday

PhracturedBlue wrote: 24hrs later and my ladybird was still bound fine and throttle still worked.

I "fine tuned" the signal of the telemetry to be as weak as possible; just close to the point where a text-box on my Devo10 becomes inverted.
(pointing the antenna to the RX; putting some obstacles between TX and RX, putting a WLAN-device close to the TX, etc.)

It may be specific to the Devo10 or the RX2636H-D (V120d02s-V2).
This RX has known bugs. One is, it does bind to a random ID even if a fixed-ID is set.

@RandMental: DSMX may behave different, but would be interesting to see, if you get implausible values like the voltage here.
@PhracturedBlue: I may try the same test with my Mini-CP.
But I can't chase two rabbits at once.
At the moment I am testing without telemetry.
No problems until now, but that may not be long enough, as the longest time I can set on my iCharger is 240min.

Hi,
some news from the telemetry front:

1.) Telemetry switched off: - no issues
My V120d02s-V2 absloved three 240min cycles without any noticeable glitch.
The Devo10 was continuously switched on for more than 2 days.

2.) Telemetry switched on with Mini-CP:
Two test cycles with loss of binding within 2h
- Press "Bind" on the Devo10 -- no help
- load different model and then MiniCP again:
Voila: control was back, without power cycling anything.

3.) Question to all MiniCP and V120d02s-v2 users:
What range do you get for telemetry?
With my Devo10 - MiniCP combination telemetry range is at best 7m-10m (values are displayed inverted). The range for the control is at least double, even at 100µW.
Edit:
The reason I am asking for telemetry range is, that I want to know if my TX-module could have a defect that triggers the "lost binding issue" (i.e. faulty LNA)

Feedback on DSMX - 2x 24hour cycles with no problems, I power cycled the DSMX receiver a few times (we are not testing the receiver) and had no issues rebinding immediately.

RandMental,
did you test with telemetry switched on?
It would be very interesting to know, if you got similar random values as in my post #20935 above.

I've done a lot of tests by now.
The issue I've reported (loss of binding) is in some way related to the quality of telemetry data. See my comment on issue #525

I am not able to trigger the problem with telemetry switched off.
Even with telemetry switched on, it needs to be somewhere close to the range limit of telemetry to trigger the issue.

No Telemetry - I don't have a DSM2/X telemetry device

summarize: see issue #525
- No issue with telemetry switched off

- Corrupted telemetry data could lead to a loss of binding.
I am able to reproduce this with MiniCP and Devo10 most likely within 3h of operation.

- The "loss of binding" is related in some way to quality of telemetry data.
With a distance RX<->TX of 20cm I am not able to trigger the issue.

- If binding (and thus control) is lost and you do the following:
1.) switch telemetry off => control is back instant.
2.) load a different model and then same model again => control is back within a few seconds.
3.) power cycle TX => most likely control comes back within a few seconds.
4.) press "Bind" button => this doesn't help.
5.) power cycle RX while leaving TX on => this doesn't help.

With the attached log files I tried to log all devo telemetry data at 10s interval.
Note that MiniCP only supports Volt2 and Temp1

datalog20-all.bin is at a distance RX<->TX of ~20cm
datalog300-all.bin is at a distance RX<->TX of ~300cm

datalog300-all.bin actually catches the issue at ~59min
At ~64min telemetry was switched off and control was back instantly.