Thursday, April 24, 2014
Matching up Meter Records to Packet Sniffer
Finally matched up some of the packet data to a sensor record on the Dexcom. Assuming this is the raw counts from the sensor. Probably should be using all 4 bytes here, not just 3.
88 mg/dl
BD 52 FD 09 54 1B FD 09 C0 93 01 00 70 84 01 00 C8 00 05 93 :From sensor data record
3C 99 E2 1E :From packet sniffer
00111100100110 01111000100001 1110 :Convert packet to binary
00111100100110 Reverse->01100100111100 ->193C :Reverse the first 14 bits
And back to Hex
96 mg/dl
15 55 FD 09 AC 1D FD 09 90 99 01 00 70 9C 01 00 C5 00 C2 38 :From sensor data record
packet 99 99 E3 9E :From packet sniffer
10011001100110 01111000111001 1110 :Convert packet to binary
10011001100110 Reverse->01100110011001=1999
95 mg/dl
41 56 FD 09 D8 1E FD 09 20 9C 01 00 00 9B 01 00 C3 00 29 04 :From sensor data record
packet 43 99 0D 9E :From packet sniffer
01000011100110 01000011011001 1110 :Convert packet to binary
01000011100110 Reverse->01100111000010 =19C2
95 mg/dl
99 58 FD 09 30 21 FD 09 30 A3 01 00 C0 9A 01 00 BA 00 EE 50 :From sensor data record
packet CC 59 35 9E :95 :From packet sniffer
11001100010110 01001101011001 1110 :Convert packet to binary
11001100010110 Reverse->01101000110011 = 1A33
120 mg/dl
F9 61 FD 09 90 2A FD 09 80 E2 01 00 E0 D1 01 00 BA 00 DB D0 :From sensor data record
Packet 14 79 78 BE D8 :From packet sniffer
00010100011110 01011110001011 1110 :Convert packet to binary
00010100011110 Reverse-> 01111000101000 =1E28
The sensor data records look like this:
--date------------ --date------------ ----counts--------- --second set ?---
FD 3F FD 09 94 08 FD 09 20 90 02 00 00 96 02 00 C0 00 14 00
29 41 FD 09 C0 09 FD 09 C0 85 02 00 80 8D 02 00 C0 00 8D 43
55 42 FD 09 EC 0A FD 09 60 7F 02 00 E0 88 02 00 B7 00 31 00
81 43 FD 09 18 0C FD 09 00 7B 02 00 20 84 02 00 AD 00 67 55
AD 44 FD 09 44 0D FD 09 00 67 02 00 A0 7C 02 00 C4 00 3C D3
D9 45 FD 09 70 0E FD 09 A0 45 02 00 40 6F 02 00 CA 00 E3 58
05 47 FD 09 9C 0F FD 09 60 26 02 00 80 59 02 00 B2 00 D7 99
31 48 FD 09 C8 10 FD 09 60 FE 01 00 80 3A 02 00 B4 00 52 53
5D 49 FD 09 F4 11 FD 09 90 C1 01 00 80 12 02 00 B6 01 94 6F
BD 52 FD 09 54 1B FD 09 C0 93 01 00 70 84 01 00 C8 00 05 93
15 55 FD 09 AC 1D FD 09 90 99 01 00 70 9C 01 00 C5 00 C2 38
41 56 FD 09 D8 1E FD 09 20 9C 01 00 00 9B 01 00 C3 00 29 04
99 58 FD 09 30 21 FD 09 30 A3 01 00 C0 9A 01 00 BA 00 EE 50
Subscribe to:
Post Comments (Atom)
Nice!
ReplyDeleteJust looking at my receiver sensor data, the second long value have even much better (R near 1) correlation to EGV value (when looking at data within two "calibrations")
DeleteHi Don. I've been looking into this more. If you look at the record from the machine, there are 2 numbers stored in 4 bytes each and a short. The 2 numbers I think are transported as only 13 bits each. in each case you get 3 bits flag followed by 13 bits reading then another 3 flag fields and another 13 bit reading.
ReplyDeleteCC 59 35 9E => 11001100010110010011010110011110
1A33 => 1101000110011
reversed => 011 1100110101100 100 1101000110011
19ac => 1100110101100
I've repeated this with a number of readings, and it's reliable. Also it doesn't work if you consider the data to be 14 bits.
As for what the 2 number are / mean. They are generally pretty close (within 5000 which is about 5 points). I wonder if the way it works is sending high and low bounds on the reading, and if you used the average to correlate to BGL reading you might get a better result.
sorry about layout - couldn't figure out how to put it into pre mode.
DeleteAlso, it could be interesting to try correlating BGL to difference in these 2 numbers. the reason being is that the dexcom sensor has 2 electrodes that give a reading. There's the main one for the enzyme reaction, and there's another reference silver electrode which is meant to be used to cancel noise. If these 2 readings were the 2 electrode readings, then we could be meant to subtract the 2 to get the raw result. So this may correlate to BGL.
United States Patent 8231531 http://pdf.sumobrain.com/US8231531B2.pdf?AWSAccessKeyId=AKIAIBOKHYOLP4MBMRGQ&Expires=1399250086&Signature=b7vJ4mUT8eMUIlRXjksmmi2Wnh4=#view=FitH
ReplyDeleteI got 2 CC2511EMK devices, so I started capturing on 2 frequencies. So now we can say that the payload is plaintext (which we knew). We can also say that the TxId is not used in any computation (e.g. of checksum). The payload (all 7 bytes) is identical on the 2 frequencies I captured. So it really looks like the transmitter only affects the 7 byte payload, and so we're looking in that 7 bytes for the way to lock a reading to a transmitter ID. I'm guessing since the transmitter ID is 5 bytes, and we have about 5 bytes of significant payload, we could XOR the transmitter ID with the 5 bytes of payload, and then calc the normal dexcom checksum code over it.
ReplyDeleteSince the packet sniffer seems to give everything in bit-reversed order, we'd need to reverse first.
ignore that about transmitter ID. it's coded from the packet SimplicIT source address, split into 5-bit values and looked up in a table. So the SimplicIT source address is the transmitter ID, so we don't need to look for it anywhere else (such as a checksum)
Delete