Support for walkera telemetry.

More
16 Apr 2015 15:57 - 16 Apr 2015 16:00 #31245 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
I already have tested with added cyrf_set_bound_sop_code(), all looks fine, I need to test in flight.

if (txState == 1) {
        int i = 0;
        while (! (CYRF_ReadRegister(0x04) & 0x02)) {
            if(++i >= NUM_WAIT_LOOPS) {
                delay = 1500;
                txState = 15;
                break;
            }
        }     
        test_reset--;
        if(!test_reset) {
            test_reset = 25000;
            CYRF_Reset();
            cyrf_init();
            cyrf_set_bound_sop_code();
            delay = 1500;
            txState = 15;
        }
Last edit: 16 Apr 2015 16:00 by vlad_vy.

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

More
16 Apr 2015 16:59 - 16 Apr 2015 17:05 #31248 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
Almost excellent result. 12 minutes of test flight. Every minute there is a reset of CYRF6936, but I do not notice any negative impact. Transparent reset. But, if I have sound alarms (battery), the connection will be lost. Probably it can be too low battery. Need more testing.
Last edit: 16 Apr 2015 17:05 by vlad_vy.

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

More
16 Apr 2015 17:05 #31249 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
to clarify. if the battery alarm goes off, you lose connection? And that is true only with the 'reset' version and not with the mainline code? What about if the alarm volume is set to 0? does it still lose connection?
the alarm code should not be able to preempt the protocol code, so this is a very odd behavior.

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

More
16 Apr 2015 17:07 #31250 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
Also, can you provide the code you are using as a patch? we can build it for linux-user and see if it resolves his issue. I'd like him to test the forced reset code since it will allow us to isolate whether the reset addresses the connection issue without guessing about when it needs to be triggered (which we DO need to figure out before it gets officially released)

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

More
16 Apr 2015 17:12 #31251 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
Early or late with working alarm connection lost.

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

More
16 Apr 2015 17:22 - 16 Apr 2015 17:28 #31252 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
It's Ladybird problem, can't tolerate low battery voltage, lost connection even with normal build.

For test I used code in my message #31245. For linux-user we need write working code, not this test build.
Last edit: 16 Apr 2015 17:28 by vlad_vy.

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

More
16 Apr 2015 17:37 - 16 Apr 2015 17:37 #31253 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
I disagree. I think this is exactly what we need linux-user to test. It should definitively indicate whether a reset will fix his issue.

I have created a devo10 build here:
www.deviationtx.com/downloads-new/catego...blue-devo-reset-test

Note that I do NOT recommend actually flying with this. Just use it to see if you can reliably maintain a connection over multiple days with telemetry enabled
Last edit: 16 Apr 2015 17:37 by PhracturedBlue.

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

More
16 Apr 2015 19:00 - 17 Apr 2015 15:37 #31256 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
Changes for Devo protocol, included CYRF reset and RX abort.
    if (txState == 1) {
        int i = 0;
        while ( !(CYRF_ReadRegister(0x04) & 0x02)) {
            if(++i > NUM_WAIT_LOOPS) 
                break;
        }
        if ((i > NUM_WAIT_LOOPS) || (CYRF_ReadRegister(0x02) & 0x80)) {
            CYRF_Reset();
            cyrf_init();
            cyrf_set_bound_sop_code();
            txState = 0;
            return 1500;
        }
    txState++;
    if(txState == 16) { //2.3msec have passed
        if (CYRF_ReadRegister(CYRF_05_RX_CTRL) & 0x80) { // We're still in receive mode    
            // Disrupt any pending receive by enabling abort    
            // Force End State should not be used to abort a receive if a SOP has already happened.    
            CYRF_WriteRegister(CYRF_29_RX_ABORT, 0x20);
        
            CYRF_RxPacketIsGood(0x00);
        
            // Abort by writing the FRC_END_STATE bit in the XACT_CFG register.    
            CYRF_SetTxRxMode(TX_EN); //Write mode
        
            // Disable abort
            CYRF_WriteRegister(CYRF_29_RX_ABORT, 0x00);    
        } 
        else CYRF_SetTxRxMode(TX_EN); //Write mode
        if(pkt_num == 0) {
            //Keep tx power updated
            CYRF_WriteRegister(CYRF_03_TX_CFG, 0x08 | Model.tx_power);
            radio_ch_ptr = radio_ch_ptr == &radio_ch[2] ? radio_ch : radio_ch_ptr + 1;
            CYRF_ConfigRFChannel(*radio_ch_ptr);
        }
        txState = 0;
    }
    return delay;
}
Last edit: 17 Apr 2015 15:37 by vlad_vy.

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

More
16 Apr 2015 19:49 #31257 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
Thanks, but to prevent any confusion, I would still like linux-user to test the build I provided above. It changes exactly one thing, and will let us know whether a reboot of the CYRF chip will resolve the issues he's having. Once we've confirmed a reset prevents the issue, we will test with the hang-detection.

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

More
17 Apr 2015 04:24 - 17 Apr 2015 05:38 #31276 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
OK. I uploaded my test code for safety only. I can get confused in all my trials, also I'm already have lost all my previous environment and archives because of HDD failure.
Last edit: 17 Apr 2015 05:38 by vlad_vy.

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

More
17 Apr 2015 10:37 - 17 Apr 2015 11:11 #31287 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
PB, what will be if bad transmission will have place for "pkt_num = 0" and with CYRF reset we skip:
        if(pkt_num == 0) {
            //Keep tx power updated
            CYRF_WriteRegister(CYRF_03_TX_CFG, 0x08 | Model.tx_power);
            radio_ch_ptr = radio_ch_ptr == &radio_ch[2] ? radio_ch : radio_ch_ptr + 1;
            CYRF_ConfigRFChannel(*radio_ch_ptr);
        }
        txState = 0;

Probably will be better to change code for CYRF reset to:
    if (txState == 1) {
        int i = 0;
        while ( !(CYRF_ReadRegister(0x04) & 0x02)) {
            if(++i > NUM_WAIT_LOOPS) 
                break;
        }
        if ((i > NUM_WAIT_LOOPS) || (CYRF_ReadRegister(0x02) & 0x80)) {
            CYRF_Reset();
            cyrf_init();
            cyrf_set_bound_sop_code();
            delay = 1500;
            txState = 15;
        } else {
            if (state == DEVO_BOUND) {
                /* exit binding state */
                state = DEVO_BOUND_3;
                cyrf_set_bound_sop_code();
            }
            if(pkt_num == 0 || bind_counter > 0) {
                delay = 1500;
                txState = 15;
            } else {
                CYRF_SetTxRxMode(RX_EN); //Receive mode
                CYRF_StartReceive(); //Prepare to receive
            }
        }
    } else {
Last edit: 17 Apr 2015 11:11 by vlad_vy.

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

More
17 Apr 2015 12:13 #31291 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
I may be missing something; isn't that what I said in 31244 ? I agree we need an else condition to prevent going into Rx mode after reset.

There IS a bug as you mentioned though. We need to sett he RF channel every time we reset, since pkt_num may not be 0:
    if(...) {
            CYRF_Reset();
            cyrf_init();
            cyrf_set_bound_sop_code();
            CYRF_ConfigRFChannel(*radio_ch_ptr);
            delay = 1500;
            txState = 15;
    } else {

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

More
17 Apr 2015 14:22 #31295 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.
It also work flawlessly. 12 minutes of test flight with every 1 minute CYRF reset. No problems.

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

More
18 Apr 2015 10:25 - 18 Apr 2015 13:25 #31323 by linux-user
Replied by linux-user on topic Support for walkera telemetry.
This [PhracturedBlue]Devo Reset Test is now running for 32h without any "connection loss"
The only odd thing I've observed is, that telemetry values are randomly getting inverted.

I don't think, that running this even longer would get us any new information.
With every version since 4.01 I have been able to recover manually by switching telemetry off/on.

IMHO, the real challenge is to reliably detect the "loss of connection" situation in a timely manner.

I may run this [PhracturedBlue]CYRF Reg Dump and capture more "connection losses" to get a more consistent picture.
Or, as I now have a cp2102 USB-to-UART, we could use this as well.
Last edit: 18 Apr 2015 13:25 by linux-user. Reason: update runtime 32h

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

More
18 Apr 2015 13:16 - 18 Apr 2015 13:19 #31325 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
Ok, here is a new build:
www.deviationtx.com/downloads-new/catego...vo-telemetry-los-fix

This SHOULD properly detect loss-of-signal and force a reset. It is a debug-build, and it will report each time a reset condition is detected on serial and on the new on-screen logger.

For the serial:
I needed to connect the 'Tx' pin (pin 3) to the tip and GND (pin 1) to the base of the 1/8" jack. I then use putty at 115200 baud to connect to the serial port. Turn on the tx and you should get some text. If it doesn't work, try the 'Rx' pin instead.
Since we have the on-screen log now, this isn't that important unless you get so many logs that they scroll off the screen.

A message of 'Rst CYRF' will indicate that a fault and reset occurred.

I tested this on my Devo10, and it looks ok, but I on't have a DEVO model handy at the moment to ensure the protocol still works.

Note this is based on the trunk, and does not include any of Indigo's fixes. those may or may not help with telemetry reliability. I am only concerned with loss-of-signal in this version. i checked in the changes on the 'devotelem' branch
Last edit: 18 Apr 2015 13:19 by PhracturedBlue.

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

More
18 Apr 2015 14:08 #31327 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
Well, after 45mins of being on, my Devo10 hit the reset condition twice, and I have never seen the LOS case that linux-user has. So the code may be the issue is common but the CYRF self-recovers (except for linux-user sometimes). One concern is that if the condition I implemented isn't the same as what causes linux-user's LOS, it is possible he'd get a loss-of-signal until the unrelated Reset condition happens and restores the Tx. That would give a false sense of security since the test he's running would pass, but in real life you'd have lost control. I have no idea how to test that other than to rig up an alarm on the Rx that indicates when LOS happens, and to leave it on for days to make sure it doesn't

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

More
18 Apr 2015 14:50 - 18 Apr 2015 15:32 #31330 by linux-user
Replied by linux-user on topic Support for walkera telemetry.

PhracturedBlue wrote: it is possible he'd get a loss-of-signal until the unrelated Reset condition happens and restores the Tx. That would give a false sense of security since the test he's running would pass, but in real life you'd have lost control.

Oh yes, I see the problem.

If you reset the CYRF from time to time, I would never see the LOS although it may happen.

What about making another debug build that only triggers a message + an alarm sound, but does not reset CYRF?
Then I could check if really "loss of connection" happened.

Edit:
It may even dump all CYRF registers to serial.
Edit 2:
IMHO the key is, not to try to solve the issue, but try to reproduce and record the situation.
I have no idea how I could rig up an alarm on the Rx side.
Last edit: 18 Apr 2015 15:32 by linux-user.

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

More
18 Apr 2015 16:36 #31332 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
can you try the build I provided? It really should resolve the issue.

The problem is that logging the error won't be sufficient I think. 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. You see the 1st 'bad tx' message, and check the Rx but it still binds. You come back 5 hours later, see a lot of 'bad tx' messages, and the Rx no longer binds. Ok, so how can we tell whether this is the proper test condition? We really have no way to do so. because we don't know if one of the 100 failures caused the issue or if it was something unrelated.

We could continue to write tests, and try to find one that fires only when you lose signal, but it may not be possible to do. It is quite possible that there is no difference to the Tx whether the 'bad tx' condition above caused a loss-of-signal or not. i.e. there may not be an indicator that means 'we need to reset the CYRF chip now'.

Also, recall that noone but you can actually duplicate the problem so far. I've run hundreds of hours on multiple transmitters and have never been able to reproduce the issue you have.

The test I have in place now is, I believe, very similar to the test Walkera does in the production firmware, so I hope it will be good enough.

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

More
18 Apr 2015 16:38 #31333 by vlad_vy
Replied by vlad_vy on topic Support for walkera telemetry.

PhracturedBlue wrote: TXCTRL has the TX_GO bit set AND XACT_CFG_ADDR has the FRC_END bit set. This is not a legal combination
TX_IRQ_STATUS shows the buffer is empty with TX_GO active, which probably shouldn't occur
The RX_Status is showing both EOP and BAD_CRCIRQs set

        if (((reg & 0x22) == 0x20) || (CYRF_ReadRegister(0x02) & 0x80)) {
     	    CYRF_Reset();
            cyrf_init();
            cyrf_set_bound_sop_code();
            printf("Rst CYRF\n");
            delay = 1500;
            txState = 15;
        } else {

I think "(reg & 0x22) == 0x20)" is excessive.

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

More
18 Apr 2015 17:54 #31336 by PhracturedBlue
Replied by PhracturedBlue on topic Support for walkera telemetry.
it is what I think Walkera does.

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

Time to create page: 0.090 seconds
Powered by Kunena Forum