Wireless Data Link
Our solution is a tiered approach. The most primitive, always-on system is a 70cm ham radio mated to a task in the hub processor that listens for DTMF (touch-tone) commands from a pocket walkie-talkie... and delivers synthesized speech responses to acknowledge commands or give reports.
The highest level is "wireless ethernet" operating at 11 Mbits/sec, transparently connecting laptops and linux boxes when all are relatively close together.
In between is one of the most critically important components in the Microship system... a network of low-power, speedy, spread-spectrum data radios from World Wireless. We have two choices here, both shown at right with PDF data sheets available: the Microhopper and the Hopper. These are frequency-hopping spread spectrum radios operating under license-free (FCC Part 15) rules in the 900-928 MHz band.
The little guy, under $200 in singles, has an over-the-air data rate of 19.2 Kbps, operates at 100 mW, and is good for about a half-mile line-of sight (better over water or with directional antennas). The big one costs about twice as much, runs 56 Kbps, pushes 1 W into the antenna, and talks about 25 miles line of sight depending on conditions. There's a power cost, of course -- the Hopper wants about 500mA from the 12V supply when transmitting (about a fifth of that on receive); the Microhopper is a little less hungry, averaging about 150mA. Both units possess some extremely clever networking capabilities, including a guaranteed delivery mode, group and unit addressing, and (in the case of the Microhopper) the ability to serve as a repeater without involving application software.
Microship wireless network operation
The whole point of this network is to integrate both boats into a coherent unit. The infrastructure is already there... the audio and video crossbars include bidirectional analog links to the other boat, and it's not much of a conceptual leap to include our backpacks in this big interconnected pool of devices. All that's needed is a coordinated, always-on, long-range data network to make the boundaries disappear completely. Ethernet speed isn't critical here, but we can do a surprising amount with what these radios have to offer.
I should mention that we have to approach this problem from two directions. The obvious is the movement of control and telemetry data between the boats, as well as the ability to remotely command the system to do various things, show status, etc. But we also want to interoperate as cleanly as possible with the linux-based front end, which is a whole desktop-scale GUI. Where do we draw the line between this rich but intermittent environment and the low-level control that has to be always available even at times of thin power budget? What "modality" exists between being on board and walking around town... or lying in the tent? Ideally, a single small portable user interface should be always at hand, whether I'm sailing, dining, or checking in from a trade show a thousand miles away.
Life is too short for reinventing the wheel, so let's postulate an off-the-shelf platform... the Palm. It's elegant, well-supported, and has great battery life. Figure out how to seal them against aqua regia, seal one onto each console, conjure a bit of front-end code analagous to Palm Query Apps, and we have an instant Microship control panel connected via serial crossbar to the Hub processor. Here's the cool part: when we clamber out to take a break or start hauling the boatlets down the road, we notify the ships we're leaving, prompting the Hub to switch the connection to the wireless pipe and allowing us to use identical Palms velcro'd into a little portfolio of techno-goodies. Same user interface... the only difference is which crossbar channel the Hub uses to talk to the user.
We put the radios in broadcast mode, which turns the group of four units into one big piece of wire: any data squirted in one connector pops out the other three. (Obviously, this requires some sense at the application level to sort out what's intended for whom, but computers are good at string munging.) The radios married to the hub processors on the boats can natter away to each other, exchanging crossbar commands, telemetry, GPS data, security status, and other information. With the boats parked on the beach and the other two radios now alive in the backpacks, the normal control-panel traffic appears on the wireless network as well.
What kind of user-interface tools will exist in these wireless Palms? Here's a preview... there will eventually be a whole section under Tech Info on this site with documentation and screen snaps of all this.
- Home view, start of navigation tree
- Monitor, which allows a configurable window (or slide show) of Microship internal sensor data, system variables, environmental sensors, and so on.
- Crossbar setup tools and a macro system for building and naming interconnect configurations. Bear in mind that these wireless data rates should handle voice-grade audio streams, allowing this to become a remote front-end tool for communications devices on the ship.
- Video tool for choosing (and optionally steering) any camera and snagging a frame-grab... or capturing to tape... or transmitting live video via analog radios
- Security tools, including configuration of events and responses for different environments, arm/disarm functions, display of violation events, and so on.
- Local speech synthesis with live audio feedback for interacting with passers-by
- Hub messages and system status.
- Email piped from the linux server... direct Globalstar terminal access, packet radio, etc.
- Autopilot control
- Thruster control -- command automatic power-tracking mode, or override and drive manually
- Basic navigation data display (note that the full charting system is on the "real" computer), waypoint snagging, and textual annotation of telemetry or frame-grab events.
- APRS and the "where's Natasha?" function
- Power management displays, including solar performance and battery info
- Personal notes
- Inter-boat simple messaging
- Tool for powering up the linux box and opening a comm channel
In addition to all this, of course, we have the vast resource of available Palm applications...
The net effect of all this is elimination of the "modality" that would otherwise enforce completely different interaction protocols when on land, on board, and presented with the linux environment. This also reduces the need to keep the "Big Iron" on all the time, as most of the basic control functions can be performed via tiny portable tools.