Sunday, April 20, 2014

Personal UV Sensor reboot

Back in 2011 one of my CFT projects was to develop a personal UV sensor for those who are a high risk for skin cancer.  Due to the limited availability of tuned UV sensors (i.e. a reliable source for UV Index rating values), I had to abandon the project. I produced one prototype, as outlined here: http://toddbot.blogspot.com/2011/08/uv-index-monitor-prototype-1.html but had to put further prototypes on hold due to  sensor procurement issues.

Well, apparently there is a rumor that the forthcoming Apple iWatch will include a UV sensor ( http://www.macrumors.com/2014/04/08/iwatch-uv-light-exposure-sensor/).  This is great if you have an iPhone, lots of money and want a new watch, but this isn't my target.

But, the new UV chip they are using, fits my budget: http://www.silabs.com/Support%20Documents/TechnicalDocs/Si1132.pdf.

I want something small (and cheap) enough that you could clip it to a hat, a UV windbreaker, shirt or blouse. Oh, and it should be water resistant (wear it on the beach or by the side of the pool) or even water proof (go swimming with it on).  It should also allow you to set a timer (in hour increments) to remind you (via beeping) to apply more suntan lotion.

The only UI would be a capacitive touch sensor. Press to see (or hear through beeps) the current UV index. Press to set timer.  LEDs (matching UV Index official colors) and/or small buzzer would be the feedback mechanism.  It should cost under $20 and the battery should last a few years (at least 5) under moderate UI usage.

Why do this?  Well, why is every (new to market) useful sensor device required to work with RF and/or interface with your phone?  Why can't tech just "be there" when you need it, rather than be "gadgets" that work with other "gadgets".

Heck, give me a 10 year battery life and I'd say you just sew the thing into clothing.

Okay, I've said way too much.  Let's just say that I am working on it.... stay tuned.


Tuesday, April 01, 2014

Teaching Forth Programming to kids... is really dangerous...

Teaching Forth Programming to kids is irresponsible and may hinder their progression into the professional programming industry.

So, let's do it.
One rather curious thing I've noticed about aesthetic satisfaction is that our pleasure is significantly enhanced when we accomplish something with limited tools.   - Donald Knuth, Computer Programming as an Art 

Forth doesn't have a lot of modern facilities, but that forces you to figure them out yourself.  Better yet, Forth encourages that you solve the problem at hand (rather than build elaborate frameworks).

I've been called out, in this blog somewhere, for promoting archaic old principles that don't apply to modern development.  But, I don't actually want to force people to learn this stuff. Find your tool and if it helps you do amazing things, stick with it.  

I've been programming in Forth since 1984.  I've learned a dozen languages since.  Forth is still the one that focuses my attention on problem solving better than any other.

Why am I writing this now?  I'm a bit late, but I just discovered this: Gforth for Google Chrome.

It's a toy right now (apparently no persistent file I/O), but I want it to be real.  I want to fire this up in a classroom full of kids and get them hacking.  I want them to build their own abstractions. I want them to see what middleware really is (a bunch of layered restrictions with the goal of making things more structured and easy, while in reality making you conform to things they want to keep hidden -- okay a rant for another day).

Sure, underneath Gforth for Google Chrome there are layers upon layers.  But there is a lesson there too: Its all about simulation.  It's Turing machines all the way down.