I spoke at the MicroHAMS conference in Redmond this past weekend… my first “gig” in quite a while. It went well, I met lots of interesting and creative digital radio geeks, and even managed to catch up a bit with some tech that I’m going to be using Real Soon Now.
Making a slide presentation for the event prompted me to stabilize the Nomadness network architecture enough to be able to discuss it comfortably. A half-dozen notebook sketches of varying quality morphed into a real architecture drawing, highlighting aspects of the design that were not really clear… but that I assumed would snap into focus someday. That day arrived in the form of a deadline.
Armed with my favorite drawing tool (the exquisite OmniGraffle Pro), I turned the past year of noodling into a high-level document that clearly expresses the Nomadness Shipnet. This will eventually find its way to the website as an image map, with each device supported by a block diagram at that level and further links to monographs of schematics and software. But for now, it’s a blogworthy introduction to this crazy nautical system I’m building:
Clicking the picture opens a large version in a new tab or window, which should make it easier to follow along as I describe the major features.
Internet and LAN
The upper left is the WAN/LAN zone… with the primary connection to the outside world (at least in populated areas) being an EVDO router augmented by the usual armamentarium of WiFi tools. At the moment I’m using a Top Global 6800 for this, but that will change to a Cradlepoint sometime soon. A Dynamic DNS account allows remote access to on-board servers.
The router, as in a typical home network, supports a wireless LAN for the laptops and other connected gadgets… the EyeFi SD card in my digital camera is happy here, and a friend who came aboard with an iPhone wondered aloud at seeing a hotspot in the middle of Puget Sound. This also supports the IP cameras, currently a couple of Axis 210 units with motion sensing and FTP, alarm-triggered events, and single in/out bits for sensing and remote lighting control. These will be augmented by a 4-port video server that can handle waterproof analog cameras for the brutal marine environment.
To the right of those is the Nav Station, a Mac Mini powered by a Carnetix P1900. I’m not yet sure what the display will be, but my current assumption is that this will be indoors in the pilothouse, with an “appliance chartplotter” at the outside helm. The Mac, of course, also takes care of the usual suite of productivity apps, assuming the operating position at the helm is comfy enough.
The system that will see most of the upcoming development effort is the box labeled “Linux Server,” an always-on network Hub with solid-state disk. This runs the ship’s database-backed web server, security/watch software, communication tools, and most of the other stuff that needs to be available on demand. The hardware selection is still not certain, but there are a few candidates; the key, given that pesky “always-on” specification, is minimal power dissipation. It doesn’t have to be the fastest thing out there, just rock-solid reliable except during a lightning strike (then cheaply replaceable once toasted ).
The colorful lower-left section of the drawing is already installed and working well: the N2K network of navigation instruments and related nautical goodies. I use a Maretron backbone, the Autopilot is Simrad, and the masthead is a trusty old B&G; Network system interfaced to N2K via a 2-hop kluge that is still not quite stable.
All this is electrically CANbus, and talks nicely to chartplotters and the DSM250 display at the inside helm. A key requirement is a stream of all available N2K data into my database, and the current plan is to use the USB100 gateway. This is a Windows-only product, so an early to-do list item (unless a volunteer pops up!) is to see what it takes to slurp this into Linux… hopefully it will run under WINE.
Back Doors and Other Strays
The little cluster at the upper right doesn’t need much attention right now; it is basically a collection of serial devices that need to interoperate with the server. Most critically, I need to be able to run a Winlink client via the PACTOR box that, in conjunction with the Icom 802 SSB rig, will be the key link for global messaging. I was happy to hear at the conference this weekend that a Linux client exists, and now have some connection with folks who know the system well.
Ideally, proper client/server design should allow use via any of the laptops or the embedded Mac. But I’m straying into the domain of hand-waving here, as I haven’t explored this part at all.
The zone of miscellany also includes the sexy Kenwood D710A, the serial feed from the retro stand-alone NAVTEX box, the data stream from the Outback power system, and some other gear. I prefer to use the Mac for all the audio stuff, however; an important subsystem involves Audacity, USB and FireWire interfaces, Garage Band, MIDI, and other musical goodness.
The Sea of Nodes
The big array of 15 boxes below the USB hierarchy is where most of the fun stuff resides… all Arduino-based, as far as I know at the moment.
Every node takes care of some logical grouping of I/O points, generally in some localized region of the boat. This minimizes cabling and keeps things clear, and some nodes are defined more by their location than any particular function (like Midship). Some are trivial, just picking up a few bits or analog sensors and turning them into variables that are periodically polled; others are responsible for actual control tasks.
A couple of them have some infrastructure responsibility. The Crossbar node is a huge array of DPDT latching reed relays driven by a long chain of SPI shift registers, and (unlike my earlier Microship crossbars) is completely signal-agnostic. Little groupings can be conjured to make anything from the serial switch in the drawing below to a sparse matrix or full-blown multiplexer, and they can handle audio, video, analog, or whatever. This physically resides in the Hub, and is making me wonder if the sexy audio mixer was such a good idea… gobbling panel real estate with non-marinized controls.
The other infrastructure node is the one that lets me get access to this whole system without having to go through the network front end:
This uses the venerable “Yaesu twins,” the 290 and 790, which have the distinctive characteristic of sipping only about 50 mA on receive standby yet cranking out 25 watts on transmit. Every other robust VHF/UHF rig I have seen sucks about an amp when just sitting there, and, like the Hub, these need to be on all the time. They don’t have fancy computer interfaces, but I don’t need them here.
What I do need is a way to communicate with the boat from shore, using only waterproof low-power hardware (not a laptop). I always carry a Yaesu VX-6R submersible handheld rig in my pack, and like all modern amateur HTs it includes a DTMF pad for accessing telephone autopatches on most repeaters. Here, I’ll just key the microphone and state my call to keep things legal, then transmit a short tone sequence that is decoded by a chip hanging on the Arduino. Depending on the command, it will then construct a serial string that is passed to a speech synthesizer… yanking the push-to-talk line on the rig until it gets the all-done signal back. “Main battery level is 72 percent.”
The node is frequently updated with every variable on the ship (well over a hundred data points), and typical queries generate a summary of some subsystem, request a report on alarm conditions, or implement simple controls. One class of commands is piped to the hub, allowing a higher level of response (do I have email?), another is fun demo stuff, and yet another takes care of “back door” maintenance functions like rebooting the Hub or rerouting network connections. The hooks are even here to implement a complete remote-base operation on HF ham radio or other comm systems.
Similar functionality can be had via a vanilla packet radio link on 2 meters, or through the “Ethernet shield” on the Arduino that allows a connection via the Internet (with authentication, of course).
This is going to be a fun one. On the Winnebiko II and BEHEMOTH bicycles, speech interaction was one of the most entertaining parts (a Votrax on the former, and Audapter on the latter).
A Note on Complexity
Finally, I want to address a frequent and reasonable question (which came up during the Q&A; session following my talk the other day). Even leaving out the maintenance issues with all this gizmology, is there a danger that the complicated gadgets will distract from the fundamental operation of the boat, negatively impacting seamanship?
Well, not if I do my job right. The idea in all this is not to tinker endlessly with gadgetry, but to strike a balance between the kind of stuff I find most amusing and the practical needs of maintaining an 18-ton voyaging machine. None of this should ever be in the critical path to basic sailing and primary safety; it is instead a layer of “local situational awareness” that is intended to tag reality with additional information… and otherwise stay out of my way.
A good example is the Waterworks node. This has a centrally located flow sensor along with a way to see the position of every valve on the boat, so right away I get intelligent tank level monitoring, usage summaries, and other resource management. But with all that in place, it becomes trivial to solve a huge maintenance headache:
A sealed box with an LCD and very simple user interface is next to all the plumbing stuff. Anytime I perform an action like changing a filter, replacing the UV sterilizer bulb, or cleaning a strainer, I tell the node about it by stepping through a set of choices. This then becomes a “soft event” that is time-stamped and logged in the database. Now it’s easy to keep track of the total number of gallons (or weeks) that have passed since each maintenance task, providing a dynamic PM schedule that doesn’t require me to remember to check things that are properly out of sight, out of mind.
So it’s getting fun. Despite all the absurd distractions (real estate?), this and the fundamental ship systems are now the prime focus… Spring is coming!
Now to go Tweet this and get to bed.
You must log in to post a comment.
Have you considered which hardware platforms for the linux box?
Having built a couple, I know some of the mini-ITX form factors are low power and fanless. Apparently nano-ITX and pico-ITX even moreso.
Seems lots of people use those with solid state media.
Hi RJ, and thanks for the comment. Yes, nano and pico ITX seem to be the default choices. I’m also considering the 12V Aleutia and even a stock netbook… it will generally run headless, but having a local LCD would be a good idea for dev and debugging.
Thanks for the OmniGraffle Pro tip. I’m about to give up on booting my MacBook into Windows to use Visio.
Have you considered what navigation programme to use? There are very few linux-compatible ones out there.. and only one free software
Phil – yes, the plan is to use MacENC on two Mac Minis (for redundancy), and dedicate a Linux box to the always-on server application. Cheers!