Nomadness Report – Issue 3

Our brief introduction to Shacktopus last week set the stage for something more substantial. We have discussed why it might be interesting to scatter data-collection nodes around a sailboat… but how do we intend to do it? And what do all those nodes (the pink diamonds in the image above) actually do? This issue is devoted to this sprawling system.

We have a few other special issues coming up, including one on GPS tracking tools, one on the mobile lab that let me deploy a robust development facility close to the boat, and another on amateur radio applications aboard. Meanwhile, the projects are underway… we’re not going to run out of material!

NOTE: The full collection of 22 issues is available as a 196-page Nomadness Report PDF from our online store. 

by Steven K. Roberts
May 10, 2011

Shacktopus Introduction

Last week’s brief discussion mentioned bringing diverse objects under the umbrella of a single user interface, then described the architecture as a central database and a collection of nodes. I even included the architecture drawing to convey a sense of scale.

Armed with that, we can look more closely at how this is intended to be used… and why it’s relevant. My intent is for this issue of The Nomadness Report to provide a broad understanding of this system; future issues will be much more focused on individual components, and will refer back to this for context.

Only a small part of all this is dedicated to direct control of the boat systems; from a seamanship perspective, one might question the wisdom of adding potentially fragile layers to systems that need to be highly reliable. Indeed, most safety-critical systems operate entirely independently of Shacktopus: I throw a switch to turn on navigation lights, turn a knob to select VHF channel 16, and pull strings to control the sails.

But that’s not what this is about. A modern voyaging vessel is an insanely complex collection of systems, including engines, plumbing, power, comms, and more. Unless one obsessively stays on top of everything (impractical), on-board “situation awareness” can easily drift out of synch with reality. Important procedures are forgotten, maintenance intervals slide, and issues can develop that have serious implications. This has happened to me many times.

My solution calls for a suite of sensors, a historical database that logs channels at appropriate intervals, and a few software tools to wrap it all in a layer of abstraction.

• Is the diesel fuel in the starboard tank below the sip tube for the Webasto heater?
• Does the temperature profile across the main engine heat exchanger suggest a blockage that may indicate impeller failure?
• Is one of the solar panels giving less and less output as time goes on, suggesting water incursion or other slow failure?
• Is my anchor light drawing current when I turn it on?
• Has the bilge pump cycled in my absence?
• Can we fine-tune mental “polars” on the boat by observing true wind, accelerometer data, and autopilot performance?
• Is someone trying to pump the holding tank without opening the vent stopcock, setting the stage for a poop implosion?
• Are there any anomalies in the sensor array that warrant a stop at the nearest starbase?
• Do filters need changing?
• Are there phantom loads increasing quiescent current?

I could go on and on.  I want to know these things when aboard, be notified of developing problems, and feel secure in the knowledge that a tireless watchman is keeping an eye on security and systems. I want a full-system control & monitoring interface at my fingertips, on or off the boat. I want to be walking on shore, and even without Internet connectivity be able to transmit a status request via waterproof ham-radio hand-held rig and get a spoken response.

If designed wisely, this will scale well. Some interfaces are standardized (NMEA2000); others, like an array of valves, require proximity sensors and a local microprocessor. Coupled with the more active tasks (resource and configuration management with a crossbar switch matrix, power control with solid-state relays, direct involvement in networking and radio communications), the obvious toolset is an I/O rich, power-efficient server and a distributed network of microcontrollers.

The system architecture is significantly shaped by a few tools.  The always-on machine will probably be an embedded Linux single-board computer, though all development is taking place in a Mac Mini… and frankly, I’d be happiest leaving that in place down the road even if there is an extra power cost. It’s just easier.

The front-end software will be implemented in DataPrism, a very cool (and yet little-known) system that allows active objects to run in a browser. The associated SQL database can also be used to archive hundreds of data points and events, which is a key requirement.  We will also need a few autonomous programs to take care of security, watch functions, alarm monitoring, and an interactive “back door” that includes both DTMF/voice and packet datacomm via ham radio… allowing access from a waterproof UHF rig or minimal computing hardware.

Of course, Macs don’t have ports for all the sensors… so interconnection with the boat is a mix of USB I/O modules, sources that continuously feed data from other systems (NMEA2000, Outback power, and Carnetix), and about a dozen Arduino nodes scattered from bow to stern.

Let’s elaborate on the server software, then look at those nodes a little more closely… that’s where a lot of the fun will be.

Primary Server Tasks

DataPrism

Basically, this is a database-backed server that connects physical (or virtual) devices to corresponding live objects on a web page, giving us a dynamic set of tools for interacting with the boat.  Without it, we would be limited to HTML page-refreshing augmented by various kluges for animation within sandboxes (assuming that we wish to keep the user interface in a browser, which is desirable for lots of reasons including the use of off-the-shelf smart phones, iPads, and remote laptops).

DataPrism is described as “A visual, object-oriented application platform for authoring and deploying rich networked solutions in web browsers, locally and through the cloud.” This translates into something very smooth and beautiful, feeling more like a dedicated application than pages you’d find at a website. It plays nice with Perl and other standard development tools, so stitching it together with the rest of the system should not bog us down in epic software projects.

Datawake

An important information source in the system is historical, and we thus need to selectively database many of the sensor channels. The challenge is that some need high sampling rate and some low; others are only interesting as events; still others may be annotations or other data that doesn’t even have a hardware counterpart. 

All this calls for a flexible system (with metadata) for stuffing time-stamped entries into a database that is then accessible to DataPrism (as when observing historical solar panel performance or trying to debug an engine issue by looking at the last few dozen hours of logged temperatures and RPM).  The Datawake term stems from my earlier project that postulated a wake of data streaming behind the boat, and it has environmental monitoring components that make it interesting to others (indeed, this led to a contract with the National Science Foundation a few years ago to produce a field data collection system called WANDER – a project I shared with Ned Konz and Tim Nolan).

A filter will be in place that allows a lower-resolution version to be mirrored on a public server as part of our expedition web presence.

Back Door

In addition to the browser-centric user interface, the system has two methods for handling queries. The first and easiest is a simple text interface over a serial port, using packet radio via a dedicated 2-meter transceiver and TNC.

The second is highly useful, and takes a few forms.  The output is a V-stamp speech synthesizer, which is steered via audio crossbar to a UHF transmitter, local audio in the cabin, cellular phone, recording interface, loud hailer, or whatever.  The input is nominally a DTMF decoder that receives Touch-tone transmissions from a small UHF ham radio, but this same alphanumeric “instruction set” is accessible via keypads on the boat (or at least one in the console, next to the server board).  This allows simple commands with voice response when conditions don’t permit the luxury of a browser (or exposing delicate electronics), and it can also work via telephone using the boat’s embedded cell number.  This will make it easy to check for alarms, request summary of any subset of data points (power, security, weather, etc), enable remote-control functions (turn on spreader and cockpit lights), do a demo for the media as I did with the bike speech system, etc.  Given this functionality, it’s a small leap to automated emergency transmissions with sufficient interlocks.

I’ve already written a basic command language for this, and it may be one of the first tools to come online once the server goes live.

Dog Watch

This is a loose name for a subsystem that is used for security monitoring and general watch operations… staying alert for error conditions (excess wood stove stack temp), human oversight (propane solenoid still on after stove is off), safety sensors (CO/smoke/fire/propane), and the security system (perimeter and PIR sensors).  Given the changing parameters and relevance of sensor data in different situations, it will take the form of an editable matrix.  All the current sensor data is present in a data structure, so this looks at that, applies a few tests, then either logs an event or takes some kind of specified action based on current activity (local voice annunciation, indicator lights, displays, radio transmissions, email, voicemail, text messaging, alarm sounds, etc).

Utility

Of course, this always-on machine will also provide the basic computing toolset that we’ve come to expect to have at hand aboard ship: email, web browsing, documentation archive, databases, navigation, music, and so on.

Streams and Nodes

At its heart, this whole system is about the relationship between a very diverse range of data and the humans who live with it.  As such, a huge part of the development will be focused on data collection, with the current snapshot of the entire Nomadness environment always available as a hash or other entity (and the history in a database).

In this final section, I’ll breeze through the nodes and other data sources, giving you a quick introduction to each. This is our first look at this entire set of sub-projects, which will be keeping us amused as the months pass.

I have these loosely grouped in three broad categories:

• Streams are situations where I’ll be sipping from the firehose of data from some other system that doesn’t care whether or not I exist.
• Nodes are generally based on the Arduino microcontroller board, and are much more civilized because I’m writing the code. They respond politely to queries, and can also perform local control tasks.
• Random Devices add to the capabilities of Shacktopus, but don’t fit into the previous two categories.

Streams

NMEA 2000

The navigation system aboard Nomadness is already in place, and depends heavily on this increasingly familiar marine networking standard that is layered atop CANbus.  We have a Maretron USB100 which purports to be a USB gateway from the N2K world, though it is only sold with Windows support.  I am assuming that this is just a driver issue and is a soluble problem; if not, we’ll have to roll our own or (preferably) leverage work done by others trying to break the industry stranglehold on the standard. (Note from a decade later – yes, things have changed a LOT)

In any case, this will look like a continuous stream of PGNs (numbered data points) and associated values. If we do end up with a more intelligent gateway, then it can be a bit better-behaved and respond to queries.  But the default right now looks like an endless torrent of data reflecting activity around the boat that includes rudder angle, autopilot data, compass heading, GPS coordinates, roll/pitch data from the rate gyro, fuel tank levels as described in Issue #2, wind information, derived nav data when under chart plotter control, and other related points.

Outback

This is the ship’s power management system, which includes an inverter/charger, solar charge controller, and the company’s FlexNet DC monitoring device that reads shunt currents.  The front end of this is called the MATE, and it has a simple ASCII serial protocol that dumps three data blocks once a second (one each for the inverter/charger, solar controller, and monitor). This is well-documented, and like the NMEA2000 feed, is a steady stream into a serial port.  Hopefully we can parse this and throttle it back without having to add external hardware, though they have just released the new MATE3 that might solve this problem while adding lots of additional capabilities. At the moment, according to company documentation, Ethernet and streaming are not yet implemented… so I’ll develop around the familiar MATE that’s currently in use.

Carnetix

The DC-DC converter that runs the Mac Mini is made by Carnetix, and it provides a small dataset via USB that includes its output voltages, currents, and temperature.  This is not highly critical, but we do want to keep an eye on it and do a bit of datalogging.

Nodes

Next up, we look at the Arduino-based nodes scattered around the boat. These are all designed here, and respond only when queried… making interaction much more relaxed.  Interface in all cases is either USB or serial (in the latter case, the nodes need to be locally powered, but can be further away from the hub without special USB range-extenders like the USB2ARC5M from B&B Electronics).  XBee wireless is also available in any case where cabling is a major issue, as on the dinghy.  All nodes have a smart status LED, though these can be suppressed under software control if they are annoying. These will be BlinkM units that can relay a lot more than a simple pattern without using CPU resources.

Sewage

This simple node (and the first one developed, already working on the bench) is located next to the forward holding tank, and performs a bit of trivial Boolean logic to sound a loud warning alarm if someone attempts to run the macerator pump without opening the thru-hull and the tank vent seacocks.  These, like all other valves on the boat, have their positions sensed with either a reed switch or Hall-effect sensor and a magnet on the tailpiece.  The node reports these as key-value pairs (HoldingVentValve=1), as well as the state of power to the pump, sink drain seacock, a nearby flooding sensor in the same compartment, Henderson manual pump cycles, and the rough level of contents in the holding tank (interfaced with a commercial device that uses proximity sensors).  All this can be integrated over time for better prediction about flushes remaining and usage efficiency.

The photo above shows the development “busy box” for this node… a kluged set of tools that allow easy simulation of sensors and other connected devices. Behind the panel is an Arduino, and it plugs into the Mac via USB.

Companionway

This node is involved with security and access control, as well as I/O related to the pod over the sliding hatch.  The area contains a few NMEA2000 devices (GPS, rate-gyro compass, and wireless base station for the autopilot), but also houses the APRS stand-alone tracker and a GPS datalogger.  This node switches their power and confirms operation by looking at the LEDs, and also owns a radiation monitor (RadAlert) with a pulse-count output. 

Security functions include access-control devices (keypad and RFID reader), hatch and companionway door sensors, and a PIR sensor for observing motion.  There is also an LED output for alarm status, blinking as in a car to convey the presence of a security system.  This node may also be the most convenient way to switch power to a small camera in the pod, and will pick up a few things that are just handily close (like the door sensor to the aft cabin).

Pedestal

The outside helm (steering station) is a nexus of user-interface devices, the most critical of which are the chart plotter, binnacle compass, and Icom Marine VHF remote mic.  None of these require any node support, though a security bit on the plotter might be a good idea.  I see this lightweight application as a set of convenience features – a serial LCD that presents alarm conditions (without requiring browser involvement), keypad that matches the DTMF/voice system command set, source-selection input for video piped to the multifunction display.  It’s also a good place for a man-overboard proximity sensor.

Arch

Located behind the helmsman, up on the radar arch, this node owns the stern of the boat. Solar array security loop, solar temperature, control of the cockpit LED floodlight, stern camera power, downward-facing PIR motion sensor to observe the stern boarding ladder, LED sternlight operation monitor, and environmental sensors.  This is also the best place to have an Xbee port for communication with the dinghy, to maximize range without needing anything more than the on-board antenna (a simple mesh network).

Dinghy

This node is in a very harsh environment, and also has more power and packaging challenges than the rest – it is located in one of the hatches of the dinghy.  (While on the davits, it should have a charge input, though we can’t depend on that since it can spend many days in the water.)  It’s largely for location tracking and security, with a sensor for the motor, a security loop, and an APRS tracker that is active when the dink is deployed.

Similar nodes may end up aboard the Hobie i12s and Pygmy kayaks…

Bow

At the other end of the boat, we have a fun one – embedded with a remote-controlled Golight Stryker searchlight with HID bulb, on which is mounted a sealed broadcast-quality video camera. This node takes care of position feedback, and parallels the stock motion control by hacking a second remote (the other is mounted at the outside steering station).  It controls camera power, has a forward-looking ultrasonic distance sensor, and a circuit for confirming operation of the bicolor LED navlight assembly. Finally, as we add the bow thruster, this node will be available for current-sensing, deployment mode, and whatever else becomes relevant.

Galley

This one is mostly about temperature sensing, and is close enough to the Hub that we might be able to use a National Instrument 6008 I/O module (though that adds complexity by requiring different drivers). In any case, we want to see temperatures around the stove, woodstove stack temp (thermocouple), fridge and freezer thermal profiling, status of the refrigeration systems (power and heat exchanger pump), status of the propane solenoid, and anything else that reflects the condition of heating and cooling systems.

Engine

There’s a lot of data down here, and it will take a node with I/O expansion to handle all the static input bits. One of the main applications is reflecting the fuel system on a distant graphic display; with 3 diesel tanks having both source and return valves, plus valves for the Racor filters and transfer pump, there are around a dozen magnetic sensors to check periodically.  (Fuel tank levels are measured by TLA100 modules on the N2K network, though we can observe their resistance for a bit of redundancy… but that’s over in the inside helm region.)  In the engine room, we will also want to see the position of the access hatches, raw water stopcock and tank-selection status.  These are input bits that don’t change often. 

More dynamically, we need to observe some key engine temperatures (block, a few spots on the heat exchanger, and two spots on the exhaust system), pick a tach pulse train off the prop shaft, note the bilge water depth and pump status, and probably a few other things I haven’t thought of yet.  We might be able to derive some additional engine data from a Maretron product that accepts the wiring harness (no intrinsic J1939), but that would not affect this node.  There is also at least one output bit – a “jog” for the Webasto heater diesel pump, necessary to bleed the system when it has sucked air. An engine room camera that can see filters is a good idea as well.

Helm

The inside steering station is a complex region, though the nav heavy lifting is handled by the N2K network or existing instruments (autopilot, charting software on the pivoting Mac screen, Furuno radar, engine controls, N2K display, hydraulic steering control).  A node here is auxiliary, presenting the same status LCD that is at the outside helm, observing tank sensor resistances, reporting access panel states, and so on. There is also another little keypad that echoes the command set of the DTMF/voice system.

Power Distribution

This is a busy one, and should not be confused with the feed that comes from the Outback system. The job of this node is to reflect the entire status of the ship’s power distribution system – all DC breakers, state of AC source selector switch, AC present, and anything else that can be glommed via optocouplers.  There is also some active intervention via SSR modules… whatever we decide needs to be optionally software controlled (in parallel with manual breakers) will need an output bit. A local LCD is probably wise here, and maybe this one should be the MAKE controller instead of the more anemic Arduino.

Midship

This is just a bunch of simple sensor bits, and is located behind the video screen in the lab region (fairly central). It reports the status of doors, drawers, and cabinets; bilge flood sensor, perimeter sensors from the deck, ambient temperature, local PIR motion detector, kayak security loops, deck box lid and internal temperature, monitoring the activity of the nearby Isotherm water heater, controlling the gear pump for the solar water heating loop, and so on.  Lots of trivial stuff, which together gives a good picture of human activity aboard.

Waterworks

This node should be a fun one; it is embedded in the fresh-water processing region on the wall of the aft head compartment. It knows the positions of all water-routing valves, and has a flow sensor at a choke point. A small display and keypad is used to report a maintenance activity like changing a filter, and this allows software to maintain accurate usage data to drive the PM schedule.  At the moment, the only water tank level sensors are pneumatic (Tank Tender), and if we’re good, we can use flow integration, pump and valve data, and other cues to maintain accurate level info (like coulomb-counting in a battery monitor). This node also owns the TDS meter and the reverse-osmosis desalinator.

Random Devices

Let’s look quickly at the other interfaces to this sprawling system (see why the name Shacktopus fits?)

Crossbar Network

This is a sparse-matrix, signal-agnostic network of latching relays controlled by SPI shift registers… about which MUCH more later. It connects anything to anything.

Communication Gear

The Icom M802 marine HF rig and the Kenwood D710A both provide considerable information on their serial ports (and are fully controllable).  This system will need to accommodate those, as well as interface with the PACTOR interface and other standalone systems in the console.

Router

It will be worthwhile for the system to periodically access the Cradlepoint router and get a log update.

Derived Data Points

Throughout the system there are “soft” data points that are the result of some computed state, human-entered values or commands, time-specific events, and so on.  These should be databased just like anything else.

Alternate Data Types

Finally, we should keep in mind that there are things like audio and video channels, textual annotations, and images.  These are very relevant, and need to be considered in any overall catalog of ship data points.  Some may even be databased, like time-stamped log entries or maintenance notes.

As you might imagine, this sprawling system involves quite a bit of planning and data management… it’s a challenge to maintain the consistency of namespace across multiple drawings, SQL tables, web objects, and software environments ranging from Arduino C to DataPrism and Perl. I’ve set up a FileMaker database to keep track of data points, and you can see one of the records here.

On with Development!

This issue has been uncharacteristically monolithic with one long and chewy article about the system, but it should be a handy reference as we move forward on more granular projects. We have now set the context for the entire ship network; at the moment, there is nothing in the domain of Nomadness geekery that hasn’t been at least prefaced here.

The immediate plan this week is to set up the development system and do the “hello, world” of data collection… in parallel with a few urgent mechanical projects. I ran out of room in this issue for the letters column, but I have one in the queue and welcome inquiries about the topics covered so far. 

Following are the two sidebars in this issue, moved to the bottom to avoid breaking up the article above.

Rope Tie: Instant Trucker’s Hitch

This is one of those “why didn’t I think of that?” items… making it easy to fixture a line under tension. These come in two sizes, and consist of a horn cleat and jam cleat (plus a little post to keep the line fully wrapped on the latter and an eye to keep it tethered). A loop through the horn fixes it to the standing part, and the bitter end is taken around whatever you’re trying to tension and cleated off. Quick and effective… I use two of these to hold my dinghy on the davits, then cinch it with a pair of stainless ratchet straps. The alternative all-line approach is more universal, but much harder to do on-the-fly.

Microship Flashback: The Video Turret

Speaking of nautical gizmology, this device was the result of over a man-year of work during the Microship project in the mid-1990s… and the complete design (including schematics and FORTH listings) is on my website. We used a 68HC11 board to steer a video camera in a sealed, pressurized enclosure… with UI tools written for a wireless Newton. I still have the machine here in the lab, but now that video cameras are cheap, it’s overkill… and may be repurposed to keep a WiFi beam aimed at a shoreside access point while I swing at anchor. Along with audio, video, and serial crossbars, this was one of the most successful student projects when I was teaching at UCSD. (The lead programmer, Nathan Parker, is now a senior software guy at Google.)