Support for walkera telemetry.

More
13 Mar 2015 09:29 - 23 Mar 2015 11:38 #29632 by linux-user
Replied by linux-user on topic 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?
Last edit: 23 Mar 2015 11:38 by linux-user.

Please Log in or Create an account to join the conversation.

More
13 Mar 2015 12:50 #29639 by Block137
Replied by Block137 on topic Support for walkera telemetry.

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

Please Log in or Create an account to join the conversation.

More
15 Mar 2015 14:41 #29740 by linux-user
Replied by linux-user on topic Support for walkera telemetry.

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?

Please Log in or Create an account to join the conversation.

More
15 Mar 2015 14:53 #29743 by Indigo
Replied by Indigo on topic Support for walkera telemetry.
Yes, Devo protocol was already checking that flag.

Please Log in or Create an account to join the conversation.

More
21 Mar 2015 07:58 - 21 Mar 2015 08:09 #29985 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
Can this problem be related to changes for universal module support? I think before that I havn't any loss of signal with Devo and Hubsan protocols and telemetry enabled.

Right now sometimes I have loss of signal with Devo and Hubsan protocols with telemetry enabled. With Hubsan protocol it's about half of a second only and I can continue to fly.
Last edit: 21 Mar 2015 08:09 by vlad_vy.

Please Log in or Create an account to join the conversation.

More
21 Mar 2015 13:08 #29987 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
Anything is possible, though I think it very unlikely. The changes made to the protocol were purely search and replace to replace a struct with a macro. the end code would be identical. The coverity change just after the merge had minor restructuring, but again nothing that would affect behavior.

If you can do testing, I can provide builds of
6d04f05
and
7da5155

which are before and after the universaltx merge. If both of those behave the same, we can do bisection to try to narrow it down. With things like this, it is very hard to debug unless the issue can be reproduced.

Please Log in or Create an account to join the conversation.

More
21 Mar 2015 13:20 #29988 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
If so it has not sence, I currently use build 6d04f05.

Please Log in or Create an account to join the conversation.

More
21 Mar 2015 13:27 #29989 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
You have no issues with 6d0405? have you tried 7da515? if 6d0405 works reliablyand 7da515 does not we could go through and figure out what specifically caused it. But I 1st need to know the problem happened there and not later (like in d1bc8bf)

Please Log in or Create an account to join the conversation.

More
21 Mar 2015 13:35 #29990 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
No, I have these issues with 6d04f05. I'm not tried all later builds.

At any case it will be hard to reproduce. With Hubsan protocol I had only two or three loss of signal for 24 hours of flights.

Please Log in or Create an account to join the conversation.

More
23 Mar 2015 09:59 - 23 Mar 2015 10:05 #30101 by linux-user
Replied by linux-user on topic Support for walkera telemetry.
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.
Last edit: 23 Mar 2015 10:05 by linux-user.

Please Log in or Create an account to join the conversation.

More
23 Mar 2015 10:08 #30102 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
My case is with Devo 8s.

Please Log in or Create an account to join the conversation.

More
23 Mar 2015 13:43 #30107 by Indigo
Replied by Indigo on topic Support for walkera telemetry.

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.

Please Log in or Create an account to join the conversation.

More
24 Mar 2015 03:54 - 24 Mar 2015 06:25 #30159 by Indigo
Replied by Indigo on topic Support for walkera telemetry.
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
Last edit: 24 Mar 2015 06:25 by Indigo.

Please Log in or Create an account to join the conversation.

More
24 Mar 2015 06:52 - 24 Mar 2015 06:54 #30167 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
devo_cyrf6936.c
- int reg = CYRF_ReadRegister(0x07);
- if ((reg & 0x23) == 0x22)
- //if(CYRF_ReadRegister(0x07) & 0x20)
- { // this won't be true in emulator so we need to simulate it somehow
- CYRF_ReadDataPacket(packet);
- parse_telemetry_packet(packet);
+ //Read telemetry if needed and parse if good
+ u8 rx_state = CYRF_ReadRegister(CYRF_07_RX_IRQ_STATUS);
+ if (rx_state & 0x02) {

Why rx_state & 0x02 ??? But not 0x23, not 0x20.
Last edit: 24 Mar 2015 06:54 by vlad_vy.

Please Log in or Create an account to join the conversation.

More
24 Mar 2015 09:51 #30172 by Indigo
Replied by Indigo on topic Support for walkera telemetry.
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.

Please Log in or Create an account to join the conversation.

More
24 Mar 2015 14:07 #30182 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
I don't get it. We the buffer size is 16, so if the buffer isn't full, the data in the buffer should be at least partially garbage.
Checking the error bit should be important. otherwise the CRC may be bad and you'll get bogus telemetry data and not even know it.
The code originally didn't use the error-bit, and it would get spurious bad data pumped in, which is why I added it.

Please Log in or Create an account to join the conversation.

More
24 Mar 2015 15:16 - 24 Mar 2015 15:43 #30190 by linux-user
Replied by linux-user on topic Support for walkera telemetry.
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.
Last edit: 24 Mar 2015 15:43 by linux-user. Reason: DSMX does not seem to be affected

Please Log in or Create an account to join the conversation.

More
24 Mar 2015 15:26 #30191 by Indigo
Replied by Indigo on topic Support for walkera telemetry.
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.
if (!(rx_state & 0x05) && !(CYRF_ReadRegister(CYRF_07_RX_IRQ_STATUS) & 0x01))
     parse_telemetry_packet();

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.

Please Log in or Create an account to join the conversation.

More
24 Mar 2015 15:37 #30195 by Indigo
Replied by Indigo on topic Support for walkera telemetry.

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?

Please Log in or Create an account to join the conversation.

More
24 Mar 2015 16:57 - 24 Mar 2015 16:59 #30203 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
The devo initialization code was captured from a Devo Tx, so it should be correct. I may even still have those logs if you want them.
Edit: I also have telemetry logs of a model transmiting data back if those would help.
Last edit: 24 Mar 2015 16:59 by PhracturedBlue.

Please Log in or Create an account to join the conversation.

Time to create page: 0.106 seconds
Powered by Kunena Forum