Reprinted from:
AUUGN 21(1):8-9 (2000)

Linux under Sail

D.F. Davey
Physiology
Univerity of Sydney

The enjoyment of cruising, and its safety, is critically dependent on the weather. When doing coastal cruising, where heading into a safe haven is an option if the weather gets nasty, having access to good weather information is critical. Special marine weather forecasts and reports are broadcast on marine frequencies regularly, but there is nothing better when making important decisions than the weather charts produced by the Bureau of Meteorology. Sometimes these can be had on television, but there are two other important sources, the Bureau of Meteorology Web site, and the Naval HF Weatherfax transmissions. The former requires a computer, the second can be received with dedicated hardware, or more economically with a computer interface to an HF receiver. The Web solution only works when within range of a digital telephone network; the HF transmissions can be received anywhere.

Of course there are other internet sources of information, including tides, contact with most marine equipment manufacturers, Notices to Mariners (more later) and more. And of course there is E-mail.

Economical web transactions

That one can achieve an IP connection over a GSM phone does not mean one can afford to use it. The timed call charges are orders of magnitude higher than ISP charges, so keeping connections to a minimum duration is critical. This is where Linux comes into its own. (If you are interested in the hardware and/or software, see the Appendix.)

HTTP requests

Rather than use an interactive web browser to request files, I use wget, which can be called from a script. Parallel asynchronous requests turn out to be even more connect-time efficient, so a script like

#! /bin/sh

URLS="url1 url2 url3 ..."

for i in $URLS
do
	wget $i &
done

wait
echo -e '\\007$0 finished'

Of course the real thing is more complex, e.g. exploiting sed to change HTML image links from the original ones to ones pointing at local files, using time-stamped file names for wget output, and setting symbolic links to these files from generic names pointed to by a local index file that can be used with a web browser off-line.

Some of this is easier said than done, for some web documents using Java and/or frames and/or image maps can be interesting challenges to get down to the particular URL of the desired specific piece of information sought. Naturally this is best done when a shore line is available. Using a browser's document information facility or scanning the HTML is sometimes needed. Trial runs with wget usually pay off. Using browsers that do not support frames or Java (e.g. Amaya) can help if the server responds appropriately to such browsers.

Conditional HTTP requests

An example of Web documents that are valuable on board are the Notices to Mariners published by the Australian Hydrographic Office. These advise of changes to nautical charts that need to be applied for safety. Published fortnightly and made available electronically as PDF files they are extremely valuable to a careful navigator. Getting these efficiently means knowing what files are available compared to the ones you already have. Some issues are in the form of multiple files of text and images, so this is not done efficiently interactively. Again Linux comes into its own, with a simple mirror script using wget to obtain the current list of files, comparing this to the local list and requesting anything new. Incidently xpdf is a nice alternative to commercial PDF readers for viewing the files.

E-mail transfers

I often have 50 work-related E-mail messages in a day plus the ones I really want to read, so once again, efficiency is critical. Reading E-mail with a telnet session, or transferring single messages with sendmail or pop is not the way. Having access to a land-based Unix system provides a number of alternatives. The most efficient ones all involve dealing with all the E-mail off-line, and transferring incoming mail as a single file compressed with gzip, i.e. the land-based system compresses my entire mail file, moves it aside and passes it to the on-board system. Outgoing mail files in the queue directory are put into a compressed tar file before the IP connection is made, then passed to the land-based system which unpackages the file into its queue directory and triggers sendmail into action. For simplicity and to minimise connect times, this is done with sendfile, part of the TCPmsg system. So in principle the process is:

tar and gzip the local mqueue directory and clear it so sendmail does nothing when the link is up
dial and start the cslip connection process
look for the remote host with ping packets
sendfile the tar file to the remote (where cron takes care of it in due course)
log in to the remote and trigger the incoming mail transfer (scripted again for speed)
wait for completion of the sendfile and receiver processes (easy because they both establish lock files)
break the connection

This usually takes 1 to 1.5 minutes for a typical batch of mail that might keep me occupied for several hours dealing with it. The outgoing mail file contains a test message addressed to the remote machine with a time-stamped Subject: line, and a matching informative message is sent to the on-board machine. On the subsequent connection the test message comes back. Any failure of the system would become evident if this did not happen.

Tidal information

There are web sites that serve tidal information, but for all but the most critical requirements, software together with data files of tidal harmonic constants can deliver adequate tidal predictions for most sites and any time. The X based program xtide is a very easy to use application that produces graphical or tabular output.

Weatherfax by HF radio

Weather and sea state information are broadcast over HF radio frequencies from Naval transmitters in Canberra and Darwin. As many as 65 charts are broadcast daily using what is effectively old technology but one which suits one way and noisy communication lacking error correction. The system is one in which the source image is scanned at about 2 lines per second, and black and white in the source is encoded as a frequency shift in the radio signal. No timing information is contained in the signal, so the receiver must somehow sync to the source scan, which requires knowing the scan rate, though there is scan frequency information contained in the start of the transmission - effectively a black bar at the top of the image. Decoding this signal is in most ways trivial, though it is a real-time process which potentially Linux is not good at.

A simple interface can convert the modulated signal into a binary one that can be monitored with the modem control lines on an RS-232 interface, or with a parallel port. Because the scan frequency is so low, the real time requirement is not difficult, so it is possible to continuously sample the signal and the system clock (which has microsecond resolution). In fact "continuously" is far too fast, and judicious use of usleep() calls to create a pseudo regular sampling proved the best answer to avoid having to use MS-DOS software. So a simple X program displays the incoming chart a line at a time, and the real time problem is not really a problem at all.

One problem does remain however: the reception process is very slow and it takes 10 minutes to receive a chart (and of course if you miss a scheduled broadcast you just have to wait for the next, anywhere from 6 to 24h). But at least with Linux, while you wait the 10 minutes, you can be doing something else.

Appendix

Power

Power on all but the largest yachts is usually restricted to 12V DC. Sometimes people use 24V, and the odd boat has an inverter to produce mains voltage AC, but being able to work with 12V is handy. Fortunately much portable computer gear will operate on 12V DC perfectly well. That includes all the equipment mentioned here. On our yacht we use large lead-acid batteries charged with the engine alternator and with solar panels. On sunny days, the panels will drive the computer gear with power to spare.

Hardware

I use an AcerNote laptop which has a PCMCIA slot, parallel, serial and IrDA ports, 1.2Gbytes hard disk, 32Meg memory and a floppy drive. I have PCMCIA peripherals: a modem card for my Ericsson GSM mobile phone (which also works with the IrDA interface), an interface for a portable CD reader, and a SCSI card for a JAZ portable disk drive (unfortunately needing both 5 and 12V DC). A Canon BJC-80 portable BubbleJet printer works with the infrared port. Finally a weather fax interface to our HF radio receiver connects through the serial port.

Linux Version

I run a file system that traces back to something like Linux-0.81, and which I have progressively upgraded myself. Recent upgrades have been driven by the IrDA code which is under intensive development. The code now intended for Linux 2.2.15 is stable and reliable for my purposes.

System software

I run X with a 1280x1024 virtual screen which overcomes the smallish display on the AcerNote. Print spooling to the printer is with lpd using Ghostscript, so it looks like a PostScript printer. I use dip and CSLIP for networking because in my tests, CSLIP throughput is 10-30% better than ppp. Sendmail provides the primary mail handling. wvWare deals with the irritating MS-Word attachments people insist on sending me.

Pointers

wget is available from the author's site or gnu sites like prep.ai.mit.edu.

Notices to Mariners are available from the Naval Hydrographer.

xpdf a non-commercial PDF reader is available in source form.

TCPmsg is a non-interactive file transport system available in source form.

xtide is available from the author's web site.

wvware provides some MSWord reading tools. It is available from the wvware site.