Support for walkera telemetry.

linux-user
Offline

18 Apr 2015 18:52 - 18 Apr 2015 20:06 #31337 by linux-user

Replied by linux-user on topic Support for walkera telemetry.

PhracturedBlue wrote: can you try the build I provided? It really should resolve the issue..

I can do, but what could we expect?
Regardless whether it solves the issue or not, I would never see the "loss of connection", simply because you reset the CYRF from time to time.

PhracturedBlue wrote: Let's say your Tx loses signal every 100 times that the bad-transmit condition happens. Let's also suppose I report this on serial but do not correct for it.

We might need some sort of time indicator in the log. (a fast growing log-file may be indication enough)

If you are testing for the right flag, I would expect the following in the log:
First (CYRF recovers by itself from the situation):
- only occasional occurrence of 'bad tx' messages

Later: (CYRF does not recover by itself):
- "infinite" occurrence of 'bad tx' messages

PhracturedBlue wrote: i.e. there may not be an indicator that means 'we need to reset the CYRF chip now'.

Than we have lost.

PhracturedBlue wrote: Also, recall that noone but you can actually duplicate the problem so far.

Although, it seems that I am the only one who can reproduce the issue, this post from cmpang indicates that this issue is not unique.

BTW:
If, what you are testing for, is an illegal CYRF state, that you think should never occur than you have actually reproduced a problem.

Edit:
I will test your build anyway.
Edit 2: It is running, let us see what it does.

Last edit: 18 Apr 2015 20:06 by linux-user.

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

PhracturedBlue
Offline

19 Apr 2015 00:06 #31342 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

Well I am 90% confident the fix I put in place will resolve your issue. The logs you provided earlier indicate that testing 0x02 should be a reliable way to detect your issue, but if you want to continue testing, I re-uploaded a new build. This build will print out the error condition without executing the reset.

If you are right, it will write out a large number of messages if the tx gets LOS. If that is the case, you really want to get the serial port working before testing.

I'm going to merge the reset code into the trunk though, since we've shown it doesn't cause any issues.

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

vlad_vy
Offline

19 Apr 2015 12:25 - 19 Apr 2015 12:26 #31351 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

vlad_vy wrote: The more and more I think it is a hardware problem. Now I run long time test for Devo protocol with telemetry enabled:

Hardware: Devo 12s without any mods, RX1202, WK-CTL01-D telemetry module, Walkera GPS sensor, elevator servo. All powered permanently.
Software: nightly build with some changes: www.deviationtx.com/forum/protocol-devel...etry?start=240#30974 or PB test build www.deviationtx.com/downloads-new/catego...o-fixes-for-devo-dsm

Test results:
Day 1, 24 hours = still connected
Day 2, 48 hours = still connected
Day 3, 72 hours = still connected
Day 4, 96 hours = still connected
Day 5, 120 hours = still connected
Day 6, ....
be continued...

Test do nothing for 'connection lost' issue, but can demonstrate code stability. Next I will continue the test with linux-user method. Devo 12s powered on from beginning to end..

Last edit: 19 Apr 2015 12:26 by vlad_vy.

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

PhracturedBlue
Offline

19 Apr 2015 12:42 - 19 Apr 2015 12:45 #31352 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

While it is obviously hardware dependent (as I said, none of my radios exhibit the issue), I think it is within Walkera's specifications since they have definitely written code to reset the chip on Tx failure. I dunno if anyone has tested the stock firmware, but I'll bet it does not have the same LOS we have in Deviation.

I was not previously trying to imply this issue should not be fixed, just that at some time we're going to get to the point where the current testing methods are not sufficient to determine if the issue is fixed, and that more advanced testing methods are hard to test given that not all hardware can reproduce the issue.

I should add, that from what I've seen, an always on test (by linux-user) should behave exactly like his mostly-off case. The tx seems to get stuck such that it does not transmit packets, and that will have little or nothing to do with whether it received a telemetry response. Because it can take many hours to trigger the issue, it is hard to evaluate one testing method against another. This one has been ood enough to get us this far at least.

Last edit: 19 Apr 2015 12:45 by PhracturedBlue.

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

linux-user
Offline

19 Apr 2015 12:52 #31354 by linux-user

Replied by linux-user on topic Support for walkera telemetry.

Hi,
the test build from PB has been running now for 16.5h without a single 'Rst CYRF' message or "loss of connection" event.
I need to interrupt this now for some flying.

I will try another test run this evening.

Telemetry values are often inverted. I know this is not to be tested here, but may be related in preventing to trigger my issue.

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

linux-user
Offline

19 Apr 2015 13:01 - 19 Apr 2015 13:05 #31355 by linux-user

Replied by linux-user on topic Support for walkera telemetry.

PhracturedBlue wrote: I dunno if anyone has tested the stock firmware, but I'll bet it does not have the same LOS we have in Deviation.

I remember reports, that early releases of original Walkera Devo10 FW could have this issue

Last edit: 19 Apr 2015 13:05 by linux-user.

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

vlad_vy
Offline

19 Apr 2015 13:06 #31356 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

With old code telemetry will work much better (but not ideally):

    } else {
        //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);
            delay = 100 * (16 - txState);
            txState = 15;
        }

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

linux-user
Offline

20 Apr 2015 08:47 - 20 Apr 2015 08:48 #31405 by linux-user

Replied by linux-user on topic Support for walkera telemetry.

linux-user wrote: Hi,
the test build from PB has been running now for 16.5h without a single 'Rst CYRF' message or "loss of connection" event.

Second test run for another 14h:
- hit 'Rst CYRF' 3 times within 5h
- connection to RX still possible
Now I will try PB's "DEVO Telemetry LOS fix" build without reset CYRF and see what it does.

Last edit: 20 Apr 2015 08:48 by linux-user.

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

linux-user
Offline

20 Apr 2015 12:29 - 20 Apr 2015 12:36 #31411 by linux-user

Replied by linux-user on topic Support for walkera telemetry.

After ~2.5h of running PB's "DEVO Telemetry LOS fix" build without reset CYRF
- Got lots of "128 CYRF bf bf000000" messages. ~15 per second on serial, right from the first occurrence.
- And, LOS
Exactly as expected

Last edit: 20 Apr 2015 12:36 by linux-user.

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

PhracturedBlue
Offline

20 Apr 2015 13:23 #31414 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

Thanks I merged it. I'm going to call this issue resolved now.

I think we still need Indigo's telemetry changes though?

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

vlad_vy
Offline

20 Apr 2015 14:20 #31420 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

PB, we don't need CYRF_ConfigRFChannel(*radio_ch_ptr) after CYRF reset?

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

PhracturedBlue
Offline

20 Apr 2015 14:44 #31421 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

I thought I had verified before that it would get called for us, but now I see it is only when pkt = 0. I've added it into the reset. Thanks.

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

vlad_vy
Offline

20 Apr 2015 15:06 #31424 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

Can you also add changes from post #30974? I never had any problems with telemetry with these changes.
www.deviationtx.com/forum/protocol-devel...etry?start=240#30974

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

Indigo
Offline

23 Apr 2015 02:20 - 23 Apr 2015 04:51 #31503 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

I believe I have found a fix for the Devo LOC problem, to stop it occurring in the first place. Although, I don't know how it could occur, possible hardware fault?

The fix is including TXBERR (Buffer Error) as a reason to exit the WAIT_LOOP.

     while (! tx_state && ++i < NUM_WAIT_LOOPS) {
-        tx_state |= (CYRF_ReadRegister(CYRF_04_TX_IRQ_STATUS) & 0x02);
+        tx_state |= (CYRF_ReadRegister(CYRF_04_TX_IRQ_STATUS) & 0x06);

TXBERR is cleared by setting the TX CLR bit (0x40) in TX_CTRL_ADR, which is all ready being done.

void CYRF_WriteDataPacketLen(const u8 dpbuffer[], u8 len)
{
     CYRF_WriteRegister(CYRF_01_TX_LENGTH, len);
     CYRF_WriteRegister(CYRF_02_TX_CTRL, 0x40);
     WriteRegisterMulti(CYRF_20_TX_BUFFER, dpbuffer, len);
     CYRF_WriteRegister(CYRF_02_TX_CTRL, 0xBF);
}

This additional reason to exit the WAIT_LOOP was already being done in J6_Pro protocol:

         case J6PRO_BIND_03_START:
            {
                int i = 0;
                while (! (CYRF_ReadRegister(0x04) & 0x06))
                    if(++i > NUM_WAIT_LOOPS)
                        break;
            }

I would like linux-user and cmpang to test version bb10550 I've uploaded to Test Builds to see if this does indeed fix LOC.

Last edit: 23 Apr 2015 04:51 by Indigo.

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

Indigo
Offline

23 Apr 2015 05:05 #31507 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

I've re-uploaded test version bb10550 with CYRF Reset fix and debug logging included into the build.

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

linux-user
Offline

23 Apr 2015 06:56 - 23 Apr 2015 07:00 #31509 by linux-user

Replied by linux-user on topic Support for walkera telemetry.

Indigo wrote: I've re-uploaded test version bb10550 with CYRF Reset fix and debug logging included into the build.

Not working with Devo! (DSMX seems to work)
- feels like one frame were sent every 5sec
- telemetry stays inverted
edit: with telemetry OFF it seems to work.

Last edit: 23 Apr 2015 07:00 by linux-user.

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

Indigo
Offline

23 Apr 2015 10:06 #31511 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

Thanks linux-user.

Please try new version 55d20bd.

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

linux-user
Offline

23 Apr 2015 12:16 #31514 by linux-user

Replied by linux-user on topic Support for walkera telemetry.

55d20bd is basically working with Devo telemetry
But no debug page.
Does this include the CYRF-reset from PB?

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

Indigo
Offline

23 Apr 2015 12:29 - 23 Apr 2015 13:20 #31516 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

Yes, includes CYRF_Reset from PB.

I don't know why no debug page.

Last edit: 23 Apr 2015 13:20 by Indigo.

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

PhracturedBlue
Offline

23 Apr 2015 12:51 - 23 Apr 2015 12:52 #31519 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

you need to build with TYPE=dev (and must do a 'make distclean' 1st) to enable debug)

Last edit: 23 Apr 2015 12:52 by PhracturedBlue.

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

Time to create page: 0.098 seconds

Force desktop display