P3 Serial Data

[GlovePuppet]

I have been logging some of the serial interfaces. The packet structure is similar to the packet structure of the NAZAM/P2 - DJI Assistant. The same 16 bit CRC is used but with a different seed. This code will calculate the CRC on all the interfaces I have sniffed so far:

import struct

def calc_checksum(packet): crc =[0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78]

# v = 0x1012 #Naza M # v =0x1013 #Phantom 2 # v =0x7000 #Naza M V2 v = 0x3692 #P3

for i in range(0, len(packet)-2): vv = v >> 8 v = vv ^ crc[((packet[i] ^ v) & 0xFF)] return v

packet = bytearray.fromhex(u'55 12 00 a6 a0 00 40 00 00 00 00 00 00 00 00 00 d3 df') print ' '.join(format(x, '02X') for x in packet) crc = calc_checksum(packet) print "%02X %02X" % (crc & 0xFF, crc >> 8)

Edit: fixed missing packet

[GlovePuppet]

Some logging on the ESC bus

1) Packets sent at 11ms interval

2) After power up FC sends the same packet 16 times to each ESC (I am guessing ESC 0,1,2,3) 16 55 12 00 a6 a0 00 40 00 00 00 00 00 00 00 00 00 d3 df 16 55 12 00 a6 a0 00 40 01 00 00 00 00 00 00 00 00 2e 92 16 55 12 00 a6 a0 00 40 02 00 00 00 00 00 00 00 00 29 44 16 55 12 00 a6 a0 00 40 03 00 00 00 00 00 00 00 00 d4 09

I didn't see any data from the ESCs, there may be a signal from ESC to FC thatcauses FC to move on to the next ESC but I don't think its sent on the serial interface.

3) FC changes the sequence 55 12 00 a6 a0 00 00 00 00 00 00 00 00 00 00 00 a8 8e 55 12 00 a6 a0 00 00 01 00 00 00 00 00 00 00 00 55 c3 55 12 00 a6 a0 00 00 02 00 00 00 00 00 00 00 00 52 15 55 12 00 a6 a0 00 00 03 00 00 00 00 00 00 00 00 af 58 55 12 00 a6 a0 00 00 00 00 00 00 00 00 00 00 00 a8 8e 55 12 00 a6 a0 00 00 01 00 00 00 00 00 00 00 00 55 c3 ...

CRCs can be checked using code above

[mefistotelis]

This is great. Will help a lot anyone diagnosing ESC issue.

There definitely is some kind of ESC-to-FC communication. FC is able to read some of ESC parameters:

3.732 : 3013 :      41 ESC0 link up
3.778 : 3041 :      43 esc alive info = 0xf
4.732 : 3613 :      91 ESC0 version: Protocol = [V1.0] Hardware = "WM320_FOC_V4" 
4.732 : 3613 :      91 Loader   = [V00.00.01.01] 
4.732 : 3613 :      91 Firmware = [V01.10.00.00] 

(this is P3 Adv log during startup)

[GlovePuppet]

Yeah, I see that in the FC binary. What I haven't seen is anything going from the ESC to the FC. I will make some more logs ...

I'm really suspicious about where the versioning info is stored, I sort-of think its all stored in the F072 (or the Nuvoton in older boards): -Downgrade after flashing this MOVM0fw.bin file -Its reads its own version from a chunk of flash -It can erase 64 bytes in that area

[coptersafe]

0 eeprom load  1   32   28   32
0 eeprom load  2   64   34   40
0 eeprom load  3  104   20   24
0 eeprom load  4  128  132  136
0 eeprom load  5  264  128  136
0 eeprom load  6  400   12   16
0 eeprom load  7  416   40   48
0 eeprom load  8  464    9   16
0 eeprom load  9  480    1    8
0 eeprom load 10  488    6   16
0 eeprom load 11  504    4    8
0 eeprom load 12  512   52   56
0 eeprom load 13  568    8   16
0 eeprom load 14  584    7   16
0 eeprom load 15  600   12   16
0 eeprom load 16  616   38   48
0 eeprom load 17  664   12   16
0 eeprom load 18  680   56   64
0 eeprom load 19  744   32   40
0 eeprom load 20  784    1    8
0 eeprom load 21  792   16   24
0 eeprom load 22  816   16   24
0 eeprom load 23  840    1    8
0 eeprom load 24  848    1    8
0 eeprom load 25  856   10   16
0 eeprom load 26  872   36   40
0 eeprom load 27  912   52   56
0 eeprom load 28  968   44   48
0 eeprom load 29 1016   28   32
0 eeprom load 30 1048   18   24
0 eeprom load 31 1072   16   24
0 eeprom load 32 1096   72   80
0 eeprom load 33 1176   24   32
0 eeprom load 34 1208   64   72
0 eeprom load 35 1280   24   32
0 eeprom load 36 1312   96  104
0 mis cali 55 55 913e fff0 cnt:0
0 imu status:0
0 [hardfault]:******************check fault info and trace ************
0 [hardfault]:-----fault is null: addr(0x40024000),flag(0xb201880c)-----
0 [hardfault]:-----fault is null: addr(0x400241a0),flag(0x632a415d)-----
0 [hardfault]:-----task info  is null: addr(0x40024340),flag(0x5c94669d)-----
0 [hardfault]:-----trace info  is null: addr(0x400244d0),flag(0x09683d30)-----
0 [hardfault]:******************check last trace ******************
0 [hardfault]:-----trace info  is null: addr(0x40024790),flag(0x1d32cec0)-----
0 [hardfault]:-----wdg_time_info is null: addr(0x40024a50),flag(0x89ad703c)-----
1 airport limit inited[1]
1 compass calibration init!
1 [LED] changed: test led when startup
1 app connect changed:last(255) != current(0)
1 assistant connect changed:last(255) != current(0)
1 [FDI MAGN[1]] event:turn on
1 [FDI GYRO[1]] event:turn on
1 [FDI ACC[1]] event:turn on
1 [FDI BARO[1]] event:turn on
1 [FDI AHRS[1]]:turn on
1 [FDI CTRL] event: turn on
1 iwdt_timeout_check call SWD_Handler g_swdg_timeout_max(0x00000120) 
1 [hardfault]:__nmi_hander,tick(4187)
1 temp cali (0.000000,0.000000) 0 fw:4 4
1 temp cali 0 bw:0.000000 0.000000 0.000000 ba:0.000000 0.000000 0.000000
1 app temp cali (58.000000,65.000000) aa fw:6 6
1 app temp cali aa bw:-0.000123 0.000132 0.000320 ba:-0.000219 0.000062 -0.000158
4 [esc_is_stall] status changed: last(0xffffffff) != current(0x00000000)
4 [esc_is_empty] status changed: last(0xffffffff) != current(0x00000000)
5 [hardfault]:******************find fault info ************
5 [hardfault]:-----nmi_fault: addr(0x40024000),flag(0xabcdef01)-----
5 [hardfault]:-----fault info-----
5 [hardfault]:fault source is "task"
5 [hardfault]:tick:4187.ts:6.978s, timebase(0x00000000226e06a7)
5 [hardfault]:----------spec_reg info----------
5 [hardfault]:BFAR  0xe000ed38
5 [hardfault]:CFSR  0x00000000
5 [hardfault]:HFSR  0x00000000
5 [hardfault]:DFSR  0x00000000
5 [hardfault]:AFSR  0x00000000
5 [hardfault]:----------contex info----------
5 [hardfault]:r0    0x0004112f
5 [hardfault]:r1    0x0000dac0
5 [hardfault]:r2    0x0000000d
5 [hardfault]:r3    0x00000002
5 [hardfault]:r12   0x0f400000
5 [hardfault]:lr    0x080899af
5 [hardfault]:pc    0x08092986
5 [hardfault]:psr   0x21000000
5 [hardfault]:StkPtr(0x2002c804),TaskState(0x00000000)
5 [hardfault]:r4(0x00000000),r5(0x00000000),r6(0x00000000),r7(0x00000000)
5 [hardfault]:r8(0x00000000),r9(0x00000000),r10(0x00000000),r11(0x00000000)
5 [hardfault]:r3_lr(0x00000000),psp(0x00000000)
6 [hardfault]:0x2002c8b0:  44160000  41f00000  00000000  00000000 
6 [hardfault]:0x2002c8c0:  00000000  00000000  20000011  08089989 
6 [hardfault]:0x2002c8d0:  000000a1  00000017  20013d24  20027f24 
6 [hardfault]:0x2002c8e0:  00000002  00000000  0000fe00  20027f24 
6 [hardfault]:0x2002c8f0:  00000015  08089865  00000000  00000014 
6 [hardfault]:0x2002c900:  00000002  0803c915  00000000  20027f63 
6 [hardfault]:0x2002c910:  00000014  00000015  00000000  20027f24 
6 [hardfault]:0x2002c920:  0000fe00  0803c96d  00000000  20027f63 
6 [hardfault]:0x2002c930:  00000034  00000000  2001c41a  20027f63 
6 [hardfault]:0x2002c940:  00000040  20027f24  11111111  0803c9b7 
6 [hardfault]:0x2002c950:  2002c9f8  00000002  00000000  08038aa7 
6 [hardfault]:0x2002c960:  0000000c  2001c41a  00000000  00000000 
6 [hardfault]:0x2002c970:  00000000  00000000  00000000  00000000 
6 [hardfault]:0x2002c980:  20027f24  20027f63 
6 [hardfault]: << 08089989 << 08089865 << 0803c915 << 0803c96d << 0803c9b7 << 08038aa7
6 [hardfault]:-----fault is null: addr(0x400241a0),flag(0x00000000)-----
6 [hardfault]:StkBasePtr(0x2002baa8),StkEndPtr(0x2002bea8)
6 [hardfault]:StkPtr(0x2002bdac),TaskState(0x00000003)
6 [hardfault]:r4(0x080349a6),r5(0x01000000),r6(0x4cc517ba),r7(0x44160000)
6 [hardfault]:r8(0x4e6e6b28),r9(0x49cb7355),r10(0x00000000),r11(0x00000000)
6 [hardfault]:r3_lr(0x080349a7),psp(0x2002be48)
6 [hardfault]:r4(0x080349a6),r5(0x01000000),r6(0x4fbe9d80),r7(0x4ca037a0)
6 [hardfault]:r8(0x4e6e6b28),r9(0x413e79e8),r10(0x38bfe7cd),r11(0x418e2bbf)
6 [hardfault]:r3_lr(0x080349a7),psp(0x2002dea8)
6 [hardfault]:----------task "task_d" tcb_info----------
6 [hardfault]:StkBasePtr(0x2002df08),StkEndPtr(0x2002e308)
6 [hardfault]:StkPtr(0x2002e20c),TaskState(0x00000000)
6 [hardfault]:r4(0x080349a6),r5(0x01000000),r6(0x00000000),r7(0x44160000)
6 [hardfault]:StkPtr(0x2002d60c),TaskState(0x00000000)
6 [hardfault]:r4(0x080349a6),r5(0x01000000),r6(0x00000000),r7(0x00000000)
6 [hardfault]:r8(0x00000000),r9(0x37c65940),r10(0x00000000),r11(0x00000000)
6 [hardfault]:r3_lr(0x080349a7),psp(0x2002d6a8)
6 [hardfault]:-----irq_trace is null,addr(0x400244d0),flg(0x00000000)-----
102 [FDI AHRS[1]]:init fdi turn on
102 [FDI AHRS[1]]:wait for sensor check
111 [LED] changed: temperature not ready when startup
142 esc alive info = 0x0
155 old.IOC reset intelligence_orientation_enabled
155 [BATTERY]:reset default smart cfg - L1:1  L2:2
155 [smart_battery]this fireware calc gohme speed:7.800000 - land speed:2.500000
155 [Ctrl<1>] REQ_RC_NORMAL ATTI ctrl_atti
161 Eeprom write offset:1d0
183 [LED] changed: no atti
198 [FDI AHRS[1]]:(mxyz)compass stuck!!!
201 [FDI AHRS[1]]:(wxyz)wait for static when init

[coptersafe]

first parts of listing - STM32 read config from at88 eprom

[coptersafe]

in a P3 PRO and P3ADV in ESC , DJU use remarked TMS320f28027f

[coptersafe]

load 0 0 140 144 g_config.rc_cfg load 1 144 76 80 g_config.mr_craft load 2 224 96 104 g_config.imu_gps load 3 328 348 352 g_config.control load 4 680 8 16 g_config.engine load 5 696 1 8 g_config.advanced_function load 6 704 2 8 g_config.fail_safe load 7 712 20 24 g_config.go_home load 8 736 8 16 g_config.intelligence_orientation load 9 752 28 32 g_config.flying_limit load 10 784 12 16 g_config.voltage load 11 800 16 24 g_config.voltage2 load 12 824 96 104 g_config.imu_para_cfg load 13 928 3 8 g_config.mag_cfg load 14 936 2 8 g_config.gyr_acc_cfg load 15 944 1 8 g_config.baro_cfg load 16 952 1 8 g_config.zenmuse_cfg load 17 960 1 8 g_config.gps_cfg load 18 968 12 16 g_config.mode_novice_cfg load 19 984 8 16 g_config.mode_tripod_en_cfg load 20 1000 20 24 g_config.mode_wifi_rc_cfg load 21 1024 44 48 g_config.mode_gentle_cfg load 22 1072 44 48 g_config.mode_sport_cfg load 23 1120 44 48 g_config.mode_normal_cfg load 24 1168 44 48 g_config.mode_tripod_cfg load 25 1216 20 24 g_config.mode_manual_cfg load 26 1240 16 24 g_config.gear_cfg load 27 1264 4 8 g_config.esc_cfg load 28 1272 36 40 g_config.imu_direction load 29 1312 40 48 g_config.api_entry_cfg load 30 1360 8 16 g_config.avoid_obstacle_limit_cfg load 31 1376 38 48 g_config.fdi_open load 32 1424 32 40 g_config.fdi_switch load 33 1464 8 16 g_config.fdi_fit_rc load 34 1480 16 24 g_config.misc_cfg load 35 1504 16 24 g_config.takeoff load 36 1528 32 40 g_config.landing load 37 1568 64 72 g_config.hotpoint load 38 1640 8 16 g_config.home_lock load 39 1656 16 24 g_config.followme load 40 1680 32 40 g_config.waypoint_cfg load 41 1720 12 16 g_config.gs load 42 1736 2 8 g_config.stop_motor load 43 1744 16 24 g_config.f_chl load 44 1768 44 48 g_config.sim load 45 1816 56 64 g_config.air_est load 46 1880 20 24 g_config.ahrs_debug_in load 47 1904 112 120 g_config.actuator.cfg load 48 2024 12 16 g_config.factory_test_cfg load 49 2040 48 56 g_config.farm load 50 2096 44 48 g_config.airport_limit_cfg load 51 2144 18 24 g_config.bat_config load 52 2168 12 16 g_config.rc_lost_search load 53 2184 24 32 g_config.waypoint_break_point load 54 2216 1 8 g_config.device

[GlovePuppet]

Probably there was something wrong with my P3S or my setup :S Here's a log from a working pro or maybe advanced version:

Note: F: data sent by FC E: data sent by ESC 115200 8N1 CRC seems to work as above

FC polling for ESC

F:55 12 00 a6 a0 00 40 00 00 00 00 00 00 00 00 00 d3 df E:55 1c 00 7a a0 01 00 13 00 00 00 00 00 00 00 00 00 00 00 00 c0 0f 00 00 00 00 6d e4 F:55 12 00 a6 a0 00 40 01 00 00 00 00 00 00 00 00 2e 92 E:55 1c 00 7a a0 01 01 13 00 00 00 00 00 00 00 00 00 00 00 00 c0 0f 00 00 00 00 3b 3b F:55 12 00 a6 a0 00 40 02 00 00 00 00 00 00 00 00 29 44 E:55 1c 00 7a a0 01 02 13 00 00 00 00 00 00 00 00 00 00 00 00 c0 0f 00 00 00 00 d0 52 F:55 12 00 a6 a0 00 40 03 00 00 00 00 00 00 00 00 d4 09 E:55 1c 00 7a a0 01 03 13 00 00 00 00 00 00 00 00 00 00 00 00 c0 0f 00 00 00 00 86 8d

Polling changes

F:55 12 00 a6 a0 00 00 00 00 00 00 00 00 00 00 00 a8 8e E:55 1c 00 7a a0 01 00 13 00 00 00 00 00 00 00 00 00 00 00 00 c0 0f 00 00 00 00 6d e4 F:55 12 00 a6 a0 00 00 01 00 00 00 00 00 00 00 00 55 c3 E:55 1c 00 7a a0 01 01 13 00 00 00 00 00 00 00 00 00 00 00 00 c0 0f 00 00 00 00 3b 3b

Identify ESCs

F:55 0d 04 33 03 0c 01 00 40 00 01 c3 41 E:55 2b 04 58 0c 03 01 00 c0 00 01 00 10 57 4d 33 32 30 5f 45 53 43 5f 56 39 00 00 00 00 02 02 00 01 00 00 0a 01 19 3c 01 04 8e 7f F:55 0d 04 33 03 2c 02 00 40 00 01 6f d9 E:55 2b 04 58 2c 03 02 00 c0 00 01 00 10 57 4d 33 32 30 5f 45 53 43 5f 56 39 00 00 00 00 02 02 00 01 00 00 0a 01 ea 8c 01 04 e6 42 F:55 0d 04 33 03 4c 03 00 40 00 01 9a 55 E:55 2b 04 58 4c 03 03 00 c0 00 01 00 10 57 4d 33 32 30 5f 45 53 43 5f 56 39 00 00 00 00 02 02 00 01 00 00 0a 01 44 ad 01 04 df 05 F:55 0d 04 33 03 6c 04 00 40 00 01 26 e0 E:55 2b 04 58 6c 03 04 00 c0 00 01 00 10 57 4d 33 32 30 5f 45 53 43 5f 56 39 00 00 00 00 02 02 00 01 00 00 0a 01 6c e5 01 04 c8 7e

Polling continues

F:55 12 00 a6 a0 00 00 02 00 00 00 00 00 00 00 00 52 15 E:55 1c 00 7a a0 01 02 13 00 00 00 00 00 00 00 00 00 00 00 00 c0 0f 00 00 00 00 d0 52 F:55 12 00 a6 a0 00 00 03 00 00 00 00 00 00 00 00 af 58 E:55 1c 00 7a a0 01 03 13 00 00 00 00 00 00 00 00 00 00 00 00 c0 0f 00 00 00 00 86 8d F:55 12 00 a6 a0 00 00 00 00 00 00 00 00 00 00 00 a8 8e E:55 1c 00 7a a0 01 00 13 00 00 00 00 00 00 00 00 00 00 00 00 c0 0f 00 00 00 00 6d e4 F:55 12 00 a6 a0 00 00 01 00 00 00 00 00 00 00 00 55 c3 E:55 1c 00 7a a0 01 01 13 00 00 00 00 00 00 00 00 00 00 00 00 c0 0f 00 00 00 00 3b 3b

Probable "Identify ESCs" payload

c0 00 01 00 10 57 4d 33 32 30 5f 45 53 43 5f 56 39 = WM320_ESC_V9 00 00 00 00 02 02 00 01 00 00 0a 01 19 3c 01 04

[GlovePuppet]

Here's a snippet from a similar log (does not match exactly)

3.762 : 3019 : 42 ESC0 link up 3.773 : 3026 : 43 ESC1 link up 3.785 : 3033 : 43 ESC2 link up 3.797 : 3040 : 44 ESC3 link up 3.797 : 3040 : 44 esc alive info = 0xf

The 0x0F in alive info looks like a bitwise OR of all the ESCs (FC code seems to support upto 8 ESC)

4.760 : 3618 : 92 ESC0 version: Protocol = [V1.0] Hardware = "WM320_ESC_V9" 4.760 : 3618 : 92 Loader = [V01.00.02.02] 4.760 : 3618 : 92 Firmware = [V01.11.00.00] ...

Probable "Identify ESCs" payload c0 00 01 00 = Protocol

10 = length of string 57 4d 33 32 30 5f 45 53 43 5f 56 39 00 00 00 00 = WM320_ESC_V9

02 02 00 01 = Loader 00 00 0a 01 = Firmware (note mismatch 10 != 11) 19 3c 01 04

[GlovePuppet]

Command packet format (not FC-ESC packets tho):

0: Always 0x55 1: Length of packet (N) 2: 3: 4: Packet source ? 5: Packet destination ? 6: Sequence Number 7: 8: 9: Command (LSB) A: Command (MSB) ... N-2: CRC (LSB) N-1: CRC (MSB)

[GlovePuppet]

FC commands identified so far

Inquiry (fetches FC serial number + ???) 0100 [02 -> 03] 0D : 55 0D 04 33 02 03 0C 0D 40 00 01 64 14 0100 [03 -> 02] 2C : 55 2C 04 36 03 02 0C 0D 80 00 01 00 00 30 33 5A 30 35 31 30 38 31 32 00 00 00 00 00 00 09 00 02 22 07 0A 04 02 09 00 00 00 01 78 A5

Licensing (fetches MD5, License flags & ???) 7003 [02 -> 03] 0D : 55 0D 04 33 02 03 0C 0D 40 03 70 02 5C 7003 [03 -> 02] 44 : 55 44 04 1A 03 02 0C 0D 80 03 70 01 65 30 61 38 64 64 36 33 63 61 61 31 65 32 36 36 64 61 62 65 36 36 33 33 66 33 34 36 66 36 38 31 00 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 1B 00 00 00 77 78

Similar cmd 7103 [02 -> 03] 0D : 55 0D 04 33 02 03 0C 0D 40 03 71 8B 4D 7103 [03 -> 02] 44 : 55 44 04 1A 03 02 0C 0D 80 03 71 00 65 30 61 38 64 64 36 33 63 61 61 31 65 32 36 36 64 61 62 65 36 36 33 33 66 33 34 36 66 36 38 31 00 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 00 1B 00 00 00 81 F0

Fetch serial number 7403 [02 -> 03] 0D : 55 0D 04 33 02 03 0C 0D 40 03 74 26 1A 7403 [03 -> 02] 18 : 55 18 04 20 03 02 0C 0D 80 03 74 00 30 33 5A 30 35 31 30 38 31 32 97 4F

Performs read of EEPROM address FC0, returns <read result, read byte> 7603 [02 -> 03] 0D : 55 0D 04 33 02 03 0C 0D 40 03 76 34 39 7603 [03 -> 02] 0F : 55 0F 04 A2 03 02 0C 0D 80 03 76 01 FF 2D B2

Writes byte to EEPROM address FC0, then performs read of EEPROM address FC0, returns <read result, read byte> 7503 [02 -> 03] 0D : 55 0D 04 33 02 03 0C 0D 40 03 75 XX crc crc 7503 [03 -> 02] 0F : 55 0F 04 A2 03 02 0C 0D 80 03 75 01 XX crc crc

[GlovePuppet]

The Inquiry (0x0100) command is implemented by a lot of 'devices' that communicate on the serial bus. The Inquiry response is an ASCII string, so far I have logged responses from these source IDs

1 - FC300C Ver.A 2 3 - 03Z0510812 (Serial number / MC ID of the FC) 4 - DJ29041209 5 - Unknown (FC expects Inquiry response from this device) 6 7 - WM321-01 8 9 A B - Probably battery (FC expects Inquiry response from this device) C - WM305_CENT_T2 D E F 10 11 - Unknown (FC expects Inquiry response from this device)

Any one know what these WM part numbers are?

[coptersafe]

i will check this commands on Inspire..

[coptersafe]

m0100 = 01 camera module - m0101 = 21 camera module m0102 = 41 m0103 = 61 m0104 = 81 camera module - lens m0105 = a1 m0106 = c1 camera module - RAW LINUX camfpga

m0305 = a3 main controller LDR m0306 = c3 main controller APP

m0400 = 04 gimbal m0401 = 24 gimbal driver m0402 = 44 gimbal driver m0403 = 64 gimbal driver m0404 = 84 m0405 = a4 m0406 = c4 m0407 = e4 //founded in M600

m0500 = 05 central board

m0600 = 06 m0601 = 26 FOCUS CONTROL m0602 = 46 m0603 = 66 m0604 = 86 m0605 = a6 m0606 = c6 m0607 = e6 ZT300 DATALINK PRO

m0700 = 07 module - OSMO

m0800 = 08 DaVinchi Dm365 Linux - video encoder m0801 = 28 IG810 LB2_ENC air m0802 = 48 m0803 = 68 m0804 = 88 m0805 = a8 m0806 = c8 m0807 = e8 camera module - Flir

m0900 = 09 NXP LPC1765 - hardware button m0901 = 29 NXP LPC1765 - hardware button

m1000 = 0a m1001 = 1a m1002 = 3a AM603

m1100 = 0b battery controller APP m1101 = 2b battery m1102 = 4b battery
m1103 = 6b battery
m1104 = 8b battery
m1105 = ab battery
m1106 = cb battery

m1200 = 0c esc0(1) m1201 = 2c esc1(2) m1202 = 4c esc2(3) m1203 = 6c esc3(4) m1204 = 8c esc4(5) m1205 = ac esc5(6) m1206 = cc esc6(7) m1207 = dc esc7(8)

Пульт m1300 = 0d DaVinchi Dm365 Linux - video decoder m1301 = 2d DaVinchi Dm385 Linux - video decoder

Пульт m1400 = 0e hardware button and joys LB m1401 = 2e

m1500 = 0f LB_68013_TX cypress m1501 = 2f IG810 LB2_68013_TX

m1600 = 10 LB_68013_RX ground m1601 = 30 IG810 LB2_68013_RX ground

m1700 = 11 vps camera m1701 = 31 vps sonar

m1800 = 12

m1900 = 13 FPGA air

m2000 = 14 FPGA ground m2001 = 34 FPGA ground m2002 = 54 FPGA ground m2003 = 74 FPGA ground LB2

m2500 = 19 IMU m2501 = 39 IMU

m2600 = 1a m2601 = 3a m2602 = 5a m2603 = 7a m2604 = 9a m2605 = ba m2606 = da RTK main app m2607 = fa RTK bootloader

m2700 = 1b

m2900 = 1d PMU APP m2901 = 3d PMU LDR

[GlovePuppet]

Nice, that's a very a useful list :) IIRC the FC, at least, masks out the top nybble so we seem to agree.

When work finally eases up I want to try talking to the FC via WIFI. We can probably turn of the NFZ without patching FW

[coptersafe]

@GlovePuppet do you have email? i whant share you some interesting info , but I do not want DJI to remove this cheat. Be sure that their security service read all post from this topics

[aka1ceman]

dont leave me out copter :( I have an email.

LOL

[notsolowki]

Yes quite a few of us have emails lol

[GlovePuppet]

I took a look at the FC<->Battery today. The physical link is UART, 115200 8N1 as usual. The packets exchanged have a different format, a 4 byte header and a 1 byte checksum at the end of the packet

0: Packet start (0xAB) 1-2: 0x0400 | (Length & 0x3FF) //16 bits, packed Little Endian 3: Unknown, maybe Command ID? 4 - (Length-2): Payload Length-1: Checksum

The attached Python code can calculate the 8 bit checksum for battery packets

batt_crc.zip

I have also attached a pcap file you can load into Wireshark and view the log of a session between the FC and an almost flat battery (no dissector for this atm).

low_battery.zip

Edit: A log from a fully charged battery:

full_battery.zip

Has anyone worked out the 4th byte and payload data format?

[GlovePuppet]

Starting to answer my own question, 4th byte is the Cmd ID

Cmd 0x34: - Unknown, no responses seen?

Cmd: ab 10 04 34 03 01 01 06 03 07 01 03 06 03 02 52

1163713632 is a substring of the battery pack's barcode (see below)

Cmd 0x38 - Fetch battery barcode

Cmd: ab, 0e, 04, 38, 00, 00, 00, 00, 00, 00, 00, 00, 00, a3

Rsp: ab, 13, 04, 38, 00, 06, 01, 07, 01, 01, 06, 03, 07, 01, 03, 06, 03, 02, 54

Barcode of this pack is: 6171163713632

[GlovePuppet]

Cmd 0x21 - Fetch battery info

Cmd: ab 0e 04 21 00 00 00 00 00 00 00 00 00 10

Rsp: ab 2d 04 21 00 [00] 68 11 [02] 06 00 // Edit: Maybe number of charges? This pack is very new [04] 80 11 // Nominal capacity 4480mAh [06] 60 3b // Nominal voltage 15200mV [08] 31 00 [0A] 2a 49 // Mfr Date 10/9/2016 (dd/mm/yyyy) [0C] 73 01 // Serial Number [0E] 41 54 4c 20 20 4e 56 54 20 20 44 4a 30 30 35 05 00 04 02 00 00 08 01 63 //Battery Name [25] 00 c5

Date calculation Year = (0x492A >> 9) + 1980 Month = (0x492A >> 5) & 0xF Day = 0x492A & 0x1F

Cmd 0x22 - Fetch battery status

Cmd: ab 0e 04 22 00 00 00 00 00 00 00 00 00 a8

Rsp: ab 25 04 22 00 [00] b4 0b [02] 60 43 [04] 9e ff ff ff [08] a9 ff ff ff [0C] 62 00 [0E] d4 10 d4 10 dc 10 dc 10 00 00 00 80 // Cell voltages [1A] 00 // Power off flag (00 - battery On, FF - battery powering off) [1B] 00 00 00 00 cc

Full pack: 0x10D4 = 4308mV Empty pack: 0x0EA1 = 3745 mV

More work needed here, I'm guessing things like current consumption & last recharge in mAh

[GlovePuppet]

Cmd 0x23 - No idea, some form of DRM? No longer used?

Cmd: ab 06 04 23 00 02

Rsp: ab 1a 04 23 00 61 df 37 d5 a3 67 e5 c1 5b 01 8b dd cf 8d c9 89 2f f1 85 65 75

No idea what this does, can't be 100% sure I got the direction right either. Response payload is 20 bytes and looks very likely to be SHA1. In the FC FW the response handler is null_sub so we can probably ignore this

Cmd 0x24: - See 0x23

Cmd: ab 0e 04 24 00 00 00 00 00 00 00 00 00 df

Rsp: ab 1a 04 24 00 86 00 71 e6 9c ae 91 92 5e 16 72 ef 0f 1c 03 da a8 89 d9 d4 47

The FC performs a memcmp and if successful manipulates some flags

Cmd 0x25: - No idea

Cmd ab 0e 04 25 00 00 00 00 00 00 00 00 00 b7

Rsp ab 82 04 25 00 00 00 00 20 00 00 00 30 00 00 00 30 00 00 00 30 00 00 00 30 00 00 00 30 00 00 02 00 00 00 00 30 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05

In the FC FW the response handler is null_sub so we can probably ignore this

[mefistotelis]

Could you point me to the FC firmware version and function address where the responses from battery are handled?

[GlovePuppet]

FW V01.07.0060

sub_807F858 - reassemble then process 'AB' packets

Fn ptr table

.data:080D376C DCD 0x21 .data:080D3770 DCD 0x807F5EB .data:080D3774 DCD 0x22 .data:080D3778 DCD 0x807F63F .data:080D377C DCD 0x23 .data:080D3780 DCD 0x807F663 .data:080D3784 DCD 0x24 .data:080D3788 DCD 0x807F665 .data:080D378C DCD 0x25 .data:080D3790 DCD 0x807F699 .data:080D3794 DCD 0x38 .data:080D3798 DCD 0x807F60F

Can you point me at a plaintext battery FW (assuming one exists)?

[mefistotelis]

There are two modules for batteries, like the battery MPU changed at some point. What I know is explained on the wiki about battery board. The modules are not encrypted.

I haven't tried disassembling the battery FW, so I don't know the proper parameters for bin2elf.

[GlovePuppet]

Datasheet for the MCU (MSP430G2755) on my Battery PCB DJI0617 Rev 04 (23/10/2014)

http://www.ti.com/lit/ds/symlink/msp430g2755.pdf

And an application note for the BQ30Z55 (the other major chip on the battery PCB)

http://www.ti.com/lit/ug/sluu516/sluu516.pdf

See figure8. I guess the DJI battery is probably very similar

[pawelsky]

I'm adding some missing pieces for the battery messages from my earlier investigations

Cmd 0x21 - Fetch battery info

Cmd: ab 0e 04 21 00 00 00 00 00 00 00 00 00 10

Rsp: ab 2d 04 21 00 [00] 68 11 // Total capacity (UINT16, , mAh) [02] 06 00 // Discharge count (UINT16, ) [04] 80 11 // Nominal capacity 4480mAh [06] 60 3b // Nominal voltage 15200mV [08] 31 00 // Likely battery specification (UINT16, see 5.1.25 in sbdat110 document linked below) [0A] 2a 49 // Mfr Date 10/9/2016 (dd/mm/yyyy) [0C] 73 01 // Serial Number [0E] 41 54 4c 20 20 4e 56 54 20 20 44 4a 30 30 35 //Battery Name [1D] 05 00 04 02 [21] 00 00 08 01 // Firmware version (1.8.0.0) [25] 63 00 // Battery life (UINT16, %) c5

Cmd 0x22 - Fetch battery status

Cmd: ab 0e 04 22 00 00 00 00 00 00 00 00 00 a8

Rsp: ab 25 04 22 00 [00] b4 0b *// Battery temperature (UINT16, Kelvins 10) [02] 60 43 // Total voltage (UINT16, mV) [04] 9e ff ff ff // Current (INT32, mA, negative when discharging, positive when charging) [08] a9 ff ff ff // Average current (INT32, mA, negative when discharging, positive when charging) [0C] 62 00 // Percentage of charge (UINT16, %) [0E] d4 10 // Cell 1 voltage (UINT16, mV) [10] d4 10 // Cell 2 voltage (UINT16, mV) [12] dc 10 // Cell 3 voltage (UINT16, mV) [14] dc 10 // Cell 4 voltage (UINT16, mV)** [16] 00 00 00 80 [1A] 00 // Power off flag (00 - battery On, FF - battery powering off) [1B] 00 00 00 00 cc

Cmd 0x31 - Request battery settings

Cmd: AB 0E 04 31 00 00 00 00 00 00 00 00 00 8

Rsp: AB 0A 04 31 00 [00] ?? // Time to discharge (UINT8, days) [01] ?? [02] ?? [03] ?? CS

Cmd 0x25 - Get list of battery warnings

Cmd: ab 0e 04 25 00 00 00 00 00 00 00 00 00 b7 or Cmd: AB 05 04 25 1A

Rsp: ab 82 04 25 00 [00] 00 00 00 20 // Battery warnings flags record 1 (UINT8 x 4) ... [78] 00 00 00 00 // Battery warnings flags record 31 (UINT8 x 4) 05

This document is pretty usefull when decoding the battery data http://sbs-forum.org/specs/sbdat110.pdf

[GlovePuppet]

Awesome, seems to be complete except for 0x23 & 0x24 which we don't really care about

MSP430 code loads at 0x8000 and RAM starts at 0x1100 but now @pawelsky has filled in all the blanks I don't think I care. Thanks @pawelsky !

Edit: One thing to note, in the FC FW there is a hardcoded 12 byte memcpy to read the cell voltages. If we ever saw a 5S pack ....

[0E] d4 10 // Cell 1 voltage (UINT16, mV) [10] d4 10 // Cell 2 voltage (UINT16, mV) [12] dc 10 // Cell 3 voltage (UINT16, mV) [14] dc 10 // Cell 4 voltage (UINT16, mV) [16] 00 00 // Cell 5 voltage (UINT16, mV) [18] 00 80 // Cell 6 voltage (UINT16, mV) OR end of list marker?

[notsolowki]

How do you guys get this data from the chip? Are you using witeshark?

[GlovePuppet]

I have a magic script that reads from two UARTS and writes the result to a file (a pcap) or a FIFO that Wireshark can read from. There are 2 pcap files in my earlier post that you can d/l and load into Wireshark then you can see the raw captured data

[GlovePuppet]

.... and here's the magic script. It is derived from work by Matthijs Kooijman

serial-pcap.py.zip

The script 'packetizes' the data it sees on either of the two UARTS, checks the CRC and if the packet is valid pushes it into the FIFO

I invoke it thus:

./serial-pcap.py -b 115200 -F /tmp/wsf /dev/ttyUSB0 /dev/ttyUSB1

This creates a FIFO at /tmp/wsf that Wireshark can read (there is an option to write to a file instead but I never tested it). It might work on Windoze but, again, I haven't tested it

Start Wireshark:

wireshark -i /tmp/wsf

You will need Python3 and python3-serial

[GlovePuppet]

http://www.ti.com/lit/ug/sluua79/sluua79.pdf

Chapter 9 ;)

[notsolowki]

Thats awsome, thanks for sharing that. Tonight i will be trying to set that up just to do it.

[mefistotelis]

Hey @GlovePuppet, I added your tools to the repository. You may share further updates as patches.

And about the update - note that packet[3] is known:

  // outpckt[3] is the checksum of 3 preceding bytes
  outpckt->field_3 = compute_buf_checksum_xor1(0x77, outpckt, 3);
[...]

uint32_t compute_buf_checksum_xor1(uint32_t seed, uint8_t *buf, uint32_t len)
{
  uint32_t chksum;
  chksum = seed;
  while (len > 0)
  {
    chksum = arr_2A103[(*buf) ^ chksum];
    len--;
    buf++;
  }
  return chksum;
}

[...]
arr_2A103      DCB    0,0x5E,0xBC,0xE2,0x61,0x3F,0xDD,0x83,0xC2,0x9C,0x7E,0x20,0xA3,0xFD,0x1F,0x41
                DCB 0x9D,0xC3,0x21,0x7F,0xFC,0xA2,0x40,0x1E,0x5F,   1,0xE3,0xBD,0x3E,0x60,0x82,0xDC
                DCB 0x23,0x7D,0x9F,0xC1,0x42,0x1C,0xFE,0xA0,0xE1,0xBF,0x5D,   3,0x80,0xDE,0x3C,0x62
                DCB 0xBE,0xE0,   2,0x5C,0xDF,0x81,0x63,0x3D,0x7C,0x22,0xC0,0x9E,0x1D,0x43,0xA1,0xFF
                DCB 0x46,0x18,0xFA,0xA4,0x27,0x79,0x9B,0xC5,0x84,0xDA,0x38,0x66,0xE5,0xBB,0x59,   7
                DCB 0xDB,0x85,0x67,0x39,0xBA,0xE4,   6,0x58,0x19,0x47,0xA5,0xFB,0x78,0x26,0xC4,0x9A
                DCB 0x65,0x3B,0xD9,0x87,   4,0x5A,0xB8,0xE6,0xA7,0xF9,0x1B,0x45,0xC6,0x98,0x7A,0x24
                DCB 0xF8,0xA6,0x44,0x1A,0x99,0xC7,0x25,0x7B,0x3A,0x64,0x86,0xD8,0x5B,   5,0xE7,0xB9
                DCB 0x8C,0xD2,0x30,0x6E,0xED,0xB3,0x51, 0xF,0x4E,0x10,0xF2,0xAC,0x2F,0x71,0x93,0xCD
                DCB 0x11,0x4F,0xAD,0xF3,0x70,0x2E,0xCC,0x92,0xD3,0x8D,0x6F,0x31,0xB2,0xEC, 0xE,0x50
                DCB 0xAF,0xF1,0x13,0x4D,0xCE,0x90,0x72,0x2C,0x6D,0x33,0xD1,0x8F, 0xC,0x52,0xB0,0xEE
                DCB 0x32,0x6C,0x8E,0xD0,0x53, 0xD,0xEF,0xB1,0xF0,0xAE,0x4C,0x12,0x91,0xCF,0x2D,0x73
                DCB 0xCA,0x94,0x76,0x28,0xAB,0xF5,0x17,0x49,   8,0x56,0xB4,0xEA,0x69,0x37,0xD5,0x8B
                DCB 0x57,   9,0xEB,0xB5,0x36,0x68,0x8A,0xD4,0x95,0xCB,0x29,0x77,0xF4,0xAA,0x48,0x16
                DCB 0xE9,0xB7,0x55, 0xB,0x88,0xD6,0x34,0x6A,0x2B,0x75,0x97,0xC9,0x4A,0x14,0xF6,0xA8
                DCB 0x74,0x2A,0xC8,0x96,0x15,0x4B,0xA9,0xF7,0xB6,0xE8, 0xA,0x54,0xD7,0x89,0x6B,0x35

EDIT: added array.

Also, are you planning to make sub-dissectors for the payload?

[GlovePuppet]

Here's an updated capture script, it now checks the packet header CRC. BTW: I couldn't find comm_serial2pcap.py in your repo

comm_serial2pcap.py.zip

I could develop the dissector further if people are interested ...

[mefistotelis]

I couldn't find comm_serial2pcap.py in your repo

It's here: https://github.com/mefistotelis/phantom-firmware-tools/blob/master/comm_serial2pcap.py

I could develop the dissector further if people are interested ...

My idea is to make the LUA scripts into a form of protocol documentation. To make this happen, the script should contain everything we know.

[GlovePuppet]

I ran out of time today but I did update the dissector to add partial decoding of battery packets

dji-p3.lua.zip

Edit: By partial I mean the Battery Barcode, Type & Status responses are decoded.

BTW, You can right click on a column in WS and select what it will display (i.e. dji_p3.batt_cmd)

[mefistotelis]

In battery dumps, where is the info about direction (to/from battery)?

[GlovePuppet]

It doesn't exist in the packet and WS can't tell from the pcap. The best I could do was look at the length of the packet and decide if it is cmd or response.

[mefistotelis]

I see, there is no field to distinguish it in one pcap file.

Unless we make two pcap files instead, and use File -> Merge option to load them together. Or it is possible to use pcapng format (with python-pcapng library - writing pcap-ng files is “planned” there, so bad idea).

EDIT - noticed no write support in python-pcapng EDIT2 - I think the easiest and best solution would be to just wrap each packet with another layer which determines direction. Having no direction info in battery communication does make things harder.

[GlovePuppet]

How will you tell the script which UART is "to FC" and which is "from FC"? Additional cmd line stuff I guess

IMHO it's not worth the hassle, with such a small set of commands on point-point connection like this you can figure it out quite easily.

Don't let me stop you improving the script tho ;)

[Mavic129]

@GlovePuppet i tested your code from first post on Mavic i can confirm Mavic uses the same seed " 0x3692 " great work man

[mefistotelis]

How will you tell the script which UART is "to FC" and which is "from FC"? Additional cmd line stuff I guess

It doesn't matter which is which, as long as they are distinguished. I'm thinking about just adding a wrapper packet with some magic value and interface index, ie 0 for first and 1 for second.

But currently I'm thinking about some kind of basic u-blox GPS simulator, so will probably not touch comm_serial2pcap.py for some time.

[mefistotelis]

Some interesting data to check:

• install "DJI Assistant 2"
• get "app.asar" file from its install dir to a linux env
• prepare linux env for the node scripts

  sudo apt install npm nodejs-legacy

• install and use asar

  npm install asar
  ./node_modules/asar/bin/asar.js e app.asar ./app.asar.extr

• install and use js standard formatter

  npm install standard --save-dev
  ./node_modules/standard/bin/cmd.js --fix "./app.asar.extr/**/*.js"

Now you have a bunch of interesting files which can help in understanding the serial communication.

[GlovePuppet]

Can you confirm that last command? It just hangs here ....

[mefistotelis]

It is quite slow. Might take an hour or so. nodejs is not a speed demon.

Looks like with some translation work, we can get proper names for source/destination and other parameters in packets:

  device_opts: [
  {text: '相机', value: 1},
  {text: '移动终端（运行App）', value: 2},
  {text: '飞控', value: 3},
  {text: '云台', value: 4},
  {text: '中心板', value: 5},
  {text: '遥控器', value: 6},
  {text: 'Wi-Fi模块（天空端）', value: 7},
  {text: 'DM368（天空端）', value: 8},
  {text: '高清图传（天空端1765）', value: 9},
  {text: 'PC', value: 10},
  {text: '智能电池', value: 11},
  {text: '电调', value: 12},
  {text: 'DM368（地面端）', value: 13},
  {text: '高清图传（地面端1765）', value: 14},
  {text: '串并转换（天空端68013）', value: 15},
  {text: '串并转换（地面端68013）', value: 16},
  {text: '单目', value: 17},
  {text: '双目', value: 18},
  {text: '高清图传（天空端FPGA）', value: 19},
  {text: '高清图传（地面端FPGA）', value: 20},
  {text: '模拟器', value: 21},
  {text: '基站', value: 22},
  {text: '机载计算平台', value: 23},
  {text: '遥控器电池', value: 24},
  {text: 'IMU', value: 25},
  {text: 'GPS', value: 26},
  {text: 'Wi-Fi模块（地面端）', value: 27},
  {text: '农用机信号转换板', value: 28}],

[GlovePuppet]

You're not joking, it's still going!

[GlovePuppet]

Erm, so, where's "the goods"?

[mefistotelis]

so, where's "the goods"?

The lists which contain names for numeric values - like the one I pasted. There are several more such lists in hil.js.

[GlovePuppet]

1 - Camera 2 - App 3 - Flight Controller 4 - Gimbal 5 - Center Plate 6 - Remote Control 7 - WiFi Module (Sky Side) 8 - DM368 (Sky Side) 9 - High-definition map (Sky Side 1765) 10 - PC 11 - Smart Battery 12 - ESC 13 - DM368 (Ground Side) 14 - High-definition map (Ground Side 1765) 15 - Serial-to-parallel conversion (Sky Side 68013) 16 - Serial-to-parallel conversion (Ground Side 68013) 17 - Monocular 18 - Binocular 19 - HD image transmission (Sky-Side FPGA) 20 - HD image transmission (Ground-Side FPGA) 21 - Simulator 22 - Base Station 23 - Airborne computing platform 24 - Remote control battery 25 - IMU 26 - GPS 27 - Wi-Fi module (Ground Side) 28 - Agricultural machine signal conversion board

EDIT: Updated with feedback 6/20