Thursday, December 11, 2014

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.

Tuesday, November 25, 2014

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.


Friday, November 7, 2014

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.

Friday, October 24, 2014

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.

Saturday, October 4, 2014

Thursday, May 22, 2014

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.


Wednesday, May 21, 2014

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...