v5_field_control/connection.txt

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 - ?