Thin is in

Test layout of parts on new PCB design.  This will be the first without a wixel.

Finished thickness should be 0.45" including case.  As I'm typing this, I realize I can get down to 0.4" if I do a cutout for the battery.   Finally gets me thinner than the dexcom, which is 0.5".

Kills me to have to leave a header on the board for programming and charging, could cut 0.4" off the length if I could do something different.  

This will be very pocket friendly.

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