By Jack Ganssle

Version One

I have no idea why we were out there. Graham, though seasick, did manage to stand watch. My wife stoically hung on and cooked despite the battering waves. Sudden squalls attacked unexpectedly, the wind increasing from 30 knots to 55 in a matter of seconds. Voyager heeled far to port, the portholes and deck underwater till I wrestled the sail down.

We weren't having a lot of fun.

Then the vane, a mechanical device that steers by the wind, failed. The electronic autopilot was overpowered by the rough conditions, so we steered for three days, each of us on the helm for two hours, off for four, night and day.

Yesterday we arrived in Bermuda, after sailing 800 miles to the southeast from Baltimore. Yet we're really headed north, to Nova Scotia and Maine. Why take this outrageous detour that'll add perhaps 1300 miles to the trip?

The ostensible purpose is to check out a new technology called AIS, or Automatic Identification System. International law that took effect this year requires all ships over 300 tons to automatically broadcast a lot of information, including their name, position, course, and speed a few times a minute in a digital stream on marine VHF frequencies. These vessels also have a RADAR-like display that displays such information from all other ships within 20 or 30 miles, to help avoid collisions.

My biggest fear while sailing far offshore is being run down by a fast-moving ship that can't see my little boat. Over the years I've added various bits of electronics to warn of nearby traffic, such as RADAR. But that takes too much power to run continuously, and rain squalls obscure even 800 foot fast-moving metal monsters. A RADAR detector sounds an alarm when it detects signals from any vessel within 10 miles or so. yet nearly half of the ships we see don't run RADAR in good weather. So when NASA Marine released their AIS system for small craft, I bought an early version. It consumes a bare 80 ma and sounds an alarm when detecting any vessel within a programmable range.

Most of us techies are early adopters. When confronted with cool, reason yields to passion. Yet having all-too-often rushed a new technology to market, we embedded folk know that version 1.0 is always a poor early iteration sure to infuriate our customers. I found this AIS unit a perfect example of how marketing's drive to ship now sacrifices quality.

Though I'll dissect the unit's shortcomings, it is a fabulous and inexpensive piece of gear that flawlessly displayed the position of every ship we saw, with the exception of the three Navy frigates that followed us for 24 hours out of Norfolk, one of which scarily conducted live fire exercises three miles away. Unsurprisingly, warships don't care to advertise their positions.

We tore the unit apart out of the same curiosity that drove my mother crazy so many decades ago when she found her appliances half disassembled. It's not much more than a simple VHF receiver that feeds the digital stream into an 8051, with a 3" x 5" LCD to graphically show ship positions, plus four pushbuttons whose function changes depending on operating mode.

I don't know the folks at NASA Marine, but can imagine the engineering discussions that resulted in the selection of an 8051. This low-end (about $350) product had to have very cheap manufacturing costs, so an 8 bit microcontroller as a natural choice. Me, I tend towards 8 bitters whenever possible as well. Yet in this case it was a poor choice. A version 1.0 unit, engineering should have realized that marketing will invariably load versions 2.0 and 3.0 with lots more features which will surely overtax such a minimal microcontroller. Can you imagine how tempting that LCD display will be to the sales folks? "We have a customer who wants to play video games on the thing! I promised another we'll ship a version that plays DVDs. next week."

Not that long ago designers wisely matched horsepower to the scope of the application. But today feature-hungry consumers, aided and abetted by marketing departments clueless about real costs, evolve beautifully simple and elegant systems into wart-covered elephants that barely resemble the original concept. All too often those warts in part arise from frantic designers trying to cram insanely complex features into a tiny address space already chock-full of the system's bare essentials. As an EE trained to minimize bill-of-material costs, it pains me to make the following recommendation: when at all possible, especially on a system with a graphical display, use more processor than you expect to need. Version 2.0 will surely consume the excess CPU cycles and memory.

On this AIS the 8051's limited RAM makes even version 1.0 behave poorly. When more than one ship is in sight the user presses the "data" button to scroll through information broadcast by each vessel. Select one, and the right side of the LCD shows that ship's name, position, speed and more. Press "data" again to select another target and. wait. And wait some more, for up to a minute till the ship transmits again. For the processor has so little RAM it cannot store the information transmitted from all ships in the vicinity. With more RAM the system could suck in data from every vessel, and immediately update the display as the user switches between ships.

Were people more patient years ago than today? In the Vacuum Tube Era everyone expected to wait a minute or so when powering up anything electronic. Those tolerant times are long gone. Never make a user wait because of some technological limitation. Only version 1.0 products have delays. Version 2.0 won't, which, in this case, will require a complete redesign to add more processor oomph.

When I first tried the AIS in Baltimore harbor it showed several ships were on a heading of 511 degrees. 511? My immediate reaction was a chuckle; here's yet another buggy embedded system reporting insane answers.

A very short FAQ in the manual, though, tells a different story. Apparently the unit displays this odd result when a ship, for some reason, doesn't transmit course information. At least the manual reports this peculiar mode. But as a rule, never present stupid results. When any output confuses the user the system is poorly designed. I'm sure version 2.0 will show something more reasonable, like "none" or "---", and can't imagine why the designers chose to show such a strange and arbitrary result.

(Last year I saw a huge side-of-the-road billboard displaying the temperature on a fine September day. -196 degrees. This was another case of designers making poor decisions. Better, bound the possible output values. If the code generates an impossible result, perhaps due to a hardware fault, it's far better to show nothing, or perhaps "HELP ME!")

And then there's the unit's manual, a version 1.0 bit of work if there ever was one. Seven microscopic pages cover everything from installation to its operation. Though the AIS's use is pretty intuitive, a credit to the designers, one or two modes continue to elude me. One of these days I'll spend some time playing with it to finally master those features. But it's always a bad idea to make the user guess. This is the communications age, and good product design requires a manual that communicates clearly and completely.

I wish the manual's shortcomings were indicative of a version 1.0 device, but my boat - and my life - are filled with embedded apps whose docs range from completely inadequate to almost laughable.

Figure one shows both the AIS and a Link 10 from Xantrex, which monitors the condition of Voyager's twin golf cart batteries. It's a remarkable unit which works flawlessly. Clearly it's well past the version 1.0 stage.

But the user's manual is awful. Also printed in small size that doesn't fit in any normal filing system, it's full of cryptic proclamations like "The Charged Current % times declared Battery Capacity MUST be GREATER than the minimum current at which the charging system maintains the batter, or turns off." Huh? So little care was taken with this document that even the copyright notice doesn't meet legal requirements. One function I use pretty regularly is so poorly described I've had to write out the procedure on the appropriate pages.

Don't treat the user so badly. He experiences your product through its features and documents. The code we slave so long over is sort of like an engine's cooling system: critically important but invisible. Hire one of those poor English majors who is dejectedly pursuing a career in the fast food industry to create a manual that thrills, rather than torments, your customer.

A sailboat runs off batteries for days, between engine-charging periods. Most sailors use quite elaborate alternators and voltage regulators to put amps back in the batteries as efficiently as possible. Voyager's regulator is from the same company that makes the monitor I've just described, and the manual is equally obscure, suggesting that the company has a policy of deprecating the docs.

Yet that regulator, like the battery monitor, is brilliantly engineered. It's completely potted in epoxy for waterproofness, a highly desirable feature in the salty sailing environment. LED displays show clearly through the clear potting. To select various operating modes and set parameters the user holds a small magnet, cleverly supplied with the unit, to activate a reed switch buried in the epoxy. A simple interface using just this one switch lets one enter many dozens of numeric values and more. Kudos to those engineers.

Voyager was built in 1977 and some of her equipment is original. It's fascinating to see the evolution in the nature of products by looking at these electronic accessories. Her original depth sounder shows depth. Nothing more. The old knotmeter, recently replaced, displayed speed. Period. The replacement shows water temperature, max, average, and min speed, plus another dozen or so readouts.

This winter I replaced the original radio. The new unit, a marvel of embedded engineering, communicates as the old one did and offers so much more. So much, that I'm still trying to figure it all out. The thing even displays a happy fish icon when the barometric pressure is suitable for angling. Cool, I guess. But surely the embedded revolution has made products of all sorts so feature-rich that version 1.0 releases tend to be buggy, hard to use, poorly documented, and sometimes not so well thought out.

No one is more important to a project than the customer. He or she puts food on our table, clothes our kids, and pays the mortgage. Design to delight first, rather than to cram lots of infrequently used features into the system. An explosion of features can wait for version 2.0 and 3.0.

Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that goes to 48,000+ engineers. Click here to sign up or enter your email here: