Support for walkera telemetry.

vlad_vy
Offline

31 Mar 2015 13:56 - 31 Mar 2015 13:59 #30543 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

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

From CYRF6936 datasheet:

Bits 4-2 Transaction End State. This field defines the mode to which the device transitions after receiving or transmitting a packet. 000 = Sleep Mode; 001 = Idle Mode; 010 = Synth Mode (TX); 011 = Synth Mode (RX); 100 = RX Mode. In normal use, this field is typically set to ‘000’ or ‘001’ when the device is transmitting packets, and ‘100’ when the device is receiving packets. Note that when the device transitions to receive mode as an END STATE, the receiver must still be armed by setting RX GO before the device can begin receiving data. If the system only supports packets less than or equal to 16 bytes then firmware should examine RXC IRQ and RXE IRQ to termine the status of the packet. If the system supports packets more than 16 bytes, make sure that END STATE is not sleep, force RXF = 1, perform receive operation, force RXF = 0, and if necessary set END STATE back to sleep.

That way 0x2C = RX mode and 0x28 = TX mode. That's why I'm asking.

Last edit: 31 Mar 2015 13:59 by vlad_vy.

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

Indigo
Offline

31 Mar 2015 13:59 #30544 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

Why is transmission error bit not checked?

Shouldn't tx_State be checked within or after wait loop.
(CYRF_ReadRegister(CYRF_04_TX_IRQ_STATUS) & 0x01)

If there is no ACK from Rx shouldn't Tx re-transmit last packet until an ACK is received. That would help keep Tx and Rx in sync.

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

PhracturedBlue
Offline

31 Mar 2015 14:00 #30545 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

I don't have any description of how synth mode differs from normal mode. I am not sure what impact using states 010 and 011 vs using 001 and 100 in refister 0x0f. This was just copied from the devo protocol trace.

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

vlad_vy
Offline

31 Mar 2015 14:17 #30548 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

Indigo wrote: Why is transmission error bit not checked?

Shouldn't tx_State be checked within or after wait loop.
(CYRF_ReadRegister(CYRF_04_TX_IRQ_STATUS) & 0x01)

If there is no ACK from Rx shouldn't Tx re-transmit last packet until an ACK is received. That would help keep Tx and Rx in sync.

It works for transaction mode only.

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

PhracturedBlue
Offline

31 Mar 2015 15:45 #30552 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

Looking at linux_user's logs, I see the following potential issues:
in the logs where reconnect doesn't work:
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

With so few data points it is difficult to know if these are just flukes (we are capturing data at an arbitrary time) but the above differences stand out. I think the 1st case was already noted by vlad. we could add more checking for error flags and see if we can clear them if they occur.

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

cmpang
Offline

31 Mar 2015 17:55 #30561 by cmpang

Replied by cmpang on topic Support for walkera telemetry.

Indigo wrote: Yes, please test again with Telemetry OFF....

I can confirm that ever since the offical 4.0.1-92e1705, everything works fine with Telemetry OFF... I back this up with hundreds of reliable flights. The only crashes happened while I forgot to switch off Telemetry. This applies to Devo.

As for the DSM protocol, thanks to Indigo's build 67f35d0. Now that I can also turn off Telemetry and get rock solid connection under DSM2/x too.

cmPang

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

PhracturedBlue
Offline

31 Mar 2015 18:08 #30562 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

I'd like to add some extra error checking. Maybe the following:
Reg04, check TXC (before switching to Rx mode), and TXVERR and TXE. If TXC is not set or TXVERR or TXE are, we should log this. Same for if TXGO is set when we want to switch to Rx mode

I have evidence that the official firmware actually has CYRF lockup detection that will send a Reset() and Init() if the chip gets into an illegal state. We could actually code that into the protocol if certain errors are found. It would be better to pay the few msec to reinitialize the chip than to lose contact for a longtime. Just need to find a reliable flag for when to do it.

linux-user: do you have a USB-to-UART that you could use to capture logs over serial? I can add info to the Error.log, but that file is not ideal for this type of logging.

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

vlad_vy
Offline

31 Mar 2015 18:37 #30564 by vlad_vy

Replied by vlad_vy on topic Support for walkera telemetry.

For my opinion the problem has place in time switching from RX to TX mode. I don't see in code any reliable test for RX_GO=0 before switching to TX mode. For example, if last telemetry poll doesn't comply with conditions for any reason (receiving not completed, any error) we can switch on TX mode with RX_GO=1.

TX mode only works reliable.

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

PhracturedBlue
Offline

31 Mar 2015 18:51 #30567 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

I don't disagree, but I think it is more reliable to detect a failure on the transmit side. We should certainly be careful about setting FRC_END. But a failed Rx has little meaning, whereas a failed TX has a very clear meaning. liunux_user's logs did indicate FRC_END being high while TX_GO was enabled which should never happen.

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

linux-user
Offline

31 Mar 2015 19:00 - 31 Mar 2015 19:02 #30568 by linux-user

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

PhracturedBlue wrote: linux-user: do you have a USB-to-UART that you could use to capture logs over serial? I can add info to the Error.log, but that file is not ideal for this type of logging.

Uhh, I am not sure.
I have a "Walkera UP02"
Could this be used for your logging idea?

This is what "lsusb" tells about it.

Bus 001 Device 112: ID 0483:5740 SGS Thomson Microelectronics 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0483 SGS Thomson Microelectronics
  idProduct          0x5740 
  bcdDevice            2.00
  iManufacturer           1 STMicroelectronics
  iProduct                2 STM32 Virtual COM Port  
  iSerial                 3 STM32 devention
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           67
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0002
  (Bus Powered)
  Remote Wakeup Enabled

Last edit: 31 Mar 2015 19:02 by linux-user.

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

PhracturedBlue
Offline

31 Mar 2015 19:56 #30571 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

it probably could, but I don't know how to make it do so. I'll think about easy log options

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

victzh
Offline

31 Mar 2015 20:11 #30572 by victzh

Replied by victzh on topic Support for walkera telemetry.

If Walkera's designs are somewhat consistent and they reused 3.5mm jack layout from model to model you just plug UP02 into Devo and open corresponding COM port on your PC. It's a standard CDC device.

Can you see UP02 in Device Manager as COM port?

There is a chance that TX and RX are in the wrong order, but it is worth trying to check it.

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

Indigo
Offline

31 Mar 2015 22:21 #30585 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

I didn't know TX_IRQ_STATUS and RX_IRQ_STATUS both require a 2nd check when status is complete with no errors. To meet this requirement are these revised code sections:

Wait loop:

void CYRF_WaitForTxIrq()
{
    unsigned i = 0;
    unsigned tx_state = 0x00;
    while ((tx_state & 0x02) == 0x00 && ++i < NUM_WAIT_LOOPS) {
        tx_state |= CYRF_ReadRegister(CYRF_04_TX_IRQ_STATUS);
    }
    if ((tx_state & 0x03) == 0x02)  // RXC=1, RXE=0 then 2nd check is required (debouncing)
        CYRF_ReadRegister(CYRF_04_TX_IRQ_STATUS);
}

DSM:

        //Read telemetry if needed and parse if good
        u8 rx_state = CYRF_ReadRegister(CYRF_07_RX_IRQ_STATUS);
        if ((rx_state & 0x02) && !(CYRF_ReadRegister(CYRF_05_RX_CTRL) & 0x80)) {
            //Receive complete and not currently receiving
            CYRF_ReadDataPacket16(pktTelem);
        }
        if (((rx_state & 0x03) == 0x02) &&  // RXC=1, RXE=0 then 2nd check is required (debouncing)
            !(CYRF_ReadRegister(CYRF_07_RX_IRQ_STATUS) & 0x01) && ((rx_state & 0x25) == 0x20)) {
            //Receive buffer full with no receive error or badCRC
            parse_telemetry_packet();
        }

Devo:

        u8 rx_state = CYRF_ReadRegister(CYRF_07_RX_IRQ_STATUS);
        if ((rx_state & 0x02) && !(CYRF_ReadRegister(CYRF_05_RX_CTRL) & 0x80)) {
            //Receive complete and not currently receiving
            CYRF_ReadDataPacket(telem_pkt);
        }
        if (((rx_state & 0x03) == 0x02) &&  // RXC=1, RXE=0 then 2nd check is required (debouncing)
            !(CYRF_ReadRegister(CYRF_07_RX_IRQ_STATUS) & 0x01) && ((rx_state & 0x25) == 0x20)) {
            //Receive buffer full with no receive error or badCRC
            scramble_pkt(telem_pkt); //This will unscramble the packet
            if ((telem_pkt[0] & 0xF0) == TELEMETRY_ENABLE
             && telem_pkt[13] == (fixed_id  & 0xff)
             && telem_pkt[14] == ((fixed_id >> 8) & 0xff)
             && telem_pkt[15] == ((fixed_id >> 16) & 0xff))
            {
                parse_telemetry_packet(telem_pkt);
            }
            delay = 100 * (15 - txState);
            txState = 14;
        }

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

Indigo
Offline

31 Mar 2015 23:32 #30591 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

vlad_vy wrote: 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.

I will add a CYRF_DummyRead() function.

And use that function to clear read buffer whenever data is bad or incomplete and only ever copy good data into telem_pkt.

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

linux-user
Offline

01 Apr 2015 07:23 - 01 Apr 2015 13:12 #30605 by linux-user

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

victzh wrote: If Walkera's designs are somewhat consistent and they reused 3.5mm jack layout from model to model you just plug UP02 into Devo and open corresponding COM port on your PC. It's a standard CDC device.

Can you see UP02 in Device Manager as COM port?

There is a chance that TX and RX are in the wrong order, but it is worth trying to check it.

"MS-Windows7" device manager says "STM32 Virtual COM Port", but wants to have a driver for it.
The nice part of "UP02" is that it would fit "plug and play" into the Devo 3.5mm jack
In Linux it shows up as "/dev/ttyACM0"

as well as "/dev/tty10"
See: What does ttyACM mean
dmesg says:

[10555842.660907] usb 1-1.2: new full-speed USB device number 120 using ehci_hcd
[10555842.748011] usb 1-1.2: New USB device found, idVendor=0483, idProduct=5740
[10555842.748017] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[10555842.748022] usb 1-1.2: Product: STM32 Virtual COM Port  
[10555842.748025] usb 1-1.2: Manufacturer: STMicroelectronics
[10555842.748029] usb 1-1.2: SerialNumber: STM32 devention
[10555842.748527] cdc_acm 1-1.2:1.0: This device cannot do calls on its own. It is not a modem.
[10555842.748551] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device

I have another device that seems to be a USB-to-UART, but that would require some instructions for me how to hook it up to the Devo.

Bus 001 Device 117: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x Composite Device
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x10c4 Cygnal Integrated Products, Inc.
  idProduct          0xea60 CP210x Composite Device
  bcdDevice            1.00
  iManufacturer           1 Silicon Labs
  iProduct                2 CP2102 USB to UART Bridge Controller
  iSerial                 3 0001
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              2 CP2102 USB to UART Bridge Controller
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

Last edit: 01 Apr 2015 13:12 by linux-user.

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

linux-user
Offline

01 Apr 2015 09:14 #30608 by linux-user

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

Indigo wrote: Yes, please test again with Telemetry OFF.

Indigo's version deviation-devo10-v4.0.1-db5dcb3.zip is still running this test for 26h now, with Telemetry OFF

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

Indigo
Offline

01 Apr 2015 12:08 #30609 by Indigo

Replied by Indigo on topic Support for walkera telemetry.

Thanks, that's long enough. I was not expecting any change. If you now turn Telemetry ON you should see how many Frame Losses and Holds there has been.

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

linux-user
Offline

01 Apr 2015 12:18 - 01 Apr 2015 12:26 #30610 by linux-user

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

Indigo wrote: If you now turn Telemetry ON you should see how many Frame Losses and Holds there has been.

Not on Devo
Even on DSM I would expect to see zero holds etc. as my test involves always a reconnect (=reset) of the RX

Last edit: 01 Apr 2015 12:26 by linux-user.

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

PhracturedBlue
Offline

01 Apr 2015 13:09 #30611 by PhracturedBlue

Replied by PhracturedBlue on topic Support for walkera telemetry.

I tried my UP-02 and it doesn't work. That isn't surprising because I tried programming my Devo7 with a standard UART and it didn't work either.

The Cignal device looks more promising, but with only 3 wires, they are probably power, ground, and Tx, with no Rx line (or it may be shared). Either way, probably won't work well here.

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

linux-user
Offline

01 Apr 2015 13:34 - 01 Apr 2015 14:26 #30612 by linux-user

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

PhracturedBlue wrote: The Cignal device looks more promising, but with only 3 wires, they are probably power, ground, and Tx, with no Rx line

As the Spirit Software can read and write to Spirit-FBL I would guess:
RX TX (orange red) and ground (brown). But either way I would need instructions how to hook it up.
Edit:
I am sure, there is NO power line; Spirit-FBL can't be powered via USB.

Last edit: 01 Apr 2015 14:26 by linux-user.

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

Time to create page: 0.093 seconds

Force desktop display