I SPI a CC2500

So this is now working.  A very long, tedious process.  No shortage of posts out there from people abandoning these things.  Lots of issues with the available Arduino CC2500 SPI libraries, here's a random list of things you should know (ymmv):

• If "things" aren't working, lead length probably isn't a cause
• The RX FIFO is read only, you can't clear it by writing to it
• The CC2500 has some registers that have to be written to in Burst mode
• You don't need to do anything with SimpliciTI.  In fact, why would you?
• The CC2500 is 3.3 Volts, don't connect MOSI directly to an UNO pin.  There is mention on the web that it works anyway, might depend on the board.  In my case, it doesn't work, you need to add a resistor.  5v doesn't appear to damage it though.
• Because these boards run at 26mhz, allot of the register settings you would use on a Wixel are completely different.  You need to recalculate these using TI RF Studio.
• You have to configure and use the GDO0 pin.  There is some code out there that doesn't.  I don't know how that could work.
• Use led's to monitor the status of all the pins you're using on the CC2500, but be aware that you may also be affecting the status of those pins (is that possible?)
• Simply reading from the FIFO does not flush it, you need to issue a command for that.

I'll put my revised SPI library on github at some point, when it's fit for the public.  I had to add Read Status Register and Read Burst Register functions to what is publicly available.

Initially I setup two separate Uno's with CC2500's.  I was paranoid about the RFduino, really working with SPI, in the end, I can confirm it works great.

I used example receive and transmit programs that are available with the library written by yasiralijaved.  Once I confirmed this works, I slowly added the new settings from RF Studio.

At one point I found that the IOCFG0 (configures the GDO0 pin) register setting no longer worked after changing some of the MDMCFG registers.  I had to use 0x01, assert when the RX FIFO is filled.  

I also configured a Wixel to transmit Dexcom packets every 10 seconds so I could work with the register settings in near real time, not every 5 minutes.

I also configured a RF24 to act as a frequency scanner, so I could see that I was transmitting on the correct frequencies.  I plan to breadboard this gadget and give it a display.  You can also see here just how much "noise" there is in the 2.4 ghz band.

Trying out the CC2500

Finally getting around to this.  Slow work today, waiting on a client, so I'm going to get this onto a breadboard.

The plan is, start with this website(there's a link here):
http://forum.43oh.com/topic/1493-simpiciti-tutorial-for-cc2500/

Get this to work using the full SimpliciTI stack, and see what I really need.  If I can get this to work on a platform it plays natively with, I should be able to port this to the RFDuino.

So, from the left we have a TI MSP430 Launchpad, next to that a CC2500 module broken out onto a Schmart board, and finally the RFDuino.  End product will be on a PCB, may or may not go with the surface mount RFDuino.  Power usage may be low enough to use a coin cell, which would be very cool.

I've picked the 2500 up a few times over the last 6 months, this post will help me keep track of my progress, I have so many bookmarks it's hard to find the details anymore.  I've tried SPI with the CC2500 to an Arduino.  SPI isn't plug and play.  I could only get as far as updating registers.

Lots of sensitive timing issues, most recommend a scope.  I think some of the issues I've experienced trying other peoples code is the microcontroller speed.

------Update-------
Abandoning simpliciTI (Again).  This is for people with 40 hours to kill, not weekends.

I think I'm getting closer just using SPI.  IOCFG0 is one important factor in the variability of code you find.  The "sheet" for my CC2500 board refers to a couple of GDOX pins as general use.  So you think great, don't need to hook those up.  Turns out GDO0, is responsible for notifying your code that a packet has been received.  But, only if you set the IOCFG0 register with the correct value(and there are many to choose from).  Most likely 0x06 is what we want here.

Pebble versus Metawatch Shootout

Finally got this working with the Pebble.  I've had the Pebble for over a year, but I could never get the Arduino->BlueSmirf combination to work.  

I bit the bullet and wrote an iOS application to handle the watch communication.  I'm a long way from finished on that front, but I've got enough functionality to say I really like the watch.  

Since this is an iOS app, all the other watch functionality is present since it's paired with the phone.  One of those features is the Misfit Shine fitness app(free activity tracker).  

The BLE signal from the phone to the watch is strong.  The watch receives updates from ~30 feet away.  The metawatch is more like 10.  Cranking up the bluetooth power wouldn't fix that, so I assume it's governed by antenna design.

The whole experience of setting up this watch is well done.  It has a web based development environment, and there's allot of easily accessible information available for developers.  Metawatch, meh.  

Looking forward to adding an indicator on the watch to indicate "late" BG readings.  I could never add this to the Metawatch without purchasing an IAR($3000) development license.  It's also nice not having to map out my fonts, although I'll have to cook up some new arrows.

The iPhone is within 30 feet of me most of the time, so we'll see if this works for me.

Value of predictive algorithms

Graphs are great, but it's not exactly intuitive to look at a chart and understand where you might be in relation to that line...  Case in point.

The watch said 120 a second or two earlier.  If I was just looking at the CGMS, it's not so obvious that there's a problem.  On the other hand, the watch is telling me that I'm probably 80 at this moment (and dropping like a rock).  Explanation of the display, the number to the far right is telling me number of minutes estimated until I'm 80, if the arrow was pointing up, that would indicate number of minutes until I'm 180.

This is a real example of how some background calculations can cut through allot of noise.  10+ minute delay, device inaccuracy and calibration inaccuracy combined can't hide the fact that a plummeting blood sugar is going to get you into the danger zone quicker than you realize.  

Next time, more fun with hardware.

PCB's

Working on creating printed circuit boards, since I'm moving to more surface mount components, and the point to point wiring is messy and takes up space.  A few months ago I tried the photo-resist method.  Very sensitive, easy to over expose and expensive.  Did some more reading, and decided to try the Toner Transfer method.  

Results below.

This really works great.  I picked up a Cannon Laser Printer for $60.  

Steps:

1. Design the PCB in Eagle

2. Print on matte photo paper

3. Place on PCB face down, tape edges, iron with highest heat setting and steam for a few minutes.

4. Soak off the paper in warm water

5. Etch

I also did this for a two sided board.  Only warning would be to avoid Radio Shack boards, the copper lifts too easily.

Lots of tutorials on this, some are over thinking the process.  This was very easy.  Surface prep and heat are probably important factors.  I can see no reason to buy a laminator.

Arduino to CGMS Code

I've loaded a basic example of an Arduino to CGMS interface here:
https://github.com/brownedon/cgms


Also, the 3d printed case plans are here:
http://www.thingiverse.com/thing:398298/#comment-512883

Calibration Data Part 2

Accidentally deleted the other post, when I tried to update the formatting.  Here's another go, this time with a 7 day old sensor, transitioning to a 0 day old sensor :).  Interesting here to see how the Intercept doesn't change.  Slope was 906 before recalibration, SAME intercept.  This sensor has had other intercept values, most recently 27626.

                                                                                                                -rc (02 2D)--
01 16 02 01 87 06 00 00 03 00 00 00 05 02 2D 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EA 57
----date---- -- date ---  --slope=767  ----------  
FD C9 1F  0A 94 92 1F 0A  4B 4B 4B 4B 4B FB 87 40  
Intercept=30000--------
00 00 00 00 00 4C DD 40   00 00 00 00 00 00 F0 3F  03 06 00 00 00 00 00 00 00 00 00 02

-- Date---  --gluc--    --counts-   --date ----
D4 C9 1F 0A 88 00 00 00 E0 0C 02 00 67 C9 1F 0A 00
DE C9 1F 0A 88 00 00 00 E0 0C 02 00 67 C9 1F 0A 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BD B4

With two more calibration data points, slope is at 820, intercept continues to be unchanged.

BLE and other new devices

RFDUINO
I got on a kick a while back to use the RFDuino.  The size was appealing and I imagined it could do some things it can't.  For BLE devices, there are two roles, Central and Peripheral.  Watches are peripherals, as is the RFDuino, an iPhone is a Central.   So, after much head scratching, I've realized I can't connect an RFDuino directly to a watch.  Kind of a show stopper.  Other issues with the RFDuino, which may or may not be imagined:
1.  If you use the one and only serial port for something, you can't use the USB for debugging output.  Typical problem with single Uart microcontrollers, but this is why I like the Teensy and Mega ADK.  It's hard hacking when you're running into constraints.  In this case, you run out of options for debug output, and are down to blinking led's.
2.  The programmer is cumbersome, and you need to unplug the board from the circuit to re-program.
3.  When you google this product, mostly what you get are items related to the kickstarter.  Lots of people bought these, then went back to their caves and vanished.  There are few write ups on actual projects out there.

WIXEL
Another strange bird.  Will make you appreciate what the Arduino empire does well.  Constant "service" calls required to keep Serial output open, otherwise "stuff" just shuts down.  Want a simple delay statement, forget it, you'll lose your serial out.  Also, I've noticed that uploading new code, doesn't always happen, although it says it did.  The compiler for this thing is slow.  And then there's the lack of memory.  But, we're all using this for a very good reason, so deal with it...

1 year anniversary

Thought I'd summarize where I'm at now.  About a year has passed since I first wrote some C# to automate keystrokes and get glucose readings from the Dexcom Studio Software.

Now I use this:

I'm getting 22 hours on a charge.  This will keep me through racing season this year.  It's reliable, and I'm now using it every day.  I've gotten the watch to hold a charge for about 4 days.  There's a magic "sniff" setting that makes all the difference.

Now I'm working towards a keychain sized receiver that will use BLE to send packets to the watch.  All the pieces are there, I just need the time to put it all together.

That's hard now that the weather is decent again.

Evaluating the Rfduino

Got the rfduino in the mail this week. Unfortunately, I got the smt version.
Here's a couple of hours out of my Sunday.

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 

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...
The other set of data looks very similiar to the data in bold.
I'll reformat this tonight when I have access to a real browser.

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

                              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" 

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.

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.

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.

ANT+ Gizmos

Pursuing multiple threads here.  With ANT+, I can use a sports watch, and Hijack the HR channel.  A watch with HR and Alarms can work perfectly as a glucose monitor.  One late night of googling and I found some posts on ANT+ and Arduino.  Unfortunately the ANT+ development board sold by Sparkfun is long out of stock.  Some more searching and I found a similiar chip was available, but would need to be mounted.  Some photos of how I spent my Saturday.

 All this wouldn't be happening if it wasn't for this site.  First solder 17 very small wires,  started with Cat5, and pulled some strands out to get them through the holes.  Kind of like sewing.

Then, added a pair of pin headers so this would be easier to work with.  Also, these wires can only be flexed a couple of times before they break.  Added copious amounts of hot glue to keep everything from moving around.  I was going to post about the evils of hot glue... Maybe another day.  All this onto a Radio Shack protoboard, and then some love with the dremel.

Finally, Breadboarded and talking to the Arduino.  No problem receiving HR from a Garmin chest strap.  Now I need to figure out how to send a HR value.  Also, a Teensy is underneath the Uno, but the Serial Library's were causing me issues.  Turns out, you can't use SoftwareSerial etc.  You reference your serial ports as Serial1, Serial2 or Serial3.

Ex.  SoftwareSerial bt(9,10);

       bt.begin(baudRate);

Becomes:

      Serial2.begin(baudRate);

It took me a while to find a posting on this.

On another note, while troubleshooting why the TI USB Dongle doesn't work with the Teensy and a Mini circuits@home USB board, I discovered that I don't need to provide ANY power to the USB port for the Dexcom to work.  This means I can interface with the Dexcom, and not let it drain any power from my circuit. Sorry, turns out this wasn't true.  Lots of wires...

On deck for this weekend.  Hopefully get some code together for the Metawatch, and assemble something that I can carry around.  

For less hopeful projects I'd like to try getting access to the Pebble, although that doesn't seem likely.  Noone seems to have had any real luck with an Arduino, I'm looking into an article on "bit banging bluetooth" that looks promising.  

New Prototype

Today, I got the Dexcom talking to a Teensy 3.1 and a Circuits@Home Usb Stick.  Each of these boards is 0.7" X 1.5".  I've had these around for about a month, and they've been frustrating me.  Finally set aside today, as a day of failure, to work through the assorted issues.

FYI, I'm accumulating boards and watches at an alarming rate.

My problem here, is I was trying to just get the Chronos working with these circuits, since, in my mind, it's simpler.  Finally on a whim, I broke the code out for just the Dexcom, and it works.

I can plug yet another stick of gum size board into this mess, and I'll have either bluetooth or Ant+.  At this point, I may go with Ant+, simulate a HR packet, and use a Timex Ironman Watch.  I don't own that watch yet though...

The Ant+ dongle is insanely small, I'll attempt soldering that tomorrow.

Arduinos

I'm finally trying the Microcontrollers.

What you see here (L to R) is an Arduino Uno with USB Shield, a Teensy 3.1 with USB Shield and an Arduino Mega ADK.  Currently the ADK setup is running with the Dexcom and the TI watch.  Battery life is amazing.  I have the Mega written to "wake up" every 2 minutes, get the number from the Dexcom and update the watch, so the Mega is only using full current for a couple of seconds out of every 2 minutes.

The big hurdle with the microcontrollers, is USB support.  The Mega ADK comes with a single port, so I've added a USB hub.  I also was working with two Arduinos using I2C, one communicates with the TI the other with the Dexcom.  The problem with that configuration, is I can't save power by putting the Arduinos to sleep.

I may be able to get by with a very small battery, and have everything work for days without a recharge.  The TI watch has yet to require a charge since I purchased it last year.  The Metawatch needs a charge daily.

The Arduino Uno, was a failure, it can't handle the amount of data coming from the Dexcom.  I'm hoping the Teensy will work.  If it does, this will be almost pocket sized.

I also have on order a transmitter for the TI, that may have improved range.  Might be a week or two before I see that.  Also, with this device, I'll only need one USB Port, so the hub goes away.

Snowy weekend coming up, hope to at least see if the Teensy will work.