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.