Here's a couple of hours out of my Sunday.
Wednesday, April 30, 2014
Evaluating the Rfduino
Here's a couple of hours out of my Sunday.
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
Tuesday, April 22, 2014
There is a Pattern
Houston we have a pattern
AF 89 AA 4E : 76 1010111110001 001 1010101001001 110
28 49 55 4E : 77 0010100001001 001 0101010101001 110
A9 49 DE CE : 80 1010100101001 001 1101111011001 110
8D 49 AF 4E : 81 1000110101001 001 1010111101001 110
E3 49 BC 4E : 82 1110001101001 001 1011110001001 110
10 C9 37 CE : 83 0001000011001 001 0011011111001 110
CE C9 E2 2E : 86 1100111011001 001 1110001000101 110
67 29 4E 6E : 97 0110011100101 001 0100111001101 110
9B A9 66 EE :103 1001101110101 001 0110011011101 110
C3 A9 AD 6E :103 1100001110101 001 1010110101101 110
28 69 AF AE :105 0010100001101 001 1010111110101 110
5A 69 0D 6E :107 0101101001101 001 0000110101101 110
9B 69 F8 1E :110 1001101101101 001 1111100000011 110
7B 69 74 6E :110 0111101101101 001 0111010001101 110
69 E9 A9 1E :115 0110100111101 001 1010100100011 110
93 99 E7 EE :117 1001001110011 001 1110011111101 110
F9 19 97 1E :122 1111100100011 001 1001011100011 110
FF D9 1E 5E :135 1111111111011 001 0001111001011 110
C0 39 BD 3E :151 1100000000111 001 1011110100111 110
B3 B9 EE 7E :163 1011001110111 001 1110111001111 110
F6 B9 0E 7E :163 1111011010111 001 0000111001111 110
Pulling out the BOLD portion, flipping it around:
1111011010111 reverse bits->1110101101111 7535 :163
1001101110101 reverse bits->1010111011001 5593 :103
1100001110101 reverse bits->1010111000011 5571 :103
1010111110001 little endian->1000111110101 4597 :76
The other stuff should be background...
I'll reformat this tonight when I have access to a real browser.
Thursday, April 3, 2014
Time to go Rainman on this
Here's a range of data from the packet sniffer.
Does anyone see a pattern here, I don't.
Err indicates a checksum error, don't worry about it. I reordered the data by glucose level so you can see how identical readings can look pretty different.
2 day old sensor
Does anyone see a pattern here, I don't.
Err indicates a checksum error, don't worry about it. I reordered the data by glucose level so you can see how identical readings can look pretty different.
2 day old sensor
txn
--xmtr id-- id crc mg/dl
____________________________________________________________
FF FF FF FF CA 58 61 00 3F 03 40 AF 89 AA 4E D8 00 37 : 76
FF FF FF FF CA 58 61 00 3F 03 3C 28 49 55 4E D8 00 1C : 77
FF FF FF FF CA 58 61 00 3F 03 EF A9 49 DE CE D8 00 F5 : 80
FF FF FF FF CA 58 61 00 3F 03 F3 8D 49 AF 4E D8 00 16 : 81
FF FF FF FF CA 58 61 00 3F 03 44 E3 49 BC 4E D8 00 0D : 82
FF FF FF FF CA 58 61 00 3F 03 EB 10 C9 37 CE D8 00 01 : 83
FF FF FF FF CA 58 61 00 3F 03 E7 CE C9 E2 2E D8 00 10 : 86
FF FF FF FF CA 58 61 00 3F 03 F7 19 C1 CD 4E D8 00 67 : 87 err
FF FF FF FF CA 58 61 00 3F 03 FB 95 C9 FB 4E D8 00 1A : 88
FF FF FF FF 0A 58 61 00 3F 03 DF A6 29 9E AE D8 00 E9 : 93 err
FF FF F7 FF CA 58 61 00 3F 03 DB 67 29 4E 6E D8 00 86 : 97
FF FF FF FF CA 58 61 00 3F 03 FF 84 A9 9E CE D8 00 FC : 98
FF FF FF FF CA 58 61 00 3F 03 20 15 A9 90 6E D8 00 D7 :102
FF FF FD FF CA 58 61 00 3F 03 50 CA 99 4D AE D8 00 02 :102 err
FF FF FF FF CA 58 61 00 3F 03 D7 9B A9 66 EE D8 00 2A :103
FF FF FF BF CA 58 61 00 3F 03 14 C3 A9 AD 6E D8 00 0A :103
FF FF FF FF CA 58 61 00 3F 03 24 28 69 AF AE D8 00 80 :105
FF FF FF FF CA 58 61 00 3F 03 10 5A 69 0D 6E D8 00 1B :107
FF FF FF FF CA 58 61 00 3F 03 08 F1 69 8A AE D8 00 6D :108
FF FF FF FF CA 58 61 00 3F 03 D3 9B 69 F8 1E D8 00 65 :110
FF FF FF FF CA 58 61 00 3F 03 0C 7B 69 74 6E D8 00 25 :110
FF FF FF FF CA 58 61 00 3F 03 CF 69 E9 A9 1E D8 00 CE :115
FF FF FF FF CA 58 61 00 3F 03 54 93 99 E7 EE D8 00 E4 :117
FF FF BF FF C2 58 61 00 39 03 94 7A 19 9F 9E D8 00 02 :121 err
FF FF FF FF CA 58 61 00 3F 03 CB F9 19 97 1E D8 00 72 :122
FF FF FF FF CA 58 61 00 3F 03 58 DB 99 31 9E C8 80 56 :129 err
FF F8 E7 FF CA 58 61 00 3F 23 90 E5 99 17 4E D8 00 B2 :130 err
FF FF FF FF CA 58 61 00 3F 03 5C 04 59 12 5E D8 00 A0 :134
FF FF FF FF CA 58 61 00 BF 03 60 95 5B BA 1E D8 00 4B :135 err
FF FF FF FF CA 58 61 00 3F 03 64 FF D9 1E 5E D8 00 24 :135
FF FF FF FF CA 58 61 00 3F 03 6C 01 79 06 3E D8 00 74 :149 err
FF FF FF FF CA 58 61 00 3F 03 84 C0 39 BD 3E D8 00 62 :151
FF FF FF FF CA 58 61 00 3F 03 80 23 39 3C BE D8 00 E9 :155
FF FF FF FF CA 58 61 00 3F 03 70 9C 79 4D BE D8 00 79 :158
FF FF FF FF CA 58 61 00 3F 03 7C 50 B9 07 BE D8 00 09 :159
FF FF FF FF CA 58 61 00 3F 03 74 B3 B9 EE 7E D8 00 53 :163
FF FF FF FF CA 58 61 00 3F 03 78 F6 B9 0E 7E D8 00 9F :163
Lets agree that we're interested in the 4 bytes after the transaction id. Note how the second bit of the second byte always is a "9", and how bit 2 of byte 4 is always an "E".
I expected that 2 bytes would be a raw value, and 2 bytes would be a background. I'm not seeing that here.
--Cleaned up Just look at the important stuff
AF 89 AA 4E : 76
28 49 55 4E : 77
A9 49 DE CE : 80
8D 49 AF 4E : 81
E3 49 BC 4E : 82
10 C9 37 CE : 83
CE C9 E2 2E : 86
19 C1 CD 4E : 87 err
95 C9 FB 4E : 88
A6 29 9E AE : 93 err
67 29 4E 6E : 97
84 A9 9E CE : 98
15 A9 90 6E :102
CA 99 4D AE :102 err
9B A9 66 EE :103
C3 A9 AD 6E :103
28 69 AF AE :105
5A 69 0D 6E :107
F1 69 8A AE :108
9B 69 F8 1E :110
7B 69 74 6E :110
69 E9 A9 1E :115
93 99 E7 EE :117
7A 19 9F 9E :121 err
F9 19 97 1E :122
DB 99 31 9E :129 err
E5 99 17 4E :130 err
04 59 12 5E :134
95 5B BA 1E :135 err
FF D9 1E 5E :135
01 79 06 3E :149 err
C0 39 BD 3E :151
23 39 3C BE :155
9C 79 4D BE :158
50 B9 07 BE :159
B3 B9 EE 7E :163
F6 B9 0E 7E :163
Some other information from a Dex 7 log, just to give an idea on ranges. Also, note the hex doesn't match the calculated value... Highest possible value of 0xFFFF = 65535
RawCountsX="0x9C34" RawCounts="115520" FilteredCountsX="0x7BEB" FilteredCounts="57176" GlucoseValue="162" RawEstimatedGlucoseValue="-3934" RawCountsX="0x9BEA" RawCounts="114336" FilteredCountsX="0x7C44" FilteredCounts="57888" GlucoseValue="159" RawEstimatedGlucoseValue="-3937" RawCountsX="0x9BE5" RawCounts="114256" FilteredCountsX="0x7C02" FilteredCounts="57360" GlucoseValue="159" RawEstimatedGlucoseValue="-3937" RawCountsX="0x99BA" RawCounts="105376" FilteredCountsX="0x7A1B" FilteredCounts="53464" GlucoseValue="159" RawEstimatedGlucoseValue="28831" RawCountsX="0x9784" RawCounts="96320" FilteredCountsX="0x78D9" FilteredCounts="50888" GlucoseValue="122" RawEstimatedGlucoseValue="-3974" RawCountsX="0x95E2" RawCounts="89632" FilteredCountsX="0x7639" FilteredCounts="45512" GlucoseValue="117" RawEstimatedGlucoseValue="-3979" RawCountsX="0x937B" RawCounts="79792" FilteredCountsX="0x7445" FilteredCounts="41512" GlucoseValue="85" RawEstimatedGlucoseValue="-4011" CalibrationSlope="297.628370890284" CalibrationIntercept="53434.3524196528"
Saturday, March 29, 2014
Cutting out the middle man
I've had the TI CC2511 Development board laying around for a while. I was pretty confused by the software for interacting with it. Compounding the confusion, was that it doesn't play well with Windows 7. Like most medical tech, since the approval process is drawn out, you're getting obsolete technology by the time the product gets to market. In this case, the development board software hasn't been updated since 2009.
I was about ready to dust off an XP notebook, but first I took a stab at filling in some of the fields in the RF Studio program. I was then able to save that configuration, which doesn't get saved in the format that the packet sniffer wants (why?). Then I opened the Packet Sniffer and manually changed some of the Registers.
And "Poof", it works.
The last two records you see are for 107 and 110 mg/dl. Looks like glucose raw counts are bytes 12-15. This is an 8 day old sensor, so expect the curve to be flatter.
I wish I could hook this to a micro controller right now, but this is going to be a challenge. I'm probably going to have to go through the whole USB sniffing process that I did with the Dexcom to use this device. Also, I don't yet know if there's a USB Library that will play with this on Arduino. I wish this came in a non-USB version. May have to buy the chip and go at it directly.
A shot of the Development board, you can cut off the strip I've drawn an arrow to. I really want this in a non-USB version. I can get that in a full kit for around $500.
Tuesday, March 4, 2014
New watch, additional functionality
Trying out an email update today.
Got the dressier version of the Metawatch.
Doesn't match the race bike, but looks better at work.
Predictive feature is being "field" tested. Number to the right is indicating that I might go over 180 in 33 minutes. I'm taking the slope of the last 15 minutes and extrapolating out to where I'll be over 180 or under 80. Also, I'm taking 20 minutes off of the estimate to account for the delay. Higher values indicate steady blood sugar. Greater than 99 minutes, I don't show anything.
Sunday, February 16, 2014
The final prototype for now
 |
| Front View |
 |
| Back View |
Finally got the Teensy Version soldered down. This is using a Sparkfun bluesmirf, silver, modem.
The switch on the left is for powering from the battery or through a USB port.
The battery is 1350 mAh. This is good for 11 hours.
This configuration is for use with the Metawatch, which is now working great. At least 3 days without a charge on the watch, and it no longer freezes. I would attribute this to the bluetooth dongle. The Bluesmirf is configured to automatically reconnect. You do this from the modem itself, don't waste time trying to get the Arduino to do this. The modem handles ALL of the connection details, you just have a pipe from the Arduino to it to pass information. I also tried the Bluesmirf "Gold", reconnect never worked, and I didn't notice an increase in range. It has a much more recent firmware version.
This link is a good place to start for details on how to deal with the Metawatch and the BlueSmirf. This will get you up to speed on how to program the Modem as well as the watch. Although this example shows controlling the connection process from the Arduino, don't be tempted. The BlueSmirf is meant to do that on it's own.
The hardest part of this, software wise, is creating and sending a 96x96 packet representing your display to the watch.
This would be an example of how the binary representation of a few pixels gets turned into Hex, that gets sent to the Metawatch in 16 byte packets. I found some font definition files on the internet that gave me the Hex for all the numbers and arrows I needed.
Ex. this is "8":
0x0e, 0x11, 0x11, 0x0e, 0x11, 0x11, 0x0e
When I finally got this to work, I had a microscopic font, on it's side, and upside down. After a couple of bit operations, it then took me a while to realize that if I just sent each line twice, I could enlarge the font to a decent size.
With all that squared away, I'm going to add a small graph and I'm thinking about a predictive feature. A report of how long it would be before I'm over 180 or under 80, depending on which way the wind is blowing. Probably will be a up or down arrow, and the number of minutes.
Subscribe to:
Posts (Atom)