Keep the User in the Loop
User feedback is critical. Originally in Embedded Systems Programming, September, 1999.
By Jack Ganssle
Position 19' 21 North, 61' 40 West, 140 nautical miles from Antigua, 1600 miles since leaving Baltimore. Long time sailing buddy Scott and myself have been pushing Voyager, my 32 foot sailboat, towards this small Caribbean island for two weeks. We expect to arrive in another day or two. The first week's frustrating light winds depleted our diesel supply, so we diverted to Bermuda for fuel, staying in that beautiful island for a mere 13 hours. After topping off the tanks nature rewarded us with nonstop strong southeasterlies; the engine has been off other than an hour or two a day for battery charging.
25 years in the embedded industry has taught me to try and separate professional from personal activities. Once nothing seemed cooler than creating an electronic solution to a boat problem; now I find simplicity much more satisfying, and have worked hard to eliminate excessive technology from my sailing life. Yet here I am, 1000 miles off the US coast, propelled by the wind, but typing into a 200 MHz laptop. Voyager exists in an odd mix of the traditional and the transistor age; her two masts and dacron sails keep us going using the technology of Noah. We use archaic navigational tools, relying on a sextant to find position from the sun, stars and planets, but dual GPSes hide in the chart table for use on cloudy or seasick days, and for finding difficult harbors.
15 miles out of Bermuda I powered a GPS up for the first time on this voyage. The resulting latitude and longitude matched our celestial position closely, but as I watched the unit the displayed latitude jumped by two degrees - 120 miles, making a mockery of GPS's vaunted 100 meter accuracy. Scott, also an old embedded hand, cut to the heart of this technology failure as he showed the unit just did not get enough signal strength while below deck. In the cockpit, its unobstructed view of the sky yielded good fixes.
I was aghast. Shouldn't the box show clearly that the displayed data was in error - or at least suspect? We eventually found a signal strength page hidden deep in the box's menus, but to my mind, no embedded system should ever lie to the user. normal">Every embedded system should tell the user when the data is unreliable.
GPS has taken the navigational world by storm, due to its high accuracy, ease of use, and low cost. Until the relatively recent invention of GPS navigation was always more art than science.
Early sailors were uneducated seamen, plowing the same short routes across the Mediterranean. Rarely long out of sight of land, they depended mostly on piloting - the art of figuring out where you are by looking at features ashore, mostly without instruments. By Columbus's time even the compass was little more than a magnetized needle floating on a cork.
The ancient Arabs learned to find latitude by observing the stars. It stands to reason that as you head north any specific star will appear lower and lower over the horizon. Arab astronomers invented the astrolabe to measure the stars' angles above the horizon. Some incorporated crude ephemeris data (the position of the stars based on season) into intricate rings inserted into the instruments.
Published ephemeris data became available during the great age of discovery that began around the time of Prince Henry. Finding latitude by observing the sun at meridian transit (when it is due south of the ship) became one of the expected arts of the sailing master. Longitude remained a thornier problem.
Longitude is easy to find if you know the time. In effect all one has to do is note when a star passes due south; if that time is 0000 GMT, and if the star's position in the universe is cataloged with an "hour angle" of 0 degrees, then you are standing on the prime meridian. If this same star transits your local zenith at 0100 GMT your longitude is the distance the earth rotates in one hour to the west of the prime meridian: 15 degrees.
Prince Henry's sailors did not have reliable clocks, so had no way to find longitude. A sandglass is not terribly accurate to start with. Clocks built prior to the middle of the 18th century mostly relied on a pendulum and counterweight, mechanical analogs of the sandglass with all of its shortcomings.
As the English started to dominate the sea lanes, Parliament realized that they were a nation of seafarers who were all but lost on every long voyage. In 1714 the desperate ruling body enacted a law offering 20,000 pounds for the first clock that lost or gained no more than two minutes after a round trip to the West Indies.
The prize went unclaimed until 1761. John Harrison's temperature compensating chronometer used a spring instead of a weight and passed the test well within specifications. Though decades passed before chronometers became cheap enough so every ship carried one, accurate clocks had solved the problem of computing position anywhere on the globe.
Now sailors could observe the angle of two or more celestial bodies above the horizon with their sextant, note the time of each observation, and by not terribly difficult mathematics compute their position. Officers guarded the secrets of navigation so a mutinous crew would be lost, creating an almost priesthood-like mystery shrouding it that persists to this day.
The heaving deck of an ocean-going vessel is far from the ideal platform for making sextant observations, as an error of a single minute of arc (1/60th of a degree) yields a mile of error in position. Because the earth rotates 15 minutes of arc per minute of time, noting the sight's exact time is just as important. A 4 second error also creates a mile of position error. Worse, because it's hard to see the horizon and more than one body at a time (e.g., during the day the sun is usually the only visible celestial object) each sextant sight generates not your position, but merely a line that the vessel is on. Cloudy days means no observations are possible. Clearly, determining position via celestial sights is tedious, error-prone, and subject to nature's whims. Yet, until the late 60s virtually every ship in the world navigated by nothing more than a sextant.
Various forms of electronic navigation offered simpler ways to fix position. Loran A used phase differences broadcast by multiple shore stations to fix position to an accuracy of a mile or better. I loved Loran A. The user interface was an oscilloscope display; the navigator rotated a knob to align pulses from two shore stations on the scope. With practice one learned to tell the quality of the fix by looking at the strength of each pulse; you could even tell sky waves from ground waves by the displayed signals. The user got two sorts of data: position, and an assessment of the quality of the fix.
Loran C replaced the A version in the 80s; it offered higher accuracy, and was the first system to rely on microprocessors for data reduction. Loran C receivers entirely removed users from the loop; the units' CPUs computed and displayed nothing more than latitude and longitude, exactly what the navigator needs.
But Loran C illustrated the peril of insulating users from the physics that underlie any application. Sure, we really only want final, smoothed, accurate, data in intuitive units. But incorrect data is worse than no data, a lesson even today too many systems seem to ignore.
On a sail to Newfoundland in the early 90s the Loran's output just did not jibe with my dead reckoning track. We learned later that off Cape Race some weird atmospheric effects drove Loran positions off by 20 miles, enough to have put us on the rocks if we had chosen to believe the displayed data. Part of me is wary of electronic data -perhaps those of us who grew up with slide rules rather than calculators tend to always question data - so I've always used multiple navigational inputs rather than just believing the box.
GPS uses its own constellation of electronic stars - satellites that broadcast radio signals to a computer in the user's receiver - and produces positions accurate to better than 100 meters. GPS gives worldwide coverage and requires no expertise. A nice sextant - hard to use, suffering from all sorts of accuracy problems, and requiring high levels of expertise - might cost $2000. A GPS runs for under $100. The electronic solution clearly wins any way you compare.
I love electronic toys, but am appalled at the unspoken philosophy of GPS which is "be happy, don't worry". The sailor determining position from a GPS looks like a worshipper at Sunday services. There he stands, hanging on the lip of the chart table nervously watching the LCD readout. Will the system acquire satellites today? He bends over to press a button. Suddenly a position appears! The miracle has repeated itself once again!
And it is indeed a miracle. Arthur Clark, writing about advanced aliens visiting our backwater planet, commented that any sufficiently advanced technology appears to be magic. The sailor shuffles off, content that somehow this group of numbers simply must be right - the little box told him so.
This effect is symptomatic of modern society. Our technology is so advanced we've fooled ourselves into thinking it's all magic. How many people understand why that suspension bridge stands up? Who cares - it's a miracle! Few bother to learn about the bridge's delicate web of forces engineered to cancel each other out. What about the MRI machine that saves your life, or the TV set far too many remain glued to? Insatiable curiosity was never important before the industrial revolution since there wasn't that much to know. Now I'm afraid it's been all but bred out of us.
GPS, like many modern technologies, uses a very complex constellation of satellites, astonishingly intricate algorithms, and possibly intermittent earth downlinks. Clearly things can go wrong. Any time we designers produce a result - like a lat/lon display - we have a responsibility to our users to qualify that result in some manner. If the signal level is too low for accurate readings, blank the display, or somehow make it clear that the data is less than pristine. As I mentioned, off Bermuda we saw readings jump 120 miles in a matter of seconds, probably due to low signal levels. A much better design would recognize the inadequate amplitudes and blank the display. Bad results are worse than no results.
When a navigator computes position using a sextant sources of errors abound. Small plotting errors create chaos. My middle-aged eyes have trouble focusing on tables of numbers, so all too often I'll miscopy a critical parameter. But the errors don't necessarily matter, as the process of navigating using these atavistic tools includes cross checks and common sense evaluations. I plot the sun's line of position, but find it's 20 miles off of my "dead reckoning" (nav by computing course and speed) position, so I go back over the numbers until the mistake stands revealed.
The magic of technology is it frees us from the tedium of older solutions. Punch a button, get a number, but give me some sort of cross-check as well. The repressed Luddite in me wants more than a result.
Spreadsheets create a similar frustration. Change one number and a thousand computations alter an entire matrix of results. I use spreadsheets all day long, but have learned that a side effect of computing is that we can now make thousands of mistakes per second, instead of one or two. Long before computers accelerated our production of bad numbers, accounts invented the double-entry ledger to cross check all of their results. All of my important spreadsheets emulate this accounting trick, creating a column or row of numbers computed as a cross check on my main results. Tedious - sure! But it's the price of technology.
Another embedded system on Voyager, one that suffered from none of these user interface problems, is the single sideband radio (SSB), a 100 watt transceiver that we use for chatting with other boats, friends in distant places, getting weather information, and simply listening to BBC for entertainment (after 17 dys at sea entertainment becomes important!). SSB radios long predate the embedded revolution, but adding processors both enhances signal reception (a DSP reduces noise and boosts the signal), as well as controls the operation of the radio. The micro helps modern SSBs synthesize frequencies from digital counters, rather than rely on far too many crystals. LED readouts - driven by a processor - give the user a complete view of the system's operation.
My radio shows frequency, mode, and all important parameters on the display. It will even show the match to the antenna, a critical indication of how well the unit is transmitting. The processors enhance the features and functionality of the radio, without hiding any important operational details. This, to me, is a well-designed embedded product.
The boat's VHF (short range) marine radio is also nicely implemented. Simple controls give access to all system features. Though a micro is not needed for basic VHF communications, adding one allows features like dual channel monitoring. Though some VHFs now use arrow keys to control everything from working channel to volume, I prefer the pot-like knobs that some other vendors still provide. Twist the volume control to set audio level in one quick motion, instead of holding an arrow key and watching a display for some interminable time.
Voyager's autopilot is equally well designed. A flux gate compass sends heading to a paperback-sized control unit. The micro therein computes the difference between the boat's real course and the one entered into the unit by the helmsperson, sending the correction needed to a motor that drives the wheel. In the awfully wet salt environment of an ocean-going boat keypads and other button-rich interfaces are a constant source of leaks. Instead, to set the course we steer the boat in the direction we want to go, and press a single "auto" button. What could be simpler? The truly important operational parameters I can see by glancing at the wheel, and watching how the unit steers. If the wheel is hard over one side all of the time, that tells me it's time to balance the sails better. If for any reason it cannot steer the desired course, an alarm sounds. So, even when singlehanding (in July I'll sail alone from the Virgin Islands to Bermuda to meet a friend), I can sleep below safe in the knowledge that an alarm will wake me if we're off course.
The designers tailored the unit's features and design around the real needs of sailors, subordinating technical features and details to ease of use considerations.
Voyager's radar detector also provides a great mix of embedded smarts with an almost perfect user interface. The unit wakes me when a ship comes within 10 miles or so. (Collision at sea is a constant worry.) The micro monitors RF circuits to detect nearby X or S band radar. If the signal matches parameters characteristic of marine radar sets, it sounds an alarm. Though an interface this simple provides adequate functionality, it resembles the GPS in distancing the user too much from the physics of the acquired data. To overcome this, the unit includes a "listen" mode, which disables the alarm and dumps the raw radar signal into a speaker. When the alarm sounds I switch to "listen" and hear the signal itself, which might consist of a main pulse with two sidelobes. With a bit of practice it's not too hard to separate commercial radar sets from military units, and to even get a vague feeling for the distance off of the radar source.
The designers provide the user with a wonderful mix of sophisticated digital signal processing and an analog output that lets me use the wetware computer between my ears to do further processing.
As we slide into the close of the 20th century many of our electronic gadgets seem designed for people with the most minimal cognitive skills. Me, I figure that the brain is still a useful adjunct to life, and am not yet ready to delegate all thought to my electronics assistants.