Astronavigation (Celestial Navigation) for Beginners

Knowing one's way around the night sky is a useful thing, if, like me, you have a telescope and want to know where to point it, or if, like me, you have ambitions to learn astronavigation. Until last week, sunset came early enough that I could get a few minutes of practice on every clear evening, standing in my garden and counting out the stars. This time of year, the orangey-red light Arcturus is usually the first that I see; the distinctive blue blaze of Vega is to the east, and when the sun's glow has faded a little more, Pollux, Castor, and Capella (actually 4 stars, an exotic double-binary) show up nicely.

The stars that I am really watching for, though, are Polaris (the north star) and Etamin; obviously, Polaris is very useful, in that it gives a navigator a course to steer anywhere in the northern hemisphere above maybe 10 degrees of latitude (ish) - but why my interest in Etamin (gamma Draconis)? Well, it so happens that my home port on the eastern seaboard of the north Atlantic is just a smidgen north of Etamin's declination (celestial latitude), which is 51 degrees, 29 minutes, 20 seconds. Now, Polaris has the useful feature of always (where always = "several hundred lifetimes") being 51 degrees and X minutes above my local horizon; Etamin, by contrast, whirls around the sky, never dipping below the horizon, but once per day passing through the zenith - what you might call "Etamin-noon".

In practical terms, this means that were I some day to be lost in the blue vastness of the North Atlantic, no GPS, compass, sextant or chrometer to guide me home, I could use Etamin to find the latitude of home, sailing north if Etamin passed north-of-zenith, and sailing south if it passed south-of-zenith. Once at the right latitude, I would need only to keep an easterly course, and a sharp look-out for pointy rocks. Of course, measuring the fixed, non-whirling altitude of Polaris is more convenient - it can be done whenever Polaris is visible - but that would require an instrument, ideally a sextant. Marvin Creamer, an American amateur sailor and retired professor of Geography, once sailed around the world on Globestar using techniques like this and no instruments whatsoever, making surprisingly accurate landfalls.

Unfortunately, during part of the year, Etamin-noon would fall during daylight hours - but even then, other bright stars at similar latitudes could give useful hints. Which bright stars pass directly over your home port / next port? Just follow the linked query at Wolfram Alpha to see a table listing the hundred brightest stars by declination, and you'll soon be on your way. A useful tool to help you practice is the (totally free) Mobile StarChart, a java applet you can install on your mobile phone - it only has about thirty star names, but is open source, so you could add more.

Living a long way from the sea? Astronavigation can also be pretty useful in the desert, and was much practiced by people like Popski. Must learn how to use a sun-compass one of these days.

Designing a new rudder

So, our beloved Briongloid, a 6.6M fin-keeled sailing yacht went adrift from her mooring, and spent an uncomfortable day bouncing on pointy rocks. The pounding reduced her wooden rudder to matchwood - so it's time to make a new one.

How big, and what shape? From a profile scale illustration of a Pandora International (our boat's model) I figured out the height and width - about 1.65 metres * 0.37 metres. Now, I just needed the cross-section's shape.

It turns out that the best shape for a rudder is a foil - like the shape of a bird or aircraft wing, the magic of the foil shape is that it generates lift (unlike, say, a flat surface, which only creates drag). Back in the 1930's, the boffins at NACA, the forerunner of NASA, investigated different foil types to find the best shapes for different aeronautical (and incidentally marine) applications.



For relatively slow-moving displacement craft like our yacht, their "NACA 0012" foil is the best fit; by creating a Google Calc document based on the NACA 0012 formula, I generated the cross-section above (y and x axes are not in proportion). Note the very round leading edge and thin trailing end.

Many fins and rudders taper from one end to the other, and give the leading edge a crescent profile; this tapering reduces drag by about 4% - for me, not worth the much-increased difficulty of shaping the foil.

This post is part of a series on making a fibreglass rudder with a foam core:
Designing a rudder, part 1
Designing a rudder, part 2
Making a rudder, part 1

Review: Imray Chart Plotter (ID30)

In the current economic climate, the demand for my services has decreased; so, less cash. Luckily, this also means more time for sailing. I'm planning a little cruise westward, which (winds permitting - hah!) will take me off the edge of my chart folio. To help my planning, I bought my first digital charts and charting software, Imray ID30, covering the west coast of England, Scotland and Wales, and the whole of Ireland. Usefully cheaper than their Admiralty equivalent (and discounted further for this Euro purchaser by the weakness of Sterling), the CD arrived promptly from those nice people at Marine Chart Services.

On first running the software, users need to register; the first step involves giving an address that must include a postcode. The tiny country I live in doesn't have those anywhere outside the capital, and even then, they aren't in the UK format which this officious little dialog demanded. After some trial and error, I discovered that "--- --" was an acceptable location(!).

Lovely coordinates, but what's the distance?

My first impressions of using the actual chart plotting software itself are that opportunities have been missed - for example, a simple tool like dividers doesn't work quite as well as it could. In the above example, I'm trying to measure the width of the anchorage at Port Magee (on Ireland's lovely south west coast). Ideally, the measurement text box would come out from its hiding place - an easy fix could be "borrowed" from CAD tools and their dimensioning widgets.

A bigger problem is (how ironic!) navigation - moving across a chart takes ages, not because the software is slow (it isn't), but because charts are often many screens wide. A zoomed-out overview in a small overlay window to show the wider context of the currently visible portion of chart would be a nice addition.

My biggest beef, however, is with chart selection. Although the "default" chart covers the full range of the folio, selecting detailed charts for harbours and so on requires browsing a list which identifies them by codes and place names. I understand the reason for this; it is the easiest way to move paper charts to a digital platform. However, it does little for usability, and isn't likely to find favour with users who are familiar with modern digital mapping, as implemented by the likes of Google Maps, Map 24, etc. Why can't I go from a whole-Ireland view to a close-up of the Cork Harbour chart in one click?

Enough with the negatives; the charts themselves look good, and I got a lot of mileage for my money - the sheer amount of data that must be collected to make these charts is astonishing. I'm already looking forward to plotting my next cruise (and with departure mere weeks away, it's not before time!).

Favourite feature so far? Definitely the print option - beautiful, instant reproductions of charts or sections of charts are only a click away (after you accept the "not for navigation" license agreement message).

The verdict so far: excellent value for money. The software is spare, but very functional, and the coverage is great, and I'm very glad I bought it.

Cleaning a microwave oven

The levels of dried-out burnt-on food on the roof of our microwave oven were well below bachelor-tolerance levels, and, considering the dose of radiation they had received, either totally sterile or already in possession of super powers. However, with my wife due back the next day, a fab-like level of cleanliness was highly desirable...

The first attack (dish-scrubber) was easily repulsed; the fossilized remnants of dinners past appeared to have attained an inter-molecular level of integration with the substrate. Doubled the elbow-grease factor, tried again, same result. Next, considered the array of chisels, lump-hammers, power saws, angle-grinders available to me, but rejected them on grounds of safety (mine, on the return of She Who Must be Obeyed). What to do?

Then, the light bulb moment. I got a bowl full of water (just water), deployed it to the centre of the oven, and gave it 8 minutes at 800 watts. Opened the door again to a steam-blasted oven that came clean on the first wipe. Result!.

CPU Hog

So there I was, tapping away at quotidian tasks, when I noticed my PC was responding with all the dash and verve of a fossilized member of Testudinidae. A quick glance at Task Manager showed that GoogleDesktop.exe was the CPU hog - apparently, it required 99% of CPU to index the work I was doing with the other 1%. Surely that couldn't be right?

Well, I love the speed and power of Google's Desktop search, so I didn't like to just kill the offending process. To get me a little extra responsiveness from my PC while I searched for a better fix, I using Task Manager to give the GoogleDesktop.exe process a lower priority. To find the real problem, I would need more data on what GoogleDestktop.exe was trying to do - so I installed the impressively capable and friendly Process Monitor (a free trouble-shooting tool from Microsoft).

This tool gives details on the interactions of running processes with the operating system, and updates in realtime. For example, I could see GoogleDesktop opening new files and folders to index them even as I created them. What was interesting was that GoogleDesktop.exe was also repeatedly accessing a file called hes.evt, even when there was nothing new to index. I deleted this file, and an instate later, a new hes.evt appeared (at first I thought it hadn't been deleted, but the new one was tiny and had an up-to-the-second creation date).

And now... CPU usage fell away to "idle" levels, and Google Desktop Search still works. Great result, but what was the underlying problem? No idea whatsoever.

Finding dolphins and whales

I've covered quite a few kilometres looking for whales and dolphins, and I have decided that I am doing it wrong. The sea is very, very big, and from my deck I can scan only a very limited area. Even worse, the animals that I am trying to find spend much of their time submerged - I should be looking under the water, not over.

I've heard whales and dolphins on hydrophones before, and it was possible to get a sense of range simply from the volume. You can hear them a long way off, too - loud animals, and sound carries very well through water. What I think was missing from the experience was stereo - with stereo, it should be possible to estimate the direction from which the sounds are coming - and so steer closer.

What I would like to do is to trail two hydrophones astern of Briongloid and hook them up to a pair of stereo headphones. Now, sound travels much more quickly through water than through air, which might make it hard for the brain to process the data fast enough - but a simple fix for that would be to increase the spacing between the hydrophones so that the time sound takes to get from one to the other in water matches the time sound takes to get between human ears in air.

Since Briongloid is usually powered by sail (rather than a noisy engine), I imagine it would be possible to trail my pair of hydrophones throughout a voyage, monitoring constantly for cetacean activity. Interesting idea: now how do I actually go about building such a thing?

Error Propagation: an unexpected beauty

So, say you have a couple of measurements, x and y, with some associated uncertainty; the true value of x might be, say, 3 units above or below the measured value, and the same for y. The problem I'm currently working on required me to propagate error through several stages - and also to have a maintain a "confidence value" for that error (i.e., a probability that the observed error will not exceed the predicted limit).

It turns out that there is a little mathematical nook crammed full of simple and useful methods for dealing with exactly such a problem; a helpful colleague introduced me to "Error Propagation" (see link for handy formulae). The amount of error expected in x (up to 3 units) is termed dx, and similarly for y. In choosing dx, you are not really saying (contrary to what I first thought) that dx will never exceed 3 units; instead, you first decide how sure you want to be that your error won't be large enough to surprise you - say 95% - and then choose a value for dx that will rarely (1 time in 20) be exceeded. For x + y, the expected error of the result, d(x+y) is given by this very familiar formula:

d(x + y) = (dx^2 + dy^2)^1/2

Seems like that formulat is familar? Yes, Pythagoras all over again - dx and dx are now the first lengths of the first two sides of right-angled "error triangle", and the result is the length of the hypotenuse... wow, we started with probability, and now we have a result that can easily be expressed geometrically. Unexpected and beautiful!

What if you want an error value that will never, ever be exceeded? Then you'll need a much larger dx; to get, say, a confidence of 99.99%) you will need dx to be at the fourth standard deviation (see Wikipedia on "normal distribution"). The trouble with certainty is that it costs - you might have to increase dx quite a lot to reach that level, assuming your error is normally distributed).

The really neat thing, for my particularly application, is that once you've chosen dx and dy with a certain confidence, then d(x + y) will have a matching confidence: set the confidence for the input, and your output - umpteen calculations later - will have the same confidence for its error value. Time to go play with code and see if I really understand all this...