In order to optimize and assess the time synchronization between the display device and the EmotiBit, a structured time synchronization protocol is employed in FW 0.2.0+ where TL/TU packets are only sent in response to a request by an EmotiBit. Specifically, time sync is initiated by the EmotiBit sending a Request Data RD packet with TL and TU in the payload. The EmotiBit then enters a state where all data sending and writing operations are suspended for a short period while it waits for the computer/phone to reply with either a TL or TU (or both) followed by an AK message with the packet number and RD in the payload. The processing of packets by the computer/phone should be optimized/prioritized to respond to these RD packets as fast as possible, targeting less than 10 milliseconds for a median round trip time.
The sequence is as follows:
- EmotiBit sends
RD packet. Payload = "TL, TU"
- EmotiBit enters an acute listening state waiting for
AK
- Computer/Phone receives
RD request for a TL/TU packet
- Computer/Phone replies with
TL or TU or both in separate packets.
- Computer/Phone replies with
AK. Payload = [packet number of RD message], RD"
- EmotiBit receives and logs received messages and resumes normal data/packet processing
This protocol enables the EmotiBit timestamp to be accurately assigned (with error bars) to a local/UTC timestamp at approximately 1/2 the round trip time between the sending of the RD packet and receipt of the TL/TU packet. Further assessment of the unidirectional packet transmission delay between the TL/TU packet and the AK packet allows even better pinpointing of the timestamp synchronization between the computer/phone and the EmotiBit.
In order to optimize and assess the time synchronization between the display device and the EmotiBit, a structured time synchronization protocol is employed in FW 0.2.0+ where
TL/TUpackets are only sent in response to a request by an EmotiBit. Specifically, time sync is initiated by the EmotiBit sending a Request DataRDpacket withTLandTUin the payload. The EmotiBit then enters a state where all data sending and writing operations are suspended for a short period while it waits for the computer/phone to reply with either aTLorTU(or both) followed by anAKmessage with the packet number andRDin the payload. The processing of packets by the computer/phone should be optimized/prioritized to respond to theseRDpackets as fast as possible, targeting less than 10 milliseconds for a median round trip time.The sequence is as follows:
RDpacket. Payload = "TL, TU"AKRDrequest for aTL/TUpacketTLorTUor both in separate packets.AK. Payload = [packet number of RD message], RD"This protocol enables the EmotiBit timestamp to be accurately assigned (with error bars) to a local/UTC timestamp at approximately 1/2 the round trip time between the sending of the
RDpacket and receipt of theTL/TUpacket. Further assessment of the unidirectional packet transmission delay between theTL/TUpacket and theAKpacket allows even better pinpointing of the timestamp synchronization between the computer/phone and the EmotiBit.