FPGA Shield

Anson's birth day story

A bunch of folks have asked about how our labor went, so I thought I'd give a thumbnail sketch of our evening.  If you're squeamish about bodily fluids and anatomy, suffice it to say that "we now have a son and we're both very happy."  For those who want the blow-by-blow, read on.

Jennifer's had some "bowel discomfort" for the last week.  Yesterday about 2:00 she had some pains, but she just thought it was intestinal junk.  So she kept doing her thing.  Last night about 9:45 we sat down to play a board game with Janine, her sister.  Jennifer was grumbly.  Around 10:30 she left the table to go take a bath and go to bed.  She was pretty sure she was having contractions at that point.  I went up to check on her at 11:30, at which point she was lying on her side, curled up on the bed.  She yelled something at me like "EVERY 5 MINUTES, 20 SECONDS"  I timed her next contraction and it was 1:06.  She got back in the bathtub while Janine and I packed and I called our birth partner and the hospital.

We hopped in the car and drove to OHSU with Jennifer going through transition.  For most of the trip her contractions were 3 minutes apart, so when we arrived the hospital staff whisked her past triage, straight into a delivery room.  About 5 minutes after we arrived, Jennifer's water broke, and maybe 3 minutes after that, the Nurse Midwife walked in.  "Yep, 10 cm.  Do what feels natural."  So Jennifer pushed, Janine and I caught, and a little less than an hour later I had a son.

All in all it was a pretty straightforward delivery.  Jennifer did experience some tearing that required stitches.  She also ended up with a good-sized hematoma, and passed a 300+ gram blood clot this morning.  She's since stabilized some more, has gotten some sleep, and is in generally good spirits.

As for Anson, he's been pretty cheery, all things considered.  He's successfully nursed a few times, but is generally more interested in breast-as-pillow than breast-as-dinner.  He does turn a delightful shade of red when he's mad.  His Apgar scores were 9s (fine), and somehow the pediatricians managed to come around during an uncharacteristically alert period and were complimentary.

Help is on the way...eventually.

So today I found myself needing to convert some plots from HPGL to something more useful, like PNG, for inclusion in a report. I turned to an old utility that I've used a bunch in the past, HP2XX, to do the conversion. Having long since lost the batch file that I used to insulate myself from its arcane argument structure, I set about learning the arguments over again. Trying to find the help file (see screen cap) caused me to think of the following:

I think the Open Source movement needs its own Clippy. It could be a sloth that looks at its shoes and mumbles while it's talking to you.

"Looks like you're using a GNUWin program, HP2XX. You don't want any documentation, do you?"
"Christ yes, I forgot what the fifteenth command line switch does."
"What program do you want documentation for?"
"Uh...HP2XX."
"What version?"
"Let's try the only one I have, 3.4.4."
"You mean you want documentation for HP2XX version 3.4.4?"
"Yes!!"

I'm just glad I didn't have to download a LaTeX viewer to read it.

Sensor network bridge

So I've got all these little wireless gadgets...low datarate things like thermometers and humidity sensors. Maybe motion detectors or something goofy like that. Probably connected by Zigbee or some proprietary standard. It's not really viable to have those directly connected to the Internet. To do that you'd have to have cellular or WLAN or something else involving a nontrivial network stack.

So we make a box that works like your Kindle. It's on the Internet, and you don't care how. It's transparent. That box acts as a bridge to your low-power, low-datarate wireless network. So at the other end of that box's 'net connection is a server, which could well be EC2-based. That server provides a few things. The first is a web-based interface to your net. You can look at information real-time, or send stuff. Whatever. The second is a logging function, with pay-by-the-byte storage. Basically subletting your S3 space. The third is an API that allows you to send data from your PC to your devices via the 'net so that you can write your own apps. The last is a driver that runs on the PC and abstracts the API, presenting it as a series of virtual serial ports on your PC. This is for folks who don't even want to bother writing software to talk to the 'net. They'd rather just talk to a "serial port". You could also use a terminal program like HyperTerm to chat with your devices.

...And there's no reason you couldn't do the same thing with WLAN and leverage some existing site infrastructure. The only problem there is that there'd be some configuration of the bridge because there's no real standard for self-configuration of WLAN. I mean, you could search for any open access point and try to grab an IP from it, but that's a long shot. The beauty of the other bridge is that it's basically a box with a power hole that you put somewhere central. There's a power LED and that's it. No UI whatsoever. Since it's transparently connected to the server, all configuration happens through that route...you get a control panel through the main server that configures your box.

Another idea: have a sandbox controller on the thing that allows the system to act locally as well. Say you have an RFID reader and a light switch. One could talk to the other through the hub without intervention via the net. You could download micro code via the main server.

And another...rather than being tied to a particular wireless technology, just have a hole in the bridge that allows you to plug in a Zigbee, Wibree, Bluetooth, Cypress, or Nordic radio module, all of which would be abstracted to use a common interface. Worst case the radio module would have to have an EEPROM on it that has special code that gets loaded into the bridge at runtime. Well, boot time.