Support for walkera telemetry.

follow up from: #29479

Hi,
Devo protocoll with telemetry switched ON could lead to a LOSS OF CONNECTION (at least with Devo10). I am able to reproduce this with devo10-v4.0.1-c0b203a_v2 and MiniCP within some hours of operation.

I am confident that (at least on Devo10) every release of Deviation up to now is affected.
See also: #525 #565
v120d02s-v2-lost-binding-mid-flight
devo-12s-dsmx-range-and-telemetry-questions #28100 #28056
It may take ~8h but sooner or later control is lost.
With telemetry switched OFF, I never could trigger this loss of connection.

How to reproduce:
1.) Connect a telemetry capable RX (i.e ladybird, MiniCP, SuperCP, New-V120D02s) with fixed-ID to TX
2.) display telemetry monitor, OR create a text box with telemetry value
I am not sure, but it seems to be necessary to actually display a telemetry value to trigger the bug (text box or telemety monitor)
Edit: I had at least 1 incident without displaying telemetry.
3.) power off RX and leave TX running.
4.) after some hours, power on RX
=> RX won't reconnect to the TX until either:
switch telemetry off or,
power cycle TX

Could anyone confirm or disprove this?

linux-user wrote: follow up from: #29479

Hi,
Devo protocoll with telemetry switched ON could lead to a LOSS OF CONNECTION (at least with Devo10)......

Could anyone confirm or disprove this?

Got something similar to this few months back.... but it was more like Tx developing a fault.
My V120D02S lost signal mid-flight several times but does reconnect within fraction of second.
In the end my DEVO10 it gave awful range and crashed my 250 which was using WK2801 protocol. And that is the last time I use DEVO 10

Picked up DEVO 12S
same heli
no problem
But I do feel that DEVO telemetry is not stable yet

Indigo wrote: dsm-telemetry-support
... the CYRF6936 detects errors in a received packet and sets a flag. So I just check that flag and if set not process that telemetry packet

Indigo, are you doing the same in Devo protocol?

Yes, Devo protocol was already checking that flag.

Here

Indigo wrote: About my Telemetry update.
Before transmit and receive (Telemetry) were sharing the same buffer. This effected Telemtry where sometimes all values change at same time and display wrong values (Tx data overwriting telemetry). If the reverse ever occurred it would cause a loss of binding. To fix this I gave Telemetry a separate buffer.

I have also done the same for Devo Telemetry, but there must still be another problem because with Devo Telemetry the problem persists. I read somewhere that the CYRF6936 will lock-up if an attempt to transmit occurs too soon after receiving data. Such a lock-up would persist until protocol is reset which would explain why Devo won't bind automatically after being left on for some time.

Hmm.

I read somewhere that the CYRF6936 will lock-up if an attempt to transmit occurs too soon after receiving data.

Would it be possible to deliberately delay transmission after reception?
Maybe even drop one frame for test purpose?

BTW:
I had "loss of connection" with telemetry ON, already in 4.01
But the only reports I am aware of are with Devo10.
Never saw a report with color display Devos by now.

linux-user wrote:

Indigo wrote: I read somewhere that the CYRF6936 will lock-up if an attempt to transmit occurs too soon after receiving data.

Would it be possible to deliberately delay transmission after reception?

Yes, as a test we could drop next frame after reception. I can create a patch or test version tomorrow that does that.

Try my new build 887aaac:
bitbucket.org/Indigo1/deviation/downloads

It switches from receive mode back to transmit mode 150us before transmitting.
If I remember correctly it needs atleast 5us before transmitting data.

So no need to skip frames, just switch back to transmit mode earlier.

You can review the source code changes here

0x02 indicates a byte has been received and receive is complete.

0x20 indicates that receive buffer is full (I think). When I check for this on DSM it rarely occurs so telemetry doesn't update continuously. I don't have Devo, but tester said it wasn't updating regularly. You will also read many similar reports from previous 2 pages on this thread.

0x01 indicates that a received byte has errors.

So old condition:
if ((reg & 0x23) == 0x22)

Was checking the above 3 bits and making sure that bit 0 (0x01) is zero.

Hi, just got loss of connection executing this Test
Version deviation-devo10-v4.0.1-887aaac.zip from Indigo

I have done this test now many times:
- No issue as long as telemetry switched OFF
- Reproduceable with 3 different RX (V120d02s-V2, MiniCP, GeniusCP-V1)
Note:
GeniusCP-V1 is not telemetry capable, but "loss of connection" occurred if telemetry is switched ON in the TX.

Manfred

Edit:
I tried the same test with DSMX and one of the newer Indigo-Versions too.
DSMX reconnected always instantly.
But I don't have DSM telemetry gear.

Source code is here . I don't get it either, but what I think happens is:

When data is received, it is all received at once. So when 0x02 is set, the receive is complete. No more bytes.

Whether 16 bytes were received or garbage, we must now empty the buffer ready for next chunk of data so regardless of quality we always call: CYRF_ReadDataPacket()

If no errors the contents is then processed.
The !(rx_state & 0x05) checks that 1st bit (receive error) and 3rd bit (receive buffer error) are not set. Then check again for receive error with 2nd call to CYRF_ReadRegister(0x07) (rare but the datasheet asks for it).

I agree that 0x20 should also be set (but it's not reliable), maybe the 2nd call is the right time to check for 0x20. Although it currently works better without checking 0x20, I will experiment with DSM and see if I can get this check to work reliably. I don't have a Devo model, but it shouldn't matter, this code section should be the same for both Devo and DSM.

linux-user wrote: Hi, just got loss of connection executing this Test
Version deviation-devo10-v4.0.1-887aaac.zip from Indigo

I have done this test now many times:
- No issue as long as telemetry switched OFF
- Reproduceable with 3 different RX (V120d02s-V2, MiniCP, GeniusCP-V1)
Note:
GeniusCP-V1 is not telemetry capable, but "loss of connection" occurred if telemetry is switched ON in the TX.

Manfred

Thanks for testing.

Strange that this problem appears fixed in DSM Telemrtry but still persists in Devo. Maybe it is something to do with how it is configured? Devo initialise code is quite different to DSM? Can we be sure that the initialise code for Devo is correct?