Data Sheet

ManualsBrandsRobotShop ManualsData Communication and Human Input DevicesxDRIP Bridge Module

XBridge2

XBridge2 is firmware code for a Pololu Wixel, and additional circuitry, that can make the

wixel act as a bridge between a Dexcom G4 Transmitter and a smart phone using Bluetooth

4.0 (BLE). It requires that the Wixel be connected to a HM-10 BLE module, using the design

originally put together by Stephen Black for his XDrip system as a minimum. There is a

minor hardware modification required in order to receive the bridge battery voltage for

monitoring in the app, and a modification to the wiring that allows the HM-1x to be powered

down with the wixel low power mode, and powered up when the wixel wakes. Please see

the Circuit diagrams below.

NOTE: This wixel app can be used with a classic xDrip-wixel wiring, but you will not have

the full battery saving features the code can provide. The xBridge2 code will automatically

detect if you are using a classic xDrip-wixel circuit, and automatically detect your HM-1x

module baud rate.

Acknowledgements

The original code, engineering and decoding of the Dexcom data packet was done by Adrien

de Croy, whithout whom this project would not be possible.

The inspiration to continue came from Lorelei Lane, Jason Calabrese, and others of the

Nightscout community and foundation.

The original XDrip circuit upon which this work is based was engineered by Stephen Black,

who also created the XDrip app.

The battery monitoring circuit was designed by Chris Botelho.

The method of powering down and powering up the HM-10 module was engineered by

Gabor Szakacs.

Also, I wish to acknowledge the work of “lumos” and “slasi” of the Pololu Wixel forum for their

work in Sleeping the wixel and radio correctly. I have made copious use of “slasi”’s

radio_mac library, and used some of the code in “lumos”’ sleep library in the xBridge wixel

code.

Overview

As the name suggests, this device acts purely as a bridge between the Dexcom G4

Transmitter and a Bluetooth Low Energy capable device, such as a mobile phone or tablet.

It retransmits the data obtained from a Dexcom G4 transmitter packet. It DOES NOT

ALTER OR RECALCULATE that data. It performs no math or translation of the raw data in

the packet to an estimated Blood Glucose value.

It should be noted that only three pieces of data are retransmitted from the Dexcom G4.

These are the two 32bit values representing blood glucose data, and an 8 bit value

representing the battery condition in the G4 transmitter.

It adds information about the XBridge battery, as a percentage of remaining capacity, and

the Dexcom G4 Transmitter ID that it is filtering on.

Summary of content (24 pages)

PAGE 1
XBridge2 XBridge2 is firmware code for a Pololu Wixel, and additional circuitry, that can make the wixel act as a bridge between a Dexcom G4 Transmitter and a smart phone using Bluetooth 4.0 (BLE). It requires that the Wixel be connected to a HM-10 BLE module, using the design originally put together by Stephen Black for his XDrip system as a minimum.
PAGE 2
This device and software, and any companion software developed for use with it, MUST NOT be used for making therapeutic decisions about diabetes management. Always use your standard Blood Glucose devices and management strategies. This is for informational and experimental use only. The original wixel code for XDrip was based on work by Adrien de Croy, Lorelai Lane, and others, but it has some limitations.
PAGE 3
ID. It also allows for packet capture by a PC for analysis of performance. IMPLEMENTED (v2.1) Version History 1 Experimental and Proof of concept. Used to refine the Packet Capture code, develop flash storage of the Transmitter ID, and general operation of the wixel as a bridge device. Text only protocol and commands. Consumer ready version. All packets are retransmitted as binary packets. Implemented:  Wixel Power Mode 2 sleeping  Wixel not sleeping on USB connected to PC.
PAGE 4
divider on P0_0. VIN of 3.2V (equivalent to 865mV input on P0_0) is 0%, as this is the lowest operating voltage of the battery. VIN of 4V (equivalent to 1081mV input on P0_0) is 100%, as this is the maximum voltage delivered the battery stably returns to once power is removed from the battery. 12:15 Dexcom TxID 32 bit unsigned integer Encoded Dexcom Transmitter ID that the bridge is filtering on. 16 XBridge Protocol Level 8 bit unsigned integer XBridge protocol level.
PAGE 5
Byte 0 1 2:5 Value 0x06 0x01 TxID Data Type 8 bit unsigned integer 8 bit unsigned integer 32 bit unsigned integer Description Number of bytes in the packet (6). Code for Data Packet Encoded 32 bit integer representing the Dexcom G4 Transmitter ID that the bridge is filtering packets on. Note: as this packet is sent from the app to the phone, it does not include a XBridge protocol level byte.
PAGE 6
character string is equivalent to the characters printed on the transmitter, and entered into a receiver. Parameters: addr a 5 character string. eg "63GEA" Returns: uint32a value equivalent to the incodeded Dexcom Transmitter address. Uses: getSrcValue(char) This function returns a value equivalent to the character for encoding.
PAGE 7
void dexcom_src_to_ascii(uint32 src, char addr[6]) { //each src value is 5 bits long, and is converted in this way. addr[0] = SrcNameTable[(src >> 20) & 0x1F]; //the last character is the src, shifted right 20 places, ANDED with 0x1F addr[1] = SrcNameTable[(src >> 15) & 0x1F]; //etc addr[2] = SrcNameTable[(src >> 10) & 0x1F]; //etc addr[3] = SrcNameTable[(src >> 5) & 0x1F]; //etc addr[4] = SrcNameTable[(src >> 0) & 0x1F]; //etc addr[5] = 0; //end the string with a null character.
PAGE 8
    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.
PAGE 9
Parts List The minimum parts required to make a working xBridge circuit are: 1x Pololu Wixel 1x Adafruit Micro Lipo Charger with Micro USB Jack (PRODUCT ID: 1904) or equivalent. 1x 10k 1% 1/2W metal film resistor. 1x 27k 1% 1/2W metal film resistor 1x HM-1X (HM-10 or HM-11) based BLE module. 1x 3.7V Lithium Polymer (LiPo) battery. The capacity is your choice, but recommend 1200mAh for 5 days or more continuous operation.
PAGE 10
Resistors are 1% 1/2W metal film 10k GND GND VIN P1_0 P0_0 27k P1_6 P1_7 TX TX RX RX STATUS BRK Note: be VERY careful not to overhead the solder pads on the HM-10 module. They are rather fragile. Also ensure that your wires do not place undue pressure on these. HM-10 on support board, with Wixel and Adafruit charger board.
PAGE 11
Resistors are 1% 1/2W metal film 10k GND GND VIN P1_0 P0_0 27k P1_6 P1_7 TX TX RX RX BRK UART_TX STATUS UART_RX GND VCC Chris Bothello’s HM-11 board (Thanks to Noah Terracalls)
PAGE 12
Options for Charging Note that it is DANGEROUS to allow a LiPo battery to drop below it’s minimum voltage for any length of time. They do include cut out circuitry to prevent this, but they still continue to discharge over time. Always keep your LiPo charged. The most obvious way to charge the bridge battery is to connect the Adafruit charger board to a micro USB cable and plug it in to a USB port. Once the Red LED goes out and the Green one comes on, the battery is charged.
PAGE 13
Prerequisites Firstly, you will need to either obtain the compiled usb_serial.wxl file (can be found at https://github.com/jstevensog/wixel-sdk/blob/master/apps/usb_serial/usb_serial.wxl), or compile it using the wixel-sdk located at https://github.com/jstevensog/wixel-sdk. Connect your wixel to a computer via USB, and use the Wixel Configuration Utility to load this onto your wixel. Secondly, you will need a terminal program. There are two options here.
PAGE 14
8. Open the HMSoft.exe file. It will open a window like this. 9. Click on the button to the right of the “Image File:” text box to navigate to the image file. Below is an example. 10. Enter the COM port number. For example, my wixel in this case is on COM 10, so my window will look like this. 11. Click the “Load Image” button. The progress bar will show the progress. The process takes a few minutes to complete. Once it has finished, the HM-1x module will be updated to the required level.
PAGE 15
12. To verify the Firmware level of the module, open your terminal program once again. Send the command “AT+VERR?”. You will see a response like “OK:HMSoft v534” 13. That is it. You can now load the xBridge2.wxl file using the Wixel Configuration Utility, and the bridge is ready for use. Modifications to use xBridge app with the xDrip-wixel circuit. The xBridge2 firmware now automatically detects if the circuit is wired as a “classic” xDrip wixel or an xBridge when it is powered on.
PAGE 16
Click the Write to Wixel button, and the app will be loaded onto the wixel. Wait for at least 30 seconds, until you see the Green LED on the wixel, and at least one blink of the Red LED. Or you can use a serial terminal to watch the boot process. You should then be able to turn on your phone’s Bluetooth and scan for your xBridge using xDrip. You are looking for a name like “xBridgeXXYY”, where XX and YY are alpha numeric characters.
PAGE 17
There will also be a setting appear that allows you to Display (or Not Display) the bridge battery in xDrip. The default is to display this. You should now be able to start your sensor, allow xDrip to capture at least two packets, and do a double calibration to start using the system. Serial Terminal Commands xBridge2 supports three commands you can issue on a serial terminal connected to the wixel via USB. Note: The wixel MUST be awake for you to issue these commands.
PAGE 18
Problems with updating the HM-1x firmware These modules are fairly robust and can put up with a lot. If you for some reason happen to power down the module during firmware update, after you had entered the AT+SBLUP command, do not be alarmed. It won’t have completed the update process. Simply repower he module, and send the firmware file again. It will complete the process. The most common problem with this, is establishing the connection with the module using usb_serial app on the wixel.
PAGE 19
3. If instead you see only a device called HMSoft, the wixel has not been able to correctly communicate with the HM-10 module. Check your wiring. And also check that you have loaded the xBridge2.wxl file on the wixel. 4. If you establish a BLE connection to the bridge, the green LED on the HM-1x module will go on, and the YELLOW LED on the Wixel will go on shortly after. This shows that the wixel is aware of the connection. 5.
PAGE 20
Example Output on USB Serial Port The screen shot above shows a boot up after the firmware is loaded. Note, that this wixel was already joined to an xDrip app. As you can see, when it first started up, all the xBridge_flags were set to 1 (ffff). After the HM-1x was set and configured, the flags are now set to fffe. Also, the battery_minimum and battery_maximum settings are not yet set (showing 65535). After it has configured the HM-1x it sends a beacon packet until it gets a TXID packet in response.
PAGE 21
In this next screenshot, you can see it has got a packet from the Dexcom transmitter. The wixel waits until it has a BLE connection to the phone, then it sends a beacon, then the DATA packet, and waits for an ACK packet. Once it has this, it saves the settings to flash (mo message above) and then goes to sleep. It is relatively common for the current xDrip app to take a while to establish a connection. Hence you can see all the “packet waiting” messages here.
PAGE 22
Here you can see that the wixel has woken up, and turned on the HM-1x (ble on). It has then received a command (me pressing the S key), and is processing it. You can see the battery minimum and maximum are at the default values, and battery capacity has been calculated at 70%. Functional Testing The following tests are carried out on every iteration of the XBridge2 code to ensure it is operating as expected.
PAGE 23
a. b. c. d. e. BLE GATT connection series of messages. Messages indicating Receipt of a Beacon Packet. Message saying the Beacon Packet is Wrong. Message “sending message”. Receipt of another Beacon Packet, which is the acknowledgement to the previous one. 4. The wixel will now listen and wait for a Data Packet. There is no ADB log entry showing this listening phase, but there will be log entries when a Data Packet is found. Test 2 – Reception of Dexcom Data, and initiating sleep. 1.
PAGE 24
4. If you have issues with your phone/Android version and Bluetooth, with the connection and disconnection that xBridge2 uses to save battery, you can try turning BLE sleeping off. Use the “B” command in a serial terminal session to toggle BLE sleeping on or off. Turning BLE sleeping off will cause higher battery drain. However, the connection to the phone will remain stable as long as the bridge does not go out of range of the phone.