Friday, March 11, 2016

Smallest device with the smallest watch

I've always wanted the Analog watchface, probably why I put up with my ugly display for as long as I did.  Now with the the Pebble round, seemed appropriate to spend the time and get the Analog face working.

The 3'oclock position shows estimated time until 80/180.  Under the date will be the missed signal (!) and funny data(???) indicators.  12'oclock is the slope of the glucose readings followed by the Calibration slope.  9'oclock is Glucose.
The round pairs better with the Blugiga radio than it does with my iPhone, good thing.  It seems the best way to get paired to upgrade the App, is to reboot the watch.  Strange.

Still need to design and print a charger base.  Good day today, the 3d printer is working!

Here's a better picture with more indicators in use.

Monday, March 7, 2016

Bluegiga WT12 Controls all Pebbles

Did some searching and found a bluetooth chip that does SSP Master, which is used by all the pebbles.  My existing code still works, just the initial configuration of the board (which you can do through serial) is different.

SET BT AUTH * 0000
CALL b0:b4:48:9d:cc:08 1101 RFCOMM

This configures the board to connect and automatically reconnect to a watch.  Power=0, gets translated to -2, which is still enough power to cover my house.  Once paired with the watch and the Wixel in sleep, it's around 5ma.  With the Wixel actively listening it's approx 27ma.  When the Bluetooth module receives data it's 35ma.  Generally you're running at 5ma, the higher numbers are for a few seconds every 5 minutes.  The pebble appears to be "chatty", so you see frequent 35ma bursts, this may be an issue, but I think I can get 20 hours out of a 110 mAh battery.

I'll probably make this over the weekend:

That's the WT12 "dead bugged" on top of the Wixel.  Curious to see if I can get away with that.

Allot of useful information here: , this guy also sells a development board for the WT12 which makes it breadboard friendly.

Friday, February 26, 2016

More BLE Central

I would still like a "Band"...  I really can't wear the watch when doing hand to hand stuff etc.  A band is a little easier to get away with, and less likely to hurt someone.

A few weeks ago I stumbled on some posts for the Xiomi MI, band.  Cheap thing $30, Amazon gets it to me in 2 days.  I found websites that detailed how to communicate with it from a BLE Central device, so I thought cool, I'll get one.  Impulse buy.

This was the perfect use for my BLE Nano.  I already had some BLE Central code written that worked for communicating with the RFDuino.  Of course, this wouldn't work...
After about 8 hours, it came down to a parameter change on the connect, ex.>peerAddr,  Gap::ADDR_TYPE_PUBLIC, NULL, NULL);

My original code had a random address type.  This was quite maddening because I could connect with the MI from both Unix and my iPhone using "LightBlue".  

It wasn't until I connected that I realized the communication protocol's for the MI had changed. 
The current protocol is actually more standardized.  All alerts (buzzing) are through a standard BLE endpoint for "Immediate Alert".   LED control, not so much, I now realize LED control isn't exposed to an external device.  My plan had been to use the 3 led's as a sort of traffic light, or:
- led 1 = >200mg/dl
- led 2 = >100mg/dl
- led 3 = blink out the 10's every minute or so.

Or something like that, coupled with buzzing to queue me in on what's going on.  
If you look around for posts on the MI, you'll see the lights don't really work anyway.  They're triggered by an accelerometer that only responds to some bizarre form of hand waving, I got them to light up once or twice, the motion required being way to ridiculous for public presentation.

That said, could be an excellent vibrating alert device that can go a month on a charge.

Some other notes from this experience:
1. The BLE Nano (with MBED) doesn't really work with Windows 10, unless you're comfortable restarting windows frequently.  The Arduino version may be fine, I have one of each, but I have issues with BLE Central on the Arduino version.  In the end, I moved my development over to the Mac.  Additionally, opening and closing serial windows and dragging/dropping hex files is a PIA.  I was able to automate this to some extent with the Mac, one of the reasons I purchased a Mac, nice to finally put that to use.  See my github for a basic script.  In a nutshell, it's a ksh that watches the download folder for a hex file, moves it to the Nano, and launches a serial window.

2.  I don't think BLE sniffing is all it's cracked up to be.  I have an Ubertooth and a Nordic device and can hook them up to Wireshark.  With an RFduino I can see all the "Magic" packets (ATT etc).  With more proprietary devices like the MI or the Pebble, once these things pair, I don't see anything.  If you want to hack a BLE device, decompile the Android APK if one is available.

On to the Pebble watch.  Still going strong.  Found out from Pebble support that the aplite versions of the pebble support "Pin" pairing via bluetooth.  The new models only support ssp (simple secure protocol).  They also pointed out the mfg'r note for nRF51, which indicates that while ssp is in the command set, it doesn't actually work.  Allegedly there's a beta that will support ssp, and will pair with the Pebble Time.  Wait and see.  

Wednesday, January 13, 2016

New year, new device

Finally got most of the kinks worked out of the Pebble as CGMS project.  Above is the device with it's charging stand.  Completely removed the phone component.  Added all the calibration functionality to my pebble.  Some screen shots from the emulator:

For calibration values, you can choose 80-190 in 10 mg/dl steps.  I also added a 15 minute snooze for alarms.  Entering anything is a two step process to avoid issues with accidentally pushing the buttons.  This will probably see more work, but for now, you click an action then scroll back to the top and choose Enter.  Finally broke my watch code up into libraries, much happier with it now, and it's easier to maintain.  Maybe I'll let my iOS developer license lapse now.  I really dislike xCode, I spend more time proving to it that I'm an authorized developer, than I do coding.

For the circuit, I realized I was better off with the Wixel, since it handles running it's radio and a 115k Serial connection.  Almost no room for a program on the Wixel, but I only had to cram in a function to blast out 2 packets to the pebble every 5 minutes.

A picture of the packed circuit board:

I'm very happy with this.  I no longer have to keep track of the phone.  Also both the boards I'm using are pretty awesome at their jobs.  The Bluetooth board easily covers the house, and pairing is automatic, handled by firmware.  No more disconnects from blocking the device.  The Wixel is also much better at pulling in signals than my CC2500 devices.

I did the PCB on a CNC router this time.  Just barely worked, luckily this is a simple circuit.  I should be able to do better on the next PCB I route.

One downside for now, is I can only get the Classic Pebble and Pebble Steel to pair.  There is something different with the Pebble Time and what it expects for Pairing.  There are quite a few parameters for the RN41 so I have a few other options to explore.  On the upside, while the Classic is fairly ugly, it has nearly a 5 day battery life.

Saturday, December 19, 2015

Pebble Battles

I was hoping to get allot of programming done on my Pebble yesterday.  Not so.

I left off Thursday with a working app, started up Friday morning to this.  It's telling me that pebble.h doesn't exist.  Sort of a fundamental problem.  So I scour the internets to see what's going on, nothing.  Send an email to support, then consider my options.

The last time CouldPebble was down I developed on my Mac, so back to that.  Fumble around for a while, it's been almost a year.  Load app on my watch, mistakenly putting it on the one I'm wearing, and not the development model...  App doesn't work.  Try to load onto my original pebble, just get this message "Couldn't install app".  Dead.  Nothing.  Try app in emulator, works fine.

After an hour or two of this, I notice that pebble is on a new SDK release.  Start fiddling around with the command line:
->pebble sdk list

Tells me I'm on 3.8.1.   Hmm, lets try 3.7.
->pebble sdk install 3.7
->pebble activate 3.7

I like the way you can easily switch and install SDK's, beats the hell out of Java and hunting around for the correct version.
Then build, install and success!  Most of my day is gone, but the watches are back to working.
As of today, CloudPebble is still wasted.  I really liked this tool, and the mbed site as well, good for casual use I suppose.  Looks like I'm officially done with CloudPebble for development.

Thursday, December 17, 2015

Working Prototype

Bread boarded and working.
Now to get this on a PCB, and figure out what kind of battery I'm going to need.

Final build:
- BLE Nano
- Sparkfun Bluetooth Mate Gold
- Teensy 3.1
- A couple of discrete components so I can control the Bluetooth Mate

The Nano, like the RFDuino, can't run at 115k with the radio on, so I have to have the Teensy around to coordinate everything.
Cool thing with the nano, is I have it in Central Mode.  My CGMS devices pair directly with this if the phone isn't available.

So it's:
Sensor->CGMS->iPhone-> Watch


Sensor->CGMS->"The new device"->Watch

Also this device will pair and/or wait to pair for as long as it has power.  No issues with something shutting down the "process" like the iPhone does if the BLE connection has been idle for more than a few minutes.

Thursday, December 10, 2015

More on Pebble

Connecting an Arduino to a Pebble.

I'm using a sparkfun, bluetooth mate, GOLD.  I don't believe the Silver will work.  A big issue with this process is what type of bluetooth dongle you have, I'm sure they all work differently.

The guy here:, has some basic working(for him) code.  What's left out, is the initial pairing.  With the Mate, you are better off not trying to control it programatically.  After many hours, it just doesn't seem consistent and tends to be unresponsive.  It is meant to be configured over serial from a lengthy command set.  Most of the settings don't appear to "take" until you reboot the device, and just power cycling may blow them away.  Also, some important settings don't persist.  The big one that comes to mind is baudrate, so assume you are going to be at 115200.

Before you do anything with the arduino, configure the Mate, you aren't done until the Mate stops flashing red and the green light stays on, indicating you are paired.  From that point forward, the mate should automatically pair with the pebble until the end of time (although it may take as long as a minute, or never)...

The commands you should send to the Mate:
SF,1         //factory reset
SP,9999   //takes care of the pairing code
SM,6        //pairing
SY,0000   //power
SW,0640  //sniff mode
R,1            //reset so settings are saved/active and pebble should ask to connect

Once the light hits green, pairing with the watch will take place, the first time the watch will ask, any time after that it will be silent.  The watch will send you a version request.  You need to send two packets in reply, screw this up and the watch will just ignore you.

I send:
//          //phone version
{0x00, 0x02, 0x00, 0x30, 0xff, 0x08};

Followed 100ms later with:
//                                  0x11 = 17 = Phone Version endpoint
//                                             phone version
//                                                        remote capabilities  Telephony.SMS.Android
//                                                                                              //session capabilities............
{0x00, 0x0d, 0x00, 0x11, 0x02, 0xff, 0xff, 0xff, 0xff, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x32};

You shouldn't send the above again, unless you "forget" the bluetooth device from your watch.

Once that's complete you can ping the watch:
//                    endpoint
//                    2001=ping
{0x00, 0x05, 0x07, 0xd1, 0x00, 0xde, 0xad, 0xbe, 0xef};

Send a notification:
//this says BG 115  
//                                                                       B      G                   1        1         5
 {0x00, 0x1A, 0x0B, 0xB8 , 0x01 , 0x02, 0x42, 0x47, 0x03 , 0x31 , 0x31 , 0x35, 0x11, 0xFF, 0xFF , 0xFF , 0xFF , 0xFF, 0xFF, 0xFF, 0xFF , 0xFF , 0xFF, 0xFF, 0xFF , 0xFF, 0xFF , 0xFF , 0xFF, 0xFF};

Note: the above packet has a header and body.  The header is 2 bytes and says "BG".  The body is 3 bytes and says "115".  The 0x11, signifies 17 bytes until the end of the message.

Or, and this is the big one, send an application message.
For this one you need the UUID of the app, which you can see in Cloud Pebble.

With that, I can send an integer value of 120 to the first element(tuple?) in my applications dictionary.
//app messages to uuid, glucoseKey
//001b 0030 0100 7f7a38901a1c43a3adf121449e4f352d 040100 0000 03:01:00:78
//msg  app    push UUID................................................... key                     len      120
//         msg                                                                                                int (0x03)
//                                                                                               dict element (0x01)

I may have to update this one.

Can't use the RFDuino.  Number of serial ports is one issue, the bigger one though is you can't run the Radio and Serial at 115200, 9600 works, but 115200 will cause the app to hang.

Turning one off and the other on, also doesn't work, doing a Serial.end / Serial.begin appears to glitch the serial line to the mate and causes it to disconnect.

It looks like this project will be continuing with a Teensy.  One serial for debug, the second for the Mate, SPI for the CC2500, maybe a third serial to run an RFDuino if I want BLE.

See github ( for a working sample.