When disconnected, controller sends following message every 20ms: 0A 4B 00 00 09 00 00 40 1A D2 1C 00 61 01 41 46 When connected, the field control app responds with: 03 01 64 00 00 00 00 BA 00 7C 1C 88 00 00 8E 67 Next the controller sends: 13 20 00 00 1A D2 1C 00 00 00 00 00 00 00 96 F0 The field control app responds with: 02 13 01 00 00 00 00 00 00 00 01 00 00 00 F3 78 These four packets are sent quickly(times from end of sending packet to start of next packet [55us, 122us, 66us]), the next message is sent after 100ms 11 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 B2 AA 0xB2AA = CRC-16/CCITT-FALSE of 11 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, so likely that's what the last two bytes are Going back, 0xF378 is the CRC-16/CCITT-FALSE of 02 13 01 00 00 00 00 00 00 00 01 00 00 00, so it looks like every message is ended with the CRC-16/CCITT-FALSE of the preceeding bytes Response: 04 00 14 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 F5 6B Next: 02 04 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 CB 80 Response: 02 02 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 D8 B1 The next burst of 6 packets starts with: A7 00 E1 11 00 00 C9 00 00 53 00 00 00 00 00 01 00 00 32 31 30 5A 00 00 00 00 00 00 02 00 29 93 Response: 54 09 00 70 C9 36 B8 50 58 39 00 EE FE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3C 9C Next: 02 54 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 FA 50 Response: 02 02 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 D8 B1 Next: A3 17 00 00 AA 5E 58 13 39 0C 00 04 00 06 00 02 40 01 40 00 40 00 40 30 30 FC 09 00 00 00 C9 DE Response(after 3x the normal time): 02 A3 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4B F7 Next burst of 4 packets starts with: A7 00 E1 11 00 00 C9 00 00 56 00 00 00 00 00 01 00 00 32 31 30 5A 00 00 00 00 00 00 02 00 9B DE Response: 54 09 00 71 C9 36 B8 50 56 20 00 4C 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 29 FA Next: 02 54 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 FA 50 Response: 02 02 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 D8 B1 Then begins the pattern of the following send->response pattern every 20ms: A7 00 E1 11 00 00 C9 00 00 53 00 00 00 00 00 01 00 00 32 31 30 5A 00 00 00 00 00 00 02 00 29 93 Response: 53 c9 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 34 8f Since no additional control messages are sent, this polling response must contain the info of the current state + time While in "driver", the pattern changes to: A7 00 E1 31 00 00 E1 68 00 64 00 00 00 00 00 01 00 00 32 31 30 5A 00 00 00 00 00 00 02 00 BE 77 Response: 53 E1 00 00 12 99 01 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 While in "autonomous", the pattern changes to: A7 00 E1 31 00 00 D1 0E 00 64 00 00 00 00 00 01 00 00 32 31 30 5A 00 00 00 00 00 00 02 00 91 AD Repsonse: 53 D1 00 00 D9 37 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A7 DA Actually when auton starts this happens(without crc): 1) same pattern of A7 00 E1 11 00 00 C9 00 00 64 00 00 00 00 00 01 00 00 32 31 30 5A 00 00 00 00 00 00 02 00 2) fc responds with 02 A7 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3) controller sends exact same packet as before A7 00 E1 11 00 00 C9 00 00 64 00 00 00 00 00 01 00 00 32 31 30 5A 00 00 00 00 00 00 02 00 4) fc responds with 02 A7 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5) controller sends same packet A7 00 E1 11 00 00 C9 00 00 64 00 00 00 00 00 01 00 00 32 31 30 5A 00 00 00 00 00 00 02 00 6) fc responds with 53 D1 00 00 7F 3E 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7) controller sends A7 00 E1 31 00 00 D1 0F 00 64 00 00 00 00 00 01 00 00 32 31 30 5A 00 00 00 00 00 00 02 00 8) fc responds with 53 D1 00 00 7D 3E 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9) controller sends A7 00 E1 31 00 00 D1 0F 00 64 00 00 00 00 00 01 00 00 32 31 30 5A 00 00 00 00 00 00 02 00 10) fc responds with 53 D1 00 00 64 3E 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7-8(aka 9-10) continues to loop, looks like bytes 4 & 5 are the countdown Notes: 1) It looks like the first byte is the type of the packet, these are the seen types: - 0A sent while controller disconnected - 03 sent as response to 0A - 13 sent after 0A - 02 sent with second byte as the type received, as an ack - 11 first packet in connection sequence - 04 second packet in connection sequence - A7 part of second connection burst - 54 response to A7 during connect - A3 part of second connection burst - 53 response to A7 normally With these types, the connection sequence can be rewritten(with assumptions): 1 ) controller send "connect init" 0x0A 2 ) field control send "connect init response" 0x03 3 ) controller sends "begin setup" 0x13 4 ) field control sends "ack 0x13" 0x02 5 ) controller sensd "do the next thing" 0x11 6 ) field control responds "next thing done" 0x04 7 ) controller responds "ack 0x04" 0x02 8 ) fc responds "ack 0x02" 0x02 9 ) controller sends "poll state" 0xA7 10) fc responds "not normal response" 0x54 11) controller sends "ack 0x54" 0x02 12) fc responds "ack 0x02" 0x02 13) controller sends "some info probably" 0xA3 14) fc responds "ack 0xA3" 0x02 15) controller sends "poll state" 0xA7 16) fc responds "not normal response" 0x54 17) controller responds "ack 0x54" 0x02 18) fc responds "ack 0x02" 0x02 19) controller sends "poll state" 20) fc responds with "normal response" 0x53 The autonomous start sequence would be: 1) controller sends "poll state" 0xA7 2) fc sends "ack poll state" 0x02 3) controller sends "poll state" 4) fc sends "ack poll state" 0x02 5) controller sends "poll state" 0xA7 6) fc responds with "normal response" 0x53 7) controller sends "poll state" 0xA7 8) fc responds with "normal response" 0x53 Looking closer at the data, sometimes the FC responds to 0xA7 with "02A7"(aka ack 0xA7), and sometimes it responds with 0x53 In both cases the 0xA7 packet is the exact same. The 0x53 response seems to have 8 bits of data while the 0x02 has none 0x53 contains the timer and state 0x02 just acknowledges I can think of two possibilities: 1) 0x02 is sent when the CPU doesn't have the data/time to send the full update 2) 0x02 is sent periodically since the protocol requires that every x messages is acknowledges with 0x02 Matching up some info with the UI on the field controller: 1) 11E1 is the "system status" 2) C9 is the "field status" 3) controller battery is 100% 4) controller version is 75(0x4B) 5) controller radio version is 48(0x30) 6) radio version is 49(0x31) 7) vex os version is 1.2.0 The 0x0A packet: 0A 4B - controller version 00 00 09 00 00 40 1A D2 1C 00 61 01 41 46 The 0x03 packet: 03 01 64 00 00 00 00 BA 00 7C 1C 88 00 00 The 0x13 packet: 13 20 00 00 1A D2 1C 00 00 00 00 00 00 00 The 0x02 packet: 02 13 - type being acknowledged 01 - ? 00 00 00 00 00 00 00 01 - ? 00 00 00 The 0xA7 packet(disabled): A7 - type 00 E1 11 - system status 00 00 C9 - field status 00 00 53 - ? 00 00 00 00 00 01 - ? 00 00 32 31 30 5A - 210Z, team name 00 00 00 00 00 00 02 - ? probably part of vexos version 00 The 0xA7 packet(driver): A7 00 E1 31 - system status 00 00 E1 - field status 68 - ? 00 64 - ? always 64 unless disabled 00 00 00 00 00 01 - ? 00 00 32 31 30 5A - 210Z, team name 00 00 00 00 00 00 02 - ? probably part of vexos version 00 The 0x53 packet (auton) 53 D1 - control flags - 0b11010001 00 00 7D 3E 00 00 - 15997ms 03 - ? The 0x53 packet(driver) 53 E1 - control flags - 0b11100001 00 00 12 99 01 00 - 104722ms 03 - ? The 0x53 packet(disabled) 53 C9 - control flags - 0b11001001 00 00 00 00 00 00 - 0ms 03 - ?