Friday, March 13, 2015

Healthkit

I was curious about all the recent hype about apple and CGMS data.  I noticed a while back that healthkit had hooks for Glucose, although it disappeared from the api for a period of time.

Finally, the 8.2 release has it.  Here's this morning:



So, first impression, the graph is basically, useless.  Upper line is 300, middle line is 110?
I thought I could zoom in on the points by double tapping, nope.  And the time scale is fixed, 12-12.

A potential positive here, all I needed was an app writing glucose values to healthkit.  Theoretically, any other app should be able to subscribe to that data with the Users permission.  That could be major, real time access to your data from any approved iOS application.

So we might see a proliferation of iOS apps that handle CGMS data in some capacity, certainly something better than what's above.

On another note, the new model died after 2 months.  First of my devices to malfunction.  Probably due to the wire wrap wire, jumpers that I used.  Redesigned the board, with only two jumpers, and relocated the connection points to where they are easier to access.  Routed the slot for the crystal, "carefully" this time, and relocated some of the traces so I wouldn't be cutting them...
Top trace isn't so pretty, I had to touch that up with a sharpie before etching.



On the XCode side, upgraded to whatever version supports 8.2.  Found that breaks the ability of my iOS app to reconnect BLE from the background.  I spent allot of time getting that to work.  Luckily, recompiling my app as 8.1 appears to solve that issue(for now), until I figure out how the code is supposed to work.  

Finally, it's easy enough to write data to healthkit, if you start with the Heart Rate example.  The tricky part is getting the units correct.  The closest unit of measurement you can choose is g/L.  If you're using mg/dl, you'll need to divide that value by 100 before writing to healthkit.  

Sunday, March 1, 2015

A Start at some BLE hacking

I've been feeling a need to have a better understanding of what these BLE devices are doing.  I would like to get back to having the iPhone as optional for my setup.  This means I need to understand the BLE Central role, and the packets these various devices are exchanging, so that I can duplicate them with a low level device, namely an arduino.

So, I fired up a Raspberry PI, I seem to have a few lying around these days.  Oh, it has a bluetooth dongle plugged into it.

pi@raspberrypi ~ $ sudo hcitool lescan>scan.txt
pi@raspberrypi ~ $ cat scan.txt|sort -u

5C:F9:38:C1:2E:02 (unknown)
CE:8E:1A:16:CE:2F CGMS MICRO1
FF:E8:16:98:EE:BA (unknown)

Shows me 3 BLE devices.  The CGMS one is an RFDuino.  I turn off a pebble and the "FF" one vanishes.  Interesting, that's not what I thought was the pebbles MAC address.

Now, I turn off bluetooth on my iPhone.  These two show up:
CE:8E:1A:16:CE:2F CGMS MICRO1
E9:7F:13:9D:90:53 vivosmart #3895410566

I really want to poke at the Vivo, but I have no clue what it wants.  Right now, I can only get it to tell me that I can't connect.
I'll stick to the RFDuino for now since I have full control of it.  

sudo gatttool -t random --primary -b CE:8E:1A:16:CE:2F –I

Note the "random".  Spent a couple of hours getting the new version of gatttool onto the PI for this.  It's a security feature, and most BLE devices require it, RFDuino being one.

Then:

> char-desc
handle: 0x0001, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0002, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb
handle: 0x0004, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb
handle: 0x0006, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb
handle: 0x0008, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0009, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x000a, uuid: 00002a05-0000-1000-8000-00805f9b34fb
handle: 0x000b, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x000c, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x000d, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x000e, uuid: 00002221-0000-1000-8000-00805f9b34fb
handle: 0x000f, uuid: 00002902-0000-1000-8000-00805f9b34fb
handle: 0x0010, uuid: 00002803-0000-1000-8000-00805f9b34fb
handle: 0x0011, uuid: 00002222-0000-1000-8000-00805f9b34fb

This is the Write attribute, so lets write something
[CE:8E:1A:16:CE:2F][LE]> char-write-req 0x0011 ff02ff0344

RFDuino serial terminal app shows:
RFduinoBLE_onReceive (this is an interrupt I have coded)
FF:2:FF:3:44:  (this is what the RFDuino just received)

You can also read the other attributes above, like:
>[CE:8E:1A:16:CE:2F][LE]> char-read-hnd 0x002
Characteristic value/descriptor: 0a 03 00 00 2a

I think this one was the Manufacturer name.

At this point, I realize I'm not going to get any further from Unix.  I need to order the Ubertooth from Sparkfun so I can do some serious packet sniffing.





Monday, February 16, 2015

Vivosmart as CGMS

I went to the store this weekend to get the Nike Fuel, but they didn't have it.  I bought the Garmin Vivosmart instead.  The picture could be better, it was nearly impossible to photograph the display.


I took a chance that I could get BG data onto it in a usable way.  To do this I'm just sending a notification from the iPhone.  Three taps whenever you want to see your BG.  The only negative is I can't control the buzzing(when the notification is received), other than to turn it off.

This is the perfect device for the gym.  The watch is too bulky, and potentially dangerous to other people, and of course, people wonder why you are wearing it in the first place.  Lots of people are wearing trackers these days, it's low profile, all rounded edges and it's just black plastic until you tap it.  Have I mentioned the time someone asked me if my HR was really 185? ...

From the iPhone you configure it to only keep 1 notification, so the new one always overwrites the last.  On the Vivo, there's a privacy setting where you turn alerts off, if you leave it on, you'll get a brief buzz every 5 minutes.  If that option could be configurable by app, I could get this to do alerts.  But, as it stands, it's all or none.

Saturday, January 31, 2015

Somewhat broken...

I flashed a couple of changes to the device during the week.  Somewhere in that time I lost most of the sensitivity.  Call me paranoid but I suspect there are some undocumented features at work here, such as:
- CC2500 needs a power cycle to reset it ? (Like blue smirf)
- Library changes don't always get picked up by Arduino (like Wixel)

I had RSSI in the -50's, now they're in the -70's.

Originally I had the bare minimum for register settings, then I slowly added additional ones.  Living life in 5 minute increments.  Biggest improvement was setting the bandwidth slightly below the 335 khz that Dexcom wants.  RFStudio will choose a value of 400 khz, the other increment available is 325.  325 made a huge difference.

So, I'm back to the minimum and testing one value at a time.

On another note, I bought one of these:



This will allow me to experiment with Central role BTLE.  And, someone has cracked the Nike Fuel band, See->http://hackaday.com/2015/01/30/hacking-the-nike-fuelband/

This might make a good display device, and it appears to take a bitmap for that display, like the MetaWatch.  So maybe, we can talk directly to it and leave the Phone at home.

News alert, RSSI's back in the 60's, just by changing the "TEST" registers.  Isn't that great, if you call something "TEST", should it have any real purpose? Noooooo.  Thank you TI.

Almost time to head to the gym to hit people.  My best test environment.  Something there shuts down the Dexcom (antenna symbol) and my custom devices.

Saturday, January 17, 2015

Finishing this one up

Printed case view from the slicer.  I got lucky today, I was able to change the filament without having to disassemble the print head, small miracle.




Theory is, these will slide together and I'll add a little hot glue to hold it all together.  Real close to encasing this one in epoxy, but I'd like to find a way to cut down on static first.

Assembling the PCB didn't go quite as well as I'd hoped.  The CC2500 has a large(ish) crystal on the back (this is how they can sell for <$5).  I had to carve out a hole in the board, which required I add another jumper.  I knew I was going to route a slot, I just didn't realize how large it was going to end up being.


Here's a view of the completed board, with the separate lipo charger.  I usually mount the lipo unit on the same board, but I realized I could get this one really small if I did without.

Here's a view of the carving on the back of the board to allow the CC2500 to sit flush.



The CC2500 didn't work initially either.  I had to reheat all the connections, and the ones on the RFDuino.  Then I used a solder wick to remove excess solder.  After a few rounds, everything was working.  This just goes with the territory when you're hand soldering surface mount components.
I have an electric frying pan and solder paste, I may give that a try next.

And finally, most of my models since last January.


Friday, January 16, 2015

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.

Wednesday, December 24, 2014

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.