You can use the Nordic nRF51422 development board:
http://www.nordicsemi.com/eng/Products/ANT/nRF51422-Development-Kit
It also provides example software.
I also have a Beagle board, but for beginners, it unfortunately adds all the complexity of an OS (Linux), BSP, Bootloaders, setting up the tools, etc, etc.
I suggest an OS-less development with ARM Cortex or MSP430 CPU. You can get some affordable ones with www.olimex.com
Have fun.
$100 for a manufacturer's dev kit isn't too bad. I think for this case, the $20 radio module and an Arduino/MSP430 environment will be the cheapest starter road with a bigger support community.
I have a Bayer Contour Link that communicates to the Medtronics 722 pump. I took it apart and there is a daughter board attached to the main board that has the circuitry for communications. It has a 10 pin ribbon cable attached to it and I'm not sure if anyone has tried using this board to communicate with their pump. It anyone has a pin out for the cable it might be a start. Any thoughts would be appreciated.
Yes, the support community is VERY important. Go with it.
The Bayer Contour link uses the "ComLink2" protocol, identical to the carelink usb stick.
Well, looks like the Dexcom G4 is not ANT at all. They're developing a new ANT+ profile for the G5. I was hoping this used generic ANT or something but not so:
The Internal Photos and Test Report indicate that it uses a TI CC2510 in the transmitter, ~5MHz bandwidth and MSK modulation. Since the nrf24l01 is GFSK modulation only and smaller bandwidth, I don't think you'll be able to decode much from the Dexcom with it.
Possibly good news is that this cheap module might be more appropriate for getting data from it:
http://www.pololu.com/catalog/product/1336
Cheers,
David
Have you got anywhere with this? My son has just got a Dexcom G4 and I'm really keen to help develop something that allows us to monitor him through the night.
Can you post your complete SmartRF or Packet sniffer configuration?
I have a cc2510 Mini Kit, but I am having trouble finding the transmissions from the Dexcom. How did you go about changing the configuration? (i.e. Frequency, Bandwidth, Filter, etc.)
Hi bewest, I found your github repository on hacking the dexcom. I'm an engineer by training (radio / comms / networking) and software guy by trade. I also have some interesting contacts who do cutting edge miniature hardware.
There's an enormous hole in the market for Dexcom dealing with people who are managing others. The Dexcom is designed really for self-managing diabetics. Having to follow my 3 yo around all day with the dexcom receiver so he doesn't go out of range, or worrying while he's at kindergarten since I can't get a remote reading is a problem screaming out for a solution.
So my questions - are you still working on this? Did you get very far with the TI CC2510 kit? Or with converting the payload? I presume the payload has a timestamp in it?
How can I help?
Some info about Dexcom G4 messages. One message looks like this:
FF FF FF FF B0 CD 61 00 3F 03 1F 07 3E 32 7A D8 00 DD
This info is received from transmitter with code 63KDG
Messages are sent every 5th minute using 4 channels so that 1st message uses channel 2425 MHz, the next after 0.5 seconds 2450 MHz, the next after 0.5 seconds 2474.737 MHz and the last after 0.5 seconds 2477.237 MHz.
CRC value is not used in transmission and therefore there must be some other checksum, maybe the last byte.
All measured values are using the very same calibration
Bytes 1-10 and bytes 16-17 are always same except bytes 11 and 16. Byte 16 can be also D9. I have used all 4 channels and they are mostly the same except byte 11. It is packet number and can have values from 1 to 255. Every packet has different packet number for every channel.
Decoding:
I have converted data to level from bytes 13 and 15 using algorithm as below:
R = result 10 bits
R.0 = B15.7
R.1 = B15.6
R.2 = B15.5
R.3 = B15.4
R.4 = B13.7
R.5 = B13.6
R.6 = B13.5
R.7 = B13.4
R.8 = B13.2 XOR B13.1
R.9 = B15.2 XOR B15.0
It is possible that the result should have more bits but I have not yet found any values outside these 10 bits.
The 22th byte is some kind of checksum but I don't know how it is calculated.
Some messages:
The last value on the line is calculated level. The first number after the message is count. 4 means that all 4 messages are ok. Next is the blood sugar.
FF FF FF FF B0 CD 61 00 3F 03 37 79 AD 5A 29 D8 00 9B 4 10.1 852
FF FF FF FF B0 CD 61 00 3F 03 3B D7 AD 84 A9 D8 00 38 4 10.6 853
FF FF FF FF B0 CD 61 00 3F 03 3F BB AD 9D A9 D8 00 F5 4 11.0 853
FF FF FF FF B0 CD 61 00 3F 03 43 6D CD C3 A9 D8 00 4B 4 11.0 821
FF FF FF FF B0 CD 61 00 3F 03 47 40 AD 72 A9 D8 00 71 4 10.7 853
FF FF FF FF B0 CD 61 00 3F 03 4B E2 2D B5 29 D8 00 81 4 10.3 836
FF FF FF FF B0 CD 61 00 3F 03 4F 3D CD 0C 29 D8 00 1F 4 10.0 820
FF FF FF FF B0 CD 61 00 3F 03 57 DE CD 85 C9 D8 00 B1 4 9.6 819
FF FF FF FF B0 CD 61 00 3F 03 5B 85 0D C8 C9 D8 00 91 4 9.3 771
FF FF FF FF B0 CD 61 00 3F 03 5F A3 8D 0A 49 D8 00 5B 4 8.8 786
FF FF FF FF B0 CD 61 00 3F 03 63 78 8D A9 89 D8 00 2C 4 8.3 785
FF FF FF FF B0 CD 61 00 3F 03 67 00 8D C8 89 D8 00 1B 4 785
FF FF FF FF B0 CD 61 00 3F 03 6B 40 8D AF 09 D8 00 8A 4 7.9 784
FF FF FF FF B0 CD 61 00 3F 03 6F F1 8D D0 89 D8 00 1F 4 7.9 785
FF FF FF FF B0 CD 61 00 3F 03 73 F2 8D AC 89 D8 00 3F 4 8.1 785
FF FF FF FF B0 CD 61 00 3F 03 77 50 4D 76 89 D9 00 8C 4 8.2 801
FF FF FF FF B0 CD 61 00 3F 03 7B 79 4D 83 89 D8 00 D5 2 8.9 801
FF FF FF FF B0 CD 61 00 3F 03 7F 60 CD 8C 49 D8 00 FB 3 9.2 818
FF FF FF FF B0 CD 61 00 3F 03 83 75 CD 03 49 D8 00 83 4 9.7 818
FF FF FF FF B0 CD 61 00 3F 03 87 C8 2D 2A C9 D9 00 92 4 9.9 835
FF FF FF FF B0 CD 61 00 3F 03 8B 23 CD 63 C9 D8 00 6C 4 9.7 819
FF FF FF FF B0 CD 61 00 3F 03 8F 47 CD BF C9 D8 00 56 4 9.8 819
FF FF FF FF B0 CD 61 00 3F 03 93 AA CD B7 C9 D8 00 76 4 819
FF FF FF FF B0 CD 61 00 3F 03 97 C8 CD A5 C9 D8 00 59 4 9.3 819
FF FF FF FF B0 CD 61 00 3F 03 9B B2 4D 5C C9 D8 00 60 2 803
FF FF FF FF B0 CD 61 00 3F 03 9F 5E 8D D5 49 D9 00 7B 4 8.2 786
FF FF FF FF B0 CD 61 00 3F 03 A3 91 0D AF 89 D8 00 AD 4 7.6 769
FF FF FF FF B0 CD 61 00 3F 03 A7 B9 F9 B8 89 D8 00 47 4 7.2 753
FF FF FF FF B0 CD 61 00 3F 03 AB C8 79 DC 09 D8 00 02 4 6.7 736
FF FF FF FF B0 CD 61 00 3F 03 AF 11 39 B3 7E D9 00 4E 4 6.2 718
FF FF FF FF B0 CD 61 00 3F 03 B3 3A D9 F2 BE D8 00 F0 4 5.8 701
FF FF FF FF B0 CD 61 00 3F 03 B7 E8 59 EF DE D9 00 63 4 5.4 683
FF FF FF FF B0 CD 61 00 3F 03 BB 87 19 6D 5E D8 00 1F 4 5.1 650
FF FF FF FF B0 CD 61 00 3F 03 BF 4D E9 C1 9E D8 00 D5 4 4.7 633
FF FF FF FF B0 CD 61 00 3F 03 C3 A3 69 5A 1E D8 00 A9 4 4.4 616
FF FF FF FF B0 CD 61 00 3F 03 C7 C8 69 D2 EE D8 00 D6 4 4.2 615
FF FF FF FF B0 CD 61 00 3F 03 CC 44 A9 7A 6E D8 00 C9 3 3.9 598
FF FF FF FF B0 CD 61 00 3F 03 CF 56 29 09 AE D9 00 D0 4 3.7 581
FF FF FF FF B0 CD 61 00 3F 03 D7 71 C9 34 2E D8 00 C2 4 3.5 564
FF FF FF FF B0 CD 61 00 3F 03 DB 6B 49 F9 CE D8 00 8C 4 547
FF FF FF FF B0 CD 61 00 3F 03 DF 88 C9 6C CE D8 00 1C 4 3.3 563
FF FF FF FF B0 CD 61 00 3F 03 E7 FF 49 57 4E D9 00 A7 4 3.3 546
FF FF FF FF B0 CD 61 00 3F 03 EB 2C C9 DF 4E D8 00 F6 4 3.4 562
FF FF FF FF B0 CD 61 00 3F 03 EF 5B C9 94 CE D9 00 0A 4 3.6 563
FF FF FF FF B0 CD 61 00 3F 03 F3 9D C9 D6 CE D9 00 28 4 563
FF FF FF FF B0 CD 61 00 3F 03 04 10 29 84 2E D9 00 32 2 580
FF FF FF FF B0 CD 61 00 3F 03 08 B5 C9 70 2E D8 00 87 4 564
FF FF FF FF B0 CD 61 00 3F 03 18 5B 89 84 4E D8 00 4D 4 3.0 530
Because Dexcom sensor is in body fluid but not in blood, the results are processed in the receiver in some strange way. If I look at my results then sometimes I get many very same values but the receiver shows to vary the value from sample to next. Or I can see the results are changing but the receiver shows the same old value.
I have programmed a Wixel Pololu USB board for at get these results using Putty in my PC. Next I think to add a button to the board for calibration. Normally Dexcom receiver is calibrated every 12 hours by measuring the real blood sugar with normal meter and giving that value to receiver. I think to use a button so that I press this button when the sugar level is near 5.0 and then my Wixel uses this level as a reference. Then my Wixel sends the difference compared to reference level to my insulin pump. Then my pump can control the basal level in small steps up or down depending how big the difference is. Maybe I can then stop the alarms every night when the blood sugar is going to low.
More info to Dexcom:
For upper bits this works better:
R.8 = (B13.3 XOR B13.2) XOR ((B13.3 XOR B13.1) OR (B13.3 XOR B15.2))
R.9 = (B13.3 XOR B13.0) XOR ((B13.3 XOR B15.2) OR (B13.1 XOR B15.3))
There might be some simpler solution but this is got using searching software.
It is possible that the result should have more bits but I have not yet found any values outside these 10 bits.
The bytes 5-7 have the sensor SN
B0 CD 61 = 63KDG
71 3B 62 = 64ETH
I don't know yet how it is decoded.
I have sent this here because I didn't know how to reply my own message.
Hi
yep, Don Browne (Dexcom watch project) has done a bit of work decoding as well. I've been working on this too for a while.
We also hacked the sensor data records out of the receiver, and compared to sniffed packets using TI SmartRF Packet Sniffer. It's using the SimplicIT protocol, and there are only 7 bytes of payload.
I believe the transmitter "ID" is used in a checksum byte only - probably the 7th payload byte. Since the receiver must reject transmissions from other transmitters it has to be keyed on transmitter "ID". I put ID in quotes because the source SimplicIT address is not related to the transmitter "ID".
There are 2 values transmitted each time. Either Signal+noise and noise (for cancellation - since there is a reference electrode for noise cancellation) or something else (maybe a confidence interval). We can see the 2 readings plaintext (unencrypted) in the packets. The 2 numbers are generally quite close. It's possible there's a low signal to noise.
It looks like the values are maybe 12 or 13 bits. The values in the receiver (converted / calibrated) are only 10 bits though, and range only goes up to 401.
Hi, I have attached Pololu application file. Radio is not optimized but it will show 18 byte payloads. I don't know if the frequencies are the same anywhere but this works at least in Europe.
7370-dxc.zip (12.5 KB)I've attached one.
7369-dexcom.prs (736 Bytes)Hi hjoke.
It's actually using TI (Texas Instruments) chipset, and SimplicIT stack. The packet format is 18 bytes overall.
dest address (4 bytes) FFFFFFFF = broadcast
src address (4 bytes)
port (1 byte) always 0x3F
device info (1 byte) always 0x03
transaction id (1 byte) incremented each packet
payload (7 bytes)
I've captured using several TI CC2511 EMK concurrently, and the payload doesn't change based on transaction id for the same sample.
Hi Adrien
Sensor 64ETH not connected at all
FF FF FF FF 71 3B 62 00 3F 03 69 00 00 00 00 D8 00 33 4 0
Sensor 63KDG connected
FF FF FF FF B0 CD 61 00 3F 03 98 6E D9 AB 1E D8 00 4C 4 696
If bytes 5-8 are src address (4 bytes), why they are different. I think they are the sensor ID.
I think I need a supermagnet to get sensor 64ETH to off state again.
I think these sensors are switched with reed switch and they are packed using big magnet and then the small magnet is enough for at keep it off.
When they are removed then they stay on all the time.
Hi. Transmitter ID is a coded version of source address.
According to patent US20120255875 (thanks to Henrik Leon for pointing this out), the 32 bits is split into 5-bit values, and looked up in a table. Table goes from 0-9, A-Y excluding O, I, and V (and Z).
e.g. my one is "638Q0" and source address in packets is 00 A3 61 00. If you convert to LE, you get 00 61 A3 00, which in binary is
0000000 00110 00011 01000 11000 00000
ignore 1st chunk, you get 6 3 8 Q 0
So it's just a way to represent the MAC address of the transmitter.
Hi Adrien, many thanks for help. It seems to be much simpler than I have expected.
Hi Adrien, here is a small log with my new application:
64ETH 00 00 00 00 D7 00 77 4 0
64ETH 00 00 00 00 D8 00 33 4 0
63KDG 0E DE 80 DA D8 00 E9 4 443
63KDG B0 BE 50 DA D8 00 28 4 475
63KDG 2C FE 77 DA D8 00 83 4 507
63KDG 7C 09 39 BA D8 00 39 4 525
63KDG A5 09 01 FA D8 00 57 4 527
63KDG 4D 89 A9 0E D8 00 50 4 528
63KDG 73 49 4A 8E D8 00 FB 4 545
63KDG EF 29 A2 4E D8 00 86 4 578
63KDG A5 69 35 CE D8 00 F8 4 611
The first 2 lines can give a little help if somebody is interested to solve the checksum algo. I think the byte with values from D7 to D9 can be the battery level. It would be interesting to get the message from a transmitter with low battery.
A log when the transmitter has been 15 minutes in fridge
64ETH 00 00 00 00 CE 09 46 maybe low battery warning
A log when the transmitter has been 15 minutes in fridge
These 3 messages came in few seconds
64ETH 00 00 00 00 D0 09 CE
64ETH 05 01 48 02 00 33 00 D0 09 CE 4 448, 05 instead 0f 3F and 01 of 03
64ETH 00 00 00 00 C5 02 F1 battery voltage has gone more down
64ETH 00 00 00 00 D2 00 4B
64ETH 00 00 00 00 D3 00 A2
64ETH 00 00 00 00 D4 00 63
64ETH 00 00 00 00 D5 00 8A
64ETH 00 00 00 00 D6 00 9E
64ETH 00 00 00 00 D7 00 77
64ETH 00 00 00 00 D8 00 33