Facilities, Virtual and Otherwise

I've often moaned in these electronic pages about the inefficiency of my current facilities; despite seeming, on the surface, to be a sort of geek paradise (3000 square-foot lab in the woods), the reality borders on absurdity. With the boat a 3-hour round-trip drive away, the rhythm of the project is the precise antithesis of the Deep Immersion that is required... I work in burst mode, make lists of what to bring next time, and constantly need whatever isn't where I happen to be.

Last week was a good example. With a few things rising in the queue to a level of urgency, we drove over to the boat, gave her a once-over, and dove into a couple of tasks... Number One confirming the templates for magnetically attached reversible curtains, the Captain deploying a hole saw on the picnic table to install Wema sensors in the access plates on the wing tanks:


So far, so good. But the sensors needed to be cabled with fresh stuff since the old connections were inaccessible, so that went on the "next visit" list. I fiddled around a bit with some of the other upcoming projects, made some notes, did a bit of online research, and vowed to get more done next time. Back on the road, another week gone by.

This is not very efficient, especially as I get into the deeply interactive projects that will require continuous movement between lab and boat. Actually, the on-board facilities are not bad... I rarely lack for a tool, and the stainless fastener inventory now reflects general consumption well enough that I can usually find what I need. But big projects are looming: waterworks installation, the new console, Outback power management system and new battery bank, binnacle nav station, solar array, redneck bow thruster, new water heater (the old one just moved to Reno via eBay), a dozen or more distributed nodes with associated sensors, and a few other things.

At the current rate, this will take until well after the end of the Mayan calendar, which is not quick enough.

So another little side project has been added to an already insane workload... finding a new home base.

Yah, I know.

Actually, if done within the budget of the existing one (since a mortgage banker would chuckle heartily while hustling me out the door), this could actually lower operating costs by eliminating monthly moorage fees while significantly increasing operating efficiency. All I need to do is trade 11 acres in the woods for about 2 on the water (with suitable lab space), then make a quick lateral move. <cough> Sounds sane in principle, but it is fraught with peril in this broken economy and I find the prospect at once enchanting and terrifying. We've been looking, though, and it is a long shot but not impossible.

Of course, what that means is that I'd really enjoy hearing from someone who is currently on a quest for this flavor of "home" so we can make the transition to that one. Need an unusual bit of forested real estate with a shop that's three times the size of the house? Here are some photos.

The Nomadic Research Labs Emporium

Moving into the domain of unreal estate, my online store is now a reality! Learning curves have been steep (and are certainly not over); the past week has seen Zen Cart installation and configuration, beating my head against the wall over download-server issues only to eventually uncover a directory permissions error (always the culprit, it seems, and thanks to the Zen Cart forum for spotting the bug), getting the SSL certificate, making the link to PayPal IPN, adding a little scattering of products, making a test sale to Sky so I could watch it all work, corresponding with vendors, planning the PDF monograph series, setting up the USPS API to automate shipping calculations, and otherwise doing everything other than actually making sales. Of course, it's only been about 3 days, and the shelves are kind of bare, so I'm not panicking just yet.

The design is primitive, just the default template with minor changes:


Once it has been running for a while and I'm less intimidated by the thousands of knobs on the back of the set, I'll work on making it more beautiful... but for now, the important thing is getting a good range of products online. It's shaping up to be an interesting mix: documentation and kits for my own designs, off-the-shelf geeky boat gadgets, NMEA2000 cabling and sensors, APRS trackers, GPS dataloggers, Arduino stuff, prototyping goodies, general electronic kits/parts/tools, LED cabin lighting, networked video security systems, fabric products, books, favorite nautical toys, embedded Linux boxes, and surplus from the Microship lab.

Though this sometimes feels like a bit of a distraction from the central task at hand, it's actually a business model that has worked for me in the past: focus on my geek projects while being a silicon-pusher on the side and documenting the gonzo engineering via magazine articles and books. The tools have changed a lot since the '70s, of course, but the basic trinity is identical and very familiar. It's also scalable in the sense that I can continue writing from the boat, and after departure the store can be operated by one or more employees (assuming some cash flow...).

Starting a business in this economic climate does seem a bit mad, but startup is incremental and the whole thing boils down to a DIY-focus... which reduces costs for people. My initial list of 15-20 technical monographs is about 50% how-to material (with the other half focused on gizmologically intensive projects of more limited appeal). If I can save a few folks from the annoyance of paying big bucks for work they can do themselves, then we all win (except, perhaps, for the people doing said work, but it's hard to feel too guilty about that after my recent experiences with plumbing and hydraulics). There's still plenty of room for hired specialists and true artisans, but a surprising number of boatfolk seem to assume that anything even remotely technical requires paying hourly wages to an installer.

This gets fun in the context of the new store, since my intent is for it to grow well past the geeky little niches in which I happen to be comfortable. There is a wide range of expertise out there, and one featured product category is a library of downloadable documents... some by me, and others produced in partnership with experts in various fields. It might introduce occasional editing and production-values issues, but the plan is to invite anyone with clear knowledge of a boat-related technical task to write it up and let me add it to the collection.

If this triggers a little "aha!" moment, please get in touch and we'll talk. I'm guessing it will be a 50-50 split of the proceeds, and once there is a critical mass of material "in stock" to justify linkage, I will put some marketing effort into building traffic. Have you solved a mechanical or electronic problem, done a complex installation, learned the details of a product, invented a new tool, reverse-engineered an older system, eliminated RFI, or otherwise accumulated some boat-related technical wisdom that others might pay the equivalent of a couple of beers to read about? Can you express it clearly, with sketches and photos as needed? If so, drop me a line, and let's turn it into a nickel-generator.

(Hats off to Don Lancaster for that eternally useful turn of phrase, first used in his classic Incredible Secret Money Machine.)

Brief Project Updates

While all that has been going on, I have not been ignoring the ship. In addition to the long-awaited completion of diesel-sensor installation, I've gotten Node S happily blinking in the lab (viewable via a network serial server), made progress with my fabrics consultants on some very cool curtains, edged closer to console fabrication with specs on the hardware, watched a few more things head off to new homes (the last 30 days of which are always logged here), gotten Satie's Gnossienne No. 1 under my fingers and started No. 3 whilst eying the tasty No. 4, and designed the 'HC595 driver architecture for a huge mat of latching relays.

The fun never ends at Nomadic Research Labs...

Cheers,
Steve

The First Node Flickers to Life

It's a humble little thing, this microprocessor that will spend its days tucked away under the forward berth, tirelessly keeping an eye on such mundane matters as the amount of sewage in the holding tank and the status of associated valves... and it probably doesn't deserve all this bloggage. But the Sewage node has some meta-value that makes it a bit more significant.

I deliberately chose this important-but-simple application to use as a development context, not only to bring my somewhat rusty skills back online, but also to establish the tools and standards that will apply across the ship network of about 15 nodes. It wouldn't do to get bogged down in tricky algorithms whilst trying to nail basic protocols.

In the previous update, I introduced the "busy boxes" and showed the front panel of this one; cobbled together from junk lying around the lab, it provides a somewhat realistic test environment that includes three valves, a bilge float switch, interface with a commercial tank level sensor, a couple of 12-volt events reflecting macerator pump activity, the diaphragm head pump, and a loud warning alarm. The Arduino boards make interface very easy; looking at a reed switch, for example, involves nothing more than a ground on one side and a series resistor just to play it safe if I accidentally define the pin as an output, with an internal pullup taking the input high unless the switch is closed by a nearby magnet.

Interface with 12-volt stuff is another matter; I decided early on that there has to be absolute separation between all this logic-level stuff (tied with USB to the hub system) and anything connected to the ship's battery (pump circuits and the like). This naturally calls for optoisolators, which use a wee bit of light to transfer information between two electrically isolated domains.

Here's the back of the Node S busy box, now wired and ready for software development:


The Arduino with its little prototyping "shield" is in the middle, and the protoboard carries three optoisolators and a FET that drives the big backup beeper on the left. This may look like overkill, but a sailboat underway can be a very noisy environment and any alarm that might prevent a poop explosion needs to be heard now. (This is a general network resource as well; it is primarily invoked by local logic in the node, but can also be triggered by software upstream in situations where the context would be clear.) The thin red/white pair going to that old terminal strip carries 12 volts; the tan cable is USB from the Mac.

Naturally, the ugly hardware you see here is not what goes on the boat... it's just a test bed. The protoboard goes away and gets replaced by soldered-in parts, with the node tucked into a sealed box; the rest is there to simulate the actual environment, increasing the odds that code I write now will have a good chance of "just working" when installed.

Once all this was wired and tested (read each switch and write the value to an LED), it was time to put it on the shelf in the "ship simulator" area and start the software. It's a pretty simple loop:

• Update all the variables by reading associated I/O pins
• Do macerator pump logic to warn against operation without valves open, such as:
  if (pumpBreaker && !(dumpValve && ventValve)) {
  digitalWrite(cautionLED, HIGH);
  }
  else {
  digitalWrite(cautionLED, LOW);
  }
  
• Test tank level every 10 minutes or so; count head-pump cycles
• OK LED blink timing
  
• Check for a message from the hub, and respond if so with a dump of key-value pairs, alarms, metadata about local variables, or node ID

Local information such as pin names is kept hidden, and sensor values are passed upstream with the understanding that they will be paired with the node ID and inserted into a global database. The node itself does the "engineering unit conversions," trivial in this case, that create a separation between hardware-specific data and values that have meaning in the big picture (the difference between whether a reed switch is closed and the status of the corresponding valve; at the server end, I don't care about the sensor, I just want to know the state of the thing it's observing).

I'm finding the Arduino development tools quite easy, and the dialect of C is comfortable and well-integrated into the target environment. I/O is expressed with pin numbers instead of masking port bits, and the edit-compile-debug cycle is very fast. It works beautifully on the Mac, which is what stopped me a few times in the past from diving into popular embedded micro flavors.

Let the fun begin!

Chicken of the VNC

Last night, I was just getting into the software out in the lab... a 3,000 square-foot building located 750 feet from my house, deep in the cold dark forest. Sky somewhat plaintively emailed that dinner was fragrantly underway and that the music was sweet. Knowing how insidiously software can gobble the hours, I thought it would be a good time to try remoting the whole process.

The Arduino bootloader is handy in the sense that it automatically resets the board after the latest hex file is uploaded, so no physical presence is required. Although I wouldn't be able to manipulate any switches or valves, I could at least watch the Node S Busy Box over the LAN... so I set up the iSight camera with the excellent EvoCam server.

The compiler has to be local, of course, as it uses USB to talk to the node, and while there is probably a tres-geeky way to do that over the network, all I really needed was screen sharing. I turned that on in the system prefs, then installed Chicken of the VNC on the laptop. This lets me interact with the iMac screen from the MacBook, and is surprisingly brisk.

Of course, 750 feet of forest is not so good for 2.4 GHz wireless connectivity, but we solved that problem a few years ago with a back-to-back pair of SpeedStream 5851 SDSL routers that are set up to bridge the two LANs. The wiring itself is just a pair in one of the three 10-conductor direct-bury phone cables that we trenched when building the lab, and phone-grade wiring was used to connect from those to convenient mounting locations in the buildings. We see a steady 1.5 megabit/sec link over vanilla copper (which still amazes me, having grown up in an era where "3 kilocycle bandwidth" was taken as gospel where phone stuff was involved). The net effect, so to speak, is a bridge between the two LANs that maketh them to feel as one.

So, with all that in place, I left a little work light aimed at the node and padded back home through the woods, kicked off my shoes, settled into a chair by the woodstove, and flipped open the laptop to see this:


Ain't technology wonderful?

That window on the left is the Arduino development environment running in the lab; the one on the right is a local Firefox browser listening to the webcam server. I could interact fully with the code, click to install a new version, and watch the LEDs blink. This kept me happily hacking until well after bedtime.

The next step, once the little loop outlined above is complete, will be to start playing at the server end. Basically, the always-on hub will chat with the nodes on a round-robin basis, collecting updates on sensor values and noteworthy events, in the process building a current table that reflects the status of everything on the ship. This has a few clients, including security software, database, web server, and the subsystem that allows "back door" queries via DTMF/speech and other channels.

"There is nothing - absolutely nothing - half so much worth doing as simply messing about in boats."

-Steve