Support for walkera telemetry.

Indigo
Offline

29 Mar 2015 20:07 #30415 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

My latest builds c810bb4 and 093e33f suffer from some sort of bind or rebind problem.

If it looses binding for more than half a second it takes forever to rebind, and when it does rebind it easily looses binding again. Could this be a sync problem?

Up until the first long Hold occurs it works great, but then

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

Thomas.Heiss
Offline

29 Mar 2015 23:39 - 29 Mar 2015 23:41 #30425 by Thomas.Heiss

Replied by Thomas.Heiss on topic Support for walkera telemetry.

> Up until the first long Hold occurs

Also applies to (DSMx) telemetry (lock) as my live flight tests (10) showed me with one-multiple holds

Is that the same case for Walkera telemetry then?

Last edit: 29 Mar 2015 23:41 by Thomas.Heiss.

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

Indigo
Offline

30 Mar 2015 03:14 - 30 Mar 2015 03:19 #30437 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

It could be. Both Devo and DSM now share the same wait loop.

In this new version db5dcb3, all I've changed is the code for that (no other changes).

bitbucket.org/Indigo1/deviation/downloads

Last edit: 30 Mar 2015 03:19 by Indigo.

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

vlad_vy
Offline

30 Mar 2015 06:29 - 30 Mar 2015 07:59 #30441 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

deleted

Last edit: 30 Mar 2015 07:59 by vlad_vy.

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

Indigo
Offline

30 Mar 2015 06:50 - 30 Mar 2015 07:56 #30442 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

Wait loops like this:

        int i = 0;
        while (! (CYRF_ReadRegister(0x04) & 0x02)) {
            if(++i > NUM_WAIT_LOOPS)
                break;
        }

From version 72057cf was replaced with: CYRF_WaitForTxIRQ();

which was this :

void CYRF_WaitForTxIRQ()
{
    int i = 0;
    while (! (CYRF_ReadRegister(CYRF_04_TX_IRQ_STATUS) & 0x02)) {
        if(++i > NUM_WAIT_LOOPS)
            break;
    }
}

And it is now this :

void CYRF_WaitForTxIRQ()
{
    unsigned i = 0;
    unsigned tx_state = 0;
    while (! tx_state && ++i < NUM_WAIT_LOOPS)
        tx_state |= (CYRF_ReadRegister(CYRF_04_TX_IRQ_STATUS) & 0x02);
    }
}

A diff between branches dsm-telemetry and telemetry-test will show that as the only change.

BTW. My nanoQX has been sitting on bench for last 2 hours and it's still bound to Tx.

Update:
NanoQX battery went flat. When I last checked it, it was still bound after 2 hours and 20 mins.

Last edit: 30 Mar 2015 07:56 by Indigo. Reason: Added links to source codes

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

Indigo
Offline

30 Mar 2015 07:42 - 30 Mar 2015 07:52 #30445 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

There is one change if made in previous commit which I should have announced with a warning.

WARNING:
Devo now uses same callback function for Telemetry OFF and ON. I did that to see if the problem would then appear with Telemetry OFF.

Last edit: 30 Mar 2015 07:52 by Indigo.

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

vlad_vy
Offline

30 Mar 2015 07:54 #30446 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

I don't think a problem related to wait loop. With telemetry OFF we use the same wait loop and all works fine.

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

Indigo
Offline

30 Mar 2015 08:09 - 30 Mar 2015 08:19 #30447 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

With Telemetry ON:

     if (txState == 1) {
         int i = 0;
         while (! (CYRF_ReadRegister(0x04) & 0x02)) {
             if(++i > NUM_WAIT_LOOPS) {
                 delay = 1500;
                 txState = 15;
                 break;
             }
         }
      
         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_WriteRegister(CYRF_07_RX_IRQ_STATUS, 0x80); //Prepare to receive
             CYRF_WriteRegister(CYRF_05_RX_CTRL, 0x80); //Prepare to receive (do not enable any IRQ)
         }
     } else {

Note: delay and txState will not change if register 04 changes its value to 2. When this happens txState might never change from 1, so Tx lock is created.

And with Telemetry OFF shown below, txState always changes back to zero.

     if (txState == 0) {
         txState = 1;
         DEVO_BuildPacket();
         CYRF_WriteDataPacket(packet);
         return 1200;
     }
     txState = 0;
     int i = 0;
     while (! (CYRF_ReadRegister(0x04) & 0x02)) {
         if(++i > NUM_WAIT_LOOPS)
             return 1200;
     }

Last edit: 30 Mar 2015 08:19 by Indigo.

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

vlad_vy
Offline

30 Mar 2015 09:05 - 30 Mar 2015 09:06 #30448 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

I'm not agree with that. At the end of 'if (txState == 1)' there is:

txState++;

So if register 04 changes its value to 2, will be txState=2.

Last edit: 30 Mar 2015 09:06 by vlad_vy.

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

Indigo
Offline

30 Mar 2015 10:22 #30450 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

Yes, you are right.

The 2 wait loops are different, so how they get optimised and converted to machine code will be different.

A problem started on DSM and Devo after replacing these wait loops which a common function CYRF_WaitForTxIRQ(). The function was not reliable. I'll speculate that it was caused by ISR interrupting the conversion of u8 to u32.

OR'ing the u8 returned by ReadRegister with a u32 variable (I think) has fixed the problem introduced to DSM with the use of this new function CYRF_WaitForTxIRQ().

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

PhracturedBlue
Offline

30 Mar 2015 14:18 #30464 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

I don't think the ISR is likely to impact the u8/u32 conversion in any way that matters. I really don't like these voodoo types of changes that don't change anything structural and seem to help reliability. On the other hand, I have no idea what is wrong, can't duplicate the issue, and really appreciate you working on it, so whatever works in the end.

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

PhracturedBlue
Offline

30 Mar 2015 17:27 #30474 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

@linux-user:
Can you confirm the following:
The 1st post 'errors-2.txt' shows an Rx connection loss: www.deviationtx.com/forum/protocol-devel...etry?start=160#30384
The 'errors-bound.txt' file was captured with the Rx still able to connect in: www.deviationtx.com/forum/protocol-devel...etry?start=180#30392
The 'errors-loss-RXon.txt' was captured with the Rx unable to connect

the errors-2.txt and errors-loss-RXon.txt are basically the same (only difference is at the point of capture). errors-bound.txt has the registers in a very different state. Before I dig through them all, I want to make sure I understand what I'm looking at.

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

vlad_vy
Offline

30 Mar 2015 18:20 - 30 Mar 2015 18:38 #30477 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

XACT_CFG_ADR (0x0F)

Bit 5 - Force End State. Setting this bit forces a transition to the state set in END STATE. By setting the desired END STATE at the same time as setting this bit the device may be forced to immediately transition from its current state to any other state. This bit is automatically cleared upon completion. Firmware MUST never try to force END STATE while TX GO is set, nor when RX GO is set and a SOP has already been received (packet reception already in progress).

Before switching to RX mode TX_GO bit always = 0 (wait loop), but before switching to TX mode we don't wait RX_GO bit = 0, so in case of any reception error (probably very rarely) RX_GO bit can remains = 1.

I think will be better before switching TX mode to check RX_GO bit, and if RX_GO = 1, forcibly exit from RX mode.

The recommended method to exit receive mode when an error has occurred is to force END STATE and then dummy read all RX_COUNT_ADR (0x09) bytes from RX_BUFFER_ADR (0x21) or poll RSSI_ADR.SOP (0x13) (bit 7) until set. See XACT_CFG_ADR (0x0F) and RX_ABORT_ADR (0x29) for description.

Last edit: 30 Mar 2015 18:38 by vlad_vy.

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

linux-user
Offline

31 Mar 2015 07:08 - 31 Mar 2015 08:04 #30525 by linux-user

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

PhracturedBlue wrote: @linux-user:
Can you confirm the following:
The 1st post 'errors-2.txt' shows an Rx connection loss: www.deviationtx.com/forum/protocol-devel...etry?start=160#30384

Yes. In other words:
RX was unable to (re)connect, but I am unsure whether RX was powered on or off at the time of capture.
Note:
RX was never continuously running during my tests. So it is always a reconnection attempt.

PhracturedBlue wrote: The 'errors-bound.txt' file was captured with the Rx still able to connect in: www.deviationtx.com/forum/protocol-devel...etry?start=180#30392

It was captured while RX was still bound. (RX powered on and transmitting telemetry values)

PhracturedBlue wrote: The 'errors-loss-RXon.txt' was captured with the Rx unable to connect

Yes. RX was powered on, but unable to connect.

PhracturedBlue wrote: the errors-2.txt and errors-loss-RXon.txt are basically the same (only difference is at the point of capture).

Yes.

PhracturedBlue wrote: errors-bound.txt has the registers in a very different state.

Yes, that is to be expected.

To make the confusion complete

here 2 more likely good ones:
I call it likely as I can't verify if RX would actually reconnect after capture has been taken

errors-good-delay-RXoff.txt - waited until telemetry-values got inverted after RX powered off
errors-good-instant-RXoff.txt - captured instantly after RX powered off.

Last edit: 31 Mar 2015 08:04 by linux-user.

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

linux-user
Offline

31 Mar 2015 07:45 #30526 by linux-user

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

Version deviation-devo10-v4.0.1-db5dcb3.zip from Indigo has been running for 8h.
Checked again after 20h and connection was lost

Indigo wrote: WARNING:
Devo now uses same callback function for Telemetry OFF and ON. I did that to see if the problem would then appear with Telemetry OFF.

Indigo,
can you explain this:
Should we now test with telemetry OFF and check if the error does occur there as well?

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

vlad_vy
Offline

31 Mar 2015 09:50 - 31 Mar 2015 15:52 #30529 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

Abort the receive before switch TX mode, if RX_GO is active.

if(CYRF_ReadRegister(0x05) & 0x80) {
CYRF_WriteRegister(0x29, 0x20);
CYRF_WriteRegister(0x0F, 0x28); what will switch RX mode? 0x2C or 0x28 ???
CYRF_WriteRegister(0x29, 0x00);
}
CYRF_SetTxRxMode(TX_EN); //Write mode

Last edit: 31 Mar 2015 15:52 by vlad_vy.

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

Indigo
Offline

31 Mar 2015 10:21 #30532 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

Yes, please test again with Telemetry OFF.

Combining the 2 callbacks has reduced size of firmware and we need to verify that both modes are still functioning as normal.

I don't see how Telemetry OFF could now suffer from connection loss, but the protocol code is so critical I feel we need to test it anyway to be sure.

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

Indigo
Offline

31 Mar 2015 13:09 - 31 Mar 2015 13:47 #30537 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

vlad_vy wrote: Abort the receive before switch TX mode, if RX_GO is active.

if(CYRF_ReadRegister(0x05) & 0x80) {
CYRF_WriteRegister(0x29, 0x20);
CYRF_WriteRegister(0x0F, 0x2C); what will switch RX mode? 0x2C or 0x28 ???
CYRF_WriteRegister(0x29, 0x00);
}
CYRF_SetTxRxMode(TX_EN); //Write mode

Answer is in Devo.txt in doc directory of source:
0x2C to change from Rx to Tx
0x28 to change from Tx to Rx

Why is it that DSM code sends 0x87 but Devo sends 0x80 to register 05 to put CYRF6936 into Rx mode, even thou document Devo.txt says to send 0x87.

Devo:

     CYRF_SetTxRxMode(RX_EN); //Receive mode
     CYRF_WriteRegister(CYRF_05_RX_CTRL, 0x80); //Prepare to receive (do not enable any IRQ)

DSM:

     CYRF_SetTxRxMode(RX_EN); //Receive mode
     CYRF_WriteRegister(CYRF_05_RX_CTRL, 0x87); //Prepare to receive

Could this be why Devo Telemetry has this lockout bug and DSM doesn't?

Last edit: 31 Mar 2015 13:47 by Indigo.

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

vlad_vy
Offline

31 Mar 2015 13:47 #30541 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

I think it has sence if you use external IRQ pin. It's only mask (bit 0-5) to enable output for various IRQ to the external IRQ pin. The state of all IRQ Status bits is valid regardless of whether or not the IRQ is enabled.

Probably all will work with 0x80 to register 05.

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

PhracturedBlue
Offline

31 Mar 2015 13:52 #30542 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

It is set that way because it doesn't matter. We just don't care if the irq is enabled since the IRQ pin isn't attached to anything.

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

Time to create page: 0.089 seconds

Force desktop display

Support for walkera telemetry.

Attachments: