Data Sheet

 If an ACK packet is not received in 10 seconds, it resends the Data packet.
 If an ACK is received, it saves all the settings back to flash, turns off the HM-1x
module, sets all its IO to low to save power, and goes to sleep for around 255
seconds.
 Upon waking from sleep, it repowers the HM-1x, restarts it’s radio, and begins
waiting for packets again.
 At any point in time, a packet from the app or a packet or command from the USB
can be received. It is processed immediately, and the program returns to where it
last was.
Basic flow of communications
From start up after code is loaded on the wixel, the xBridge2 code will begin sending Beacon
Packets at 5 second intervals on UART1 and USB (if it is connected). To break this cycle, a
TXID packet must be received on either UART1 or USB (if connected).
Once the wixel has received a TXID Packet and saved the info to flash, it will begin scanning
for Dexcom packets from that transmitter.
When the wixel receives a Dexcom data packet, it will send a Data Packet on UART1 or
USB (if connected).
The receiving app must process the packet, and if the TXID sent in the packet is valid, it may
send back a data ACK packet, which will immediately send the wixel to sleep for a period of
time until before the next packet is due.
If the TXID in the data packet is incorrect, the app must send back a TXID packet to the
wixel to set it to the correct ID.
The wixel will send a Beacon Packet, if it has not received a Data Packet within 5 minutes
and 30 seconds of waking. The app must process this packet, and ignore the beacon
packet if all is good, or send a TXID packet if the beacon contains the wrong ID. This
ensures that when a patient changes their transmitter ID in the app, the wixel can be
updated as soon as possible after it wakes, and before it receives a packet from the new
transmitter. If no beacon was sent when the wixel woke, the wixel would simply loop
indefinitely until it received a packet from a transmitter that was no longer functioning.
The reason that we have had to send beacons this way is for two reasons. First, the BLE
implementation in Android does NOT cleanly detect a closed connection, and retry
connection at a fast enough rate to guarantee that it will connect immediately the HM-1x
module is powered on by the Wixel. Otherwise, we would send the beacon as soon as the
Wixel wakes and powers the HM-10 on. Any delay between wake and beginning packet
capture could prevent a dexcom packet being missed.
Secondly, we do not want to interrupt the packet capture, so it is best to set a limit on packet
capture, stop and send the beacon, and then start packet capture again. So, allowing
packet capture to run a little longer than the anticipated 5 minutes means we are less likely
to miss a packet capture.