Serial Communications for A3 1.7 Firmware

[axdhill]

Hi -

It's hard to determine if this is an SDK issue, an A3 issue, or both. I've seen related problems for other people, but in their cases they were using slightly unusual hardware (BeagleBones, etc). I've been attempting to get my A3 to talk over serial with an x86_64 Linux desktop for about a month now, with no luck. I've tried both USB and native serial ports, both with the same issue, seen below:

Serial port = /dev/ttyUSB1 
Baudrate = 38400 
App ID: ***** 
App Key: **** 

Does everything look correct? If not, navigate to Linux/UserConfig.txt and make changes. 

STATUS init,line 51: Attempting to open device /dev/ttyUSB1 with baudrate 38400... 
STATUS init,line 60: ...Serial started successfully. 
STATUS validateSerialDevice,line 118: Succeeded to read from serial device 
ERROR parseDroneVersionInfo,line 249: Drone version was not obtained. Please restart the program or call getDroneVersion 

Attempting activation.. 
ERROR parseDroneVersionInfo,line 249: Drone version was not obtained. Please restart the program or call getDroneVersion 
Automatic activation successful. 
Failed to obtain control. 
Your RC mode switch is not in mode F. (Is the RC connected and paired?) 
This program will exit now.

I have the latest firmware (1.7) and am using the latest SDK (3.2). I don't have an LB2 (I have a basic DT7), but this is supposedly not an issue anymore, correct? Does anyone know the proper serial configuration/flow control for communicating with the A3? The baud rates match and everything is seemingly correct. HOWEVER, when I use a serial monitor to view communications from the A3, they do not seem to be formatted as stated in the Open Protocol manual.

Example serial output from A3 at 38400 baud for native serial port:

0xf8 0x89 0xbf 0x3b 0x0
0xf8 0xda 0xf1 0x99 0x3

Every line is prepended by 0xf8.

For the USB serial adapter, though, each line is prepended with character 0xFF (which is different). According to the open protocol every command should be prepended by 0xAA, right? Any ideas why this would be incorrect? What are the other configuration settings that the Onboard SDK expects from a serial port? Obviously if the SDK is expecting communications to be formatted starting with 0xAA, but the A3 is genuinely sending 0xFF then there's something irreconcilable happening.

I've attempted changing the parity of the serial interface but with no luck (nothing changes - perhaps I have no control over the behavior of the port in the SDK?).

[rohitsantdji]

The OSDK expects an 8N1, no flow control serial config. The 0xFF prepending (or for that matter even a 0xf8 prepeding) appears to indicate a baud rate mismatch to me. Another possiblity could be that the enryption flag is turned ON in DJI_Config.h.

Could you provide screenshots of DJI Assistant 2's SDK page, and pictures of your hardware connections as a starting point for helping us debug this?

[axdhill]

Thanks for your quick reply! The encryption flag is turned off. I attempted forcing 38400 8N1 connection and am using a 1Hz timestamp to debug. I should note that when I send one serial adapter into another (the PC talking to itself) the output signals from the SDK appear to be formatted correctly. Also when I increase the baud rate to 115200 in the PC adapter and in the DJI assistant I do not get anything resembling a command at all.

To explain the second image, the Tx pin of the A3 is going to the Rx pin of a USB-serial db9 connector, the Rx is going to the Tx of the db9, and ground is going to ground.

It could still be that our adapters (both the native port and the USB adapter) are inappropriate for use with the A3 and somehow the baud rate is still not matching (perhaps the buffering is bad). Are there USB/serial adapters which are known to work that our lab could troubleshoot with?

[rohitsantdji]

I believe you will need a level-shifter since the TTL logic for the A3's UART port is not voltage-compatible with RS232 (your DB9 connector) - something like this. Our Hardware Setup Guide recommends this cable.

[axdhill]

Thanks for your patience - I wasn't aware of the TTL/RS232 level differences. We happened to have the same UART cable you listed in our lab and things are working correctly now.

[rohitsantdji]

OK. Great!