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 pull-up 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 opto-isolators 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