Star Names

For navigational purposes, stars have two naming conventions: proper names such as Canopus and a Greek letter designation called the Bayer system such as Alpha Carinae, meaning the alpha star of the constellation Carina. The alpha star means most dominate, or if all are about the same brightness, the first one in a logical sequence of numbering, as in the Big Dipper, which goes alphabetically from Alpha Ursa Majoris (Dubhe) at tip of the cup to Eta Ursa Majoris (Alkaid) at the end of the handle. Officially the constellation name in this system is in the Latin genitive form (belonging to), but Alpha Ursa Major would be adequate for record keeping and communications.

Science fiction readers will likely know of Alpha Centauri, which navigators call by its proper name Rigil Kentaurus, because this is the nearest star to our solar system and perhaps an early one to visit or receive visitors from.

Figure 1. Sample of star names. The red labels have been added. Selected stars called navigational stars are assigned  unique numbers in the Almanac.

The USNO star chart above (from the support page of our cel nav text) shows how these names are used in the Almanac, sometimes using one name form and sometimes another. We see this also in the star charts from the Almanac, a sample of which is below.

Figure 2. Sample star chart from the Almanac.

Figure 3. Greek alphabet

Comparing the alphabet with Figure 1, see the points mentioned above. In Bootes, there is one dominant star and it is alpha, and the other letters are more or less random.  In the Big Dipper the stars are similar in prominence, so they are labeled sequentially along the figure. In Leo, the brighter Regulus  (magnitude 1.4) is alpha and Denebola (magnitude 2.1) is beta. The brightness of stars is specified in terms of magnitude (see Brightness of Stars and Planets.)  All magnitude-1 stars  and most magnitude-2 stars have proper names. Less bright stars typically do not.

Note on Constellations

We often think of constellations as groups of stars, but that is not the full picture. The full sky is divided up into sections with straight boundaries (SHA and Dec), much as a state is divided up into counties.  The full globe of the sky is divided into 88 constellations, which means that every point in the sky is in a constellation, even if there are no stars near it.  If you look up any constellation in the wiki it will include a nice vector image of the constellation boundaries. A sample is shown below.

Figure 3a. Outline of the constellation Ursa Major (white area).  See these for any constellation
 in the wikipedia.

Navigational Stars

There is yet another classification of stars that is crucial to navigators. The 57 stars listed on the daily pages are called navigational stars. They are also on the Index to Selected Stars in the back of the Almanac (p. xxxiii). These are bright stars, magnitude 1 or 2, but they are not chosen by brightness alone, but rather selected uniformly around the sky so that several of them will be in view at all times from any location. Polaris is notably not on that list, though it is used routinely for navigation and certainly qualifies as a "navigational star."

Figure 4. Index to Selected Stars—the navigational stars. 

This list has been on page xxxiii  of the Almanac for many years, which is easy to remember, and it is also printed on the yellow cardstock bookmark that comes with the Almanac.  Listing the stars by number and alphabetically is a handy feature of this list.  Cel nav apps, including our own StarPilot, often use these star numbers for a quick way to select a star.

There are another 116 stars listed in the back of the Almanac that do not show up on the daily pages. That full list (174 stars) includes the navigational stars, and is presented in a unique manner, illustrated in Figure 4. The first half of the year (January to June) lists the stars by their Bayer designation ("Greek-letter name"), whereas from July to December they are listed by their proper names. This can be an important nuance to know when it comes to some star ID questions. All navigational stars have a proper name.

Figure 5. Sections of two facing pages of the star list at the back of the Almanac.

Here we learn, for example, that the brightest star in the sky, Sirius, is also known as Alpha Canis Majoris, the alpha dog in the Dog constellation. It has still another name—you guessed it: the Dog Star.

Stars in this list are sorted according to increasing SHA. If you know the star but not its SHA, check the star maps in the Almanac or the USNO version linked above, which plots star locations on a Declination-SHA grid.

This list provides more stars for navigation but it is very rare that we need one from this list. The navigational stars usually carry us across the ocean. Indeed, any ocean can typically be crossed using the same few stars with the aid of a planet or two.  See a real example in Hawaii by Sextant.

 How to Pronounce a Star's Name

My answer would be, just about however you want to.  These are often complex names; many evolved from the Arabic, although Arabic speaking persons might not recognize the present form of the word. Alnilam, Alioth, Altair, are examples, as is, by the way, Alcohol. In fact, many of the prominent stars have many names, or many spellings for the same name, although there is now an official list of names and spellings as of June, 2018.  You will see that most of these were only formalized in 2016 or 2017.

The wiki has good presentations of stars organized by constellations, which include detailed maps of the constellation. Standard pronunciation guides are complex, so here is a starting point for the navigation stars, plus a few others we use in the course.  There are more alternatives than I have listed here.

Name                Pronunciation

Acamar               AH-kuh-mar

Achernar             AK-er-nar

Acrux                A-krucks

Adhara               ad-HAR-a

Al Nair              all-NAYR

Aldebaran            al-DEB-ah ran

Alioth               AL-lee-oth

Alkaid               AL-kade

Alphecca             al-FECK-ah

Alpheratz            AL-fer-rats

Altair               AL-tair

Ankaa                ANG-kah

Antares              an-TAIR-ease

Arcturus             arc-TOUR-russ

Atria                AH-tree-a

Bellatrix            BEL-la-trix

Betelgeuse           BET-el-jooz

Canopus              can-OH-pus

Capella              kah-PELL-ah

Caph                 KAF

Castor               CASS-ter

Deneb                DEN-ebb

Denebola             de-NEB-oh-la

Dubhe                DOOB-huh

Elnath               EL-noth

Eltanin              EL-ta-nin

Enif                 EEN-if

Fomalhaut            FO-mal-oh or FOH-mal-owt

Gacrux               GAK-kruks

Gienah               JEEN-ah

Hadar                HAH-dahr

Hamal                HAM-al or hah-MAHL

Kaus Australis       KOWSS ow-STRAH-liss

Markab               MAR-kab

Megrez               meg-REZ or MEG-rez

Menkar               men-KAHR

Menkent              men-KENT

Merak                MER-ak

Miaplacidus          mee-a-PLASS-id-uss

Mintaka              MIN-ta-ka

Mirfak               MERE-fak

Mizar                MYE-zahr

Nunki                NUN-kee

Peacock              pea-COCK

Polaris              poe-LAIR-is or poe-LAHR-is

Pollux               POL-lucks

Procyon              PRO-see-on

Rasalhague           RAHS-al-haig

Regulus              REG-you-luss

Rigel                RYE-jel

Rigil Kentaurus      RYE-jel ken-TAW-russ

Sabik                SAH-bik

Saiph                SAFE

Scheat               SHEE-at

Schedar              SHED-er

Segin                SEG-in

Shaula               SHOWL-a

Sirius               SEER-ee-us

Skat                 SKAHT

Spica                SPEE-ka or SPY-ka

Suhail               soo-HALE

Vega                 VEY-ga or VEE-ga

Zubenelgenubi        zoo-BEN-el-je-NEW-bee

Zubeneschamali       zoo-BEN-ess-sha-MAH-lee

My suggestion is choose a way to say it and then whenever you do say it, say it bold and clear. Anyone hearing who might have thought it was done another way would then pause, and likely take your word for it. It would be difficult in many cases to argue what is right.

For more, the definitive study of star names is the classic Victorian text  Star Names Their Lore and Meaning by Richard Hinckley Allen, which is online, being a remarkable work of Bill Thayer, formerly of University of Chicago.  There are also tons of used print copies online for a dollar or two, being the Dover edition from the early 60s. We have a copy of that one which we scanned, OCRed, and cleaned up to make an ebook long before Bill Thayer's work and also long before Google got into the practice of scanning all books.

The best stargazing program for Mac or PC is the amazing free one called Stellarium. Has a short learning curve, but is a remarkable and beautiful tool.  You can read digital values of height and bearing for cel nav studies as well.

Check Assumed Positions After Plotting Cel Nav Fix

A question about DR came up in our cel nav course that took us back to a couple basic points. One is the difference between manual cel nav solutions using tables and plotting sheets compared to doing sight reduction and position fixing with a computed solution using a computer or mobile app. We discuss most of these differences in our textbook, but realized today that one important difference is not stressed in the book, although it is covered in many places in our online course.

The issue at hand is evaluating a fix based on the dimensions of the plot itself. In other words, we look at the lengths of all the lines involved. There are two kinds of lines on the plot of a cel nav fix: the lines of positions (LOPs) themselves, and the lengths of the azimuth lines that run from the assumed positions to the LOPs (the a-values). A sample is shown in Figure 1.

Figure 1.  Crucial lengths defined.  If any of these are approaching 60 nmi long, we should use the fix for a new DR and redo the sight reduction.

The crucial lengths are the a-values, a1 and a2, as well as the lengths along the LOPs from the fix to the azimuth line (L1 and L2).  Chances of long lines is enhanced when the DR is about halfway between two whole latitudes, because we must choose one of these for the assumed latitude. 

We make the assumption in standard manual plotting procedure that the circle of equal altitude near our position can be approximated as a straight line (the LOP), and that the azimuth lines, which are segments of a great circle, can be approximated by a straight line as well.  Both of these approximations can break down if any of these lines gets too long.

Below is a new addition to textbook Section 11.24, followed by examples and background of this concern.

Evaluate Assumed Positions in Manual Sight Reductions

Before we start to evaluate a full set of sights for optimum accuracy, we should pause at the end of the sight reduction to check that our basic assumptions are in order for the sights at hand.  How we do this depends on how we are doing the sight reduction. If we are using a computer or nav app for sight reduction and position fixing,  this step can be skipped completely, because the location of the assumed position (AP) does not matter when computing a fix. With calculator solutions, we generally use our DR at the fix time as the basis of the computations, and even if the DR is way off, the programs will work around this either by solving for intersecting circles of position, or iterating lines of position (LOPs) automatically, as explained in the manual approach below. In any event the choice of AP is not a concern for computed solutions, but we must consider this when doing manual solutions using plotting.

When doing sight reduction by hand using tables and manual plotting, we must check that none of the lines leading to our plotted fix are too long. This can happen with manual sight reduction as we must choose an AP based on the minutes part of the GHA and our DR Lat and Lon. We can always choose the AP to be within 30' of the DR, but even then with various configurations of body bearings and APs, we can end up with large a-values. If the DR position was wrong by a lot, meaning the distance between the DR position and the fix found using the APs chosen properly for each sight, then the a-values can get even much larger.  In this case the distance between the fix and the azimuth line measured along the LOP can get large as well. The lines that can get too long are illustrated in Figure 1, above.

We might consider that any crucial line in our plotted fix that is over (or approaching) 60 nmi should be considered too long for best results, meaning they may violate our basic assumptions in the plotting. Underlying the manual plotting solution is the assumption that the LOP itself is a valid straight-line approximation to a segment of a circle of equal altitude (see textbook Section 10.6), and we assume that the azimuth line is a segment of a great circle, even though we are plotting it as a straight rhumb line. These approximations can break down when the lines get too long. The consequences of this also depends on the direction they are oriented, but a generic filter on the lengths should catch all cases.

The solution to long lines on the plot, is to plot the fix in the normal way, then read that Lat and Lon and call that the new DR for these sights.  Then do the sight reduction again using this DR, which will call for new APs, and then the lines will all be shorter, and the fix you get will be more accurate.

In most cases of routine cel nav—see Hawaii by Sextant for examples—we can proceed as normal, and will not find any excessively long lines, but if we do, we can fix it. On the other hand, if we suspect ahead of time that our DR could be wrong by over 40 miles or so, then we might do a quick 2-LOP fix to check the lines and find a new best DR to use before any further analysis.

The instructions to Pub 229 include a Table of Offsets for curving the LOPs to help with this correction. That table shows corrections of several miles for lines L1 or L2 of just 45 miles. Errors due to long a-values are more subtle and depend on the azimuths; they occur when a straight line approximation to the azimuth line diverges from the curved great circle tract between AP and GP.

In summary, any of the crucial lines in a fix plot approaching 60 nmi long should call for getting a new DR from the fix and redoing the sight reduction. Errors of several miles can occur without this precaution. Such errors are larger for high sights, above 70º or so, and line lengths can get enhanced when  DR Lat is about half way between two parallels.

More Background on this Topic

This section goes into more detail to look at how these errors actually come about and the sizes of them in a few examples.  At this point, you can say "I know the rule now, and I will use it as needed," and then skip this section!  

Below is a sample of the Pub 229 Table of Offsets and how it is used to make the corrections for curved LOPs.

Figure 2.  Table of Offsets from Pub 229 and their example of how they are used.

We see from the Table that for a sight that has Ho about 73º, an LOP line length (L1 or L2 in Figure 1) of 45 nmi (45') would cause an error of 1 nmi (1') on the LOP position.  At 60 nmi, the error would be much larger. All in all, it is likely faster to just get a new DR leading to shorter lines than to correct the individual LOPs this way, and with that in mind, we generally do not cover the use of the Offsets in our course.

Here is a way to approximate this correction if you might care to.

Figure 2a.  We see the 0.9' at 72º in the Pub 229 table, and then can estimate that at 100 nmi, the correction would be about 4.6'. ( To be redrawn when we can. )

Errors due to large a-values are a bit more subtle and there is no easy table for the correction. The situation is illustrated in the graphics below, starting with cel nav data from the USNO.

Figure 3. Cel Nav data from starpath.com/usno.

The Mars and Markab sights are plotted below in OpenCPN, using a neat feature of that program that lets us plot a line segment as rhumb line or great circle, or both.

 Figure 4. Geographical positions (GP) of two bodies showing the great circle track to them from the assumed position (AP). 

Here we see an interesting example of spherical geometry.  From this AP at this time, we would actually be looking just north of west to see a star that is a long way south of us!  The direction we look to see a star is called its azimuth, 279.8 T to Markab in this example. This azimuth generated in the sight reduction process is numerically the same as the initial heading of a great circle (GC) track from the AP to the GP.  Below we expand the section near the AP.

Figure 5. Deviation of a rhumb line along the initial heading of a great circle track.

In the case of Markab, we would plot the azimuth line in direction 279.8, and then plot the LOP perpendicular to that line. However if the a-value is ~60 miles or so long, this line is some 4 nmi off the GC track as computed in OpenCPN. This, in itself, would not matter, but the offset will effectively rotate the LOP by some small amount. In this simple picture the rotation would be arctan (4/60) which is about 4º—but this example overestimates the effect. We get a better feel for the effect by breaking the GC track down into smaller steps, which is easy to do with a program like StarPilot.

Figure 6. Start of the great circle track to Mars from the AP in 0.25º of Lon steps (~ 12 nmi).

In this example we see that an a-value of 85 nmi would yield an LOP that is rotated by 1º off the true orientation.  This could lead to a relatively large fix error if the lines L1 or L2 were also large.  On the other hand, a quick redo of the sight reduction using new DR removes this error.

A real example

As a practical example that includes a bit of each of these long-line errors, we look at  Problem 8 from the real sight data included in Hawaii by Sextant (HBS).

Figure 7. Sample sights from HBS.

In this voyage and the documentation of it, we did a running fix between two sun lines taken at 1102 and 1334, which led to the fix labeled FIX 1334.  For now, we do not care about running fixes and just treat these two sights as if we were dead in the water.  That would lead to the fix marked with a red circle, where no line was advanced.  That is the fix we are studying in light of the fact that L2 from the 1334 sun line is indeed over 60 nmi long.

In the next picture we used the 1334 fix to get a new DR and then did the sight reduction again, using Pub 229 (without any offsets). That is shown below with the new APs.

Figure 8. Redo of Problem 8 sight reductions with new DR position.

The red data are the original plotting using original APs shown in Figure 7. The green plotting is the new fix using the previous fix position as a new DR. You can view both work forms to see where all the numbers come from.

This correction moved the fix by 3.5 nmi, which is a significant amount if we are striving to get the best possible cel nav fix.

______

To follow up on the point that these long-line problems do not arise in a computed solution, we look at a computed solutions using the raw data from the initial sights, including the inaccurate DR.

Here is the raw sight data of the two sights and the computed LOPs 

using 1802 DR 36º 31' N, 133º 28' W. Times in UTC

July 10, 1982, HE = 9 ft, IC=0, 

18:02:02, Hs 49º 24.5',   a = 21.5' T 098.0

20:34:46, Hs 74º 42.0',   a = 10.7' T 158.0

For a fix at 36º 27.8' N, 133º 01.6' W.... which is what we got by plotting, but only after one iteration of the AP.

In other words, again, if you compute the fix with a standard navigation program you do not have to worry about this factor.  The crucial feature of a proper cel nav program is it will iterate the results automatically that we are illustrating here manually, meaning it gets a fix from the user input DR, then replaces the DR with the fix, then computes the fix again to see if it changes, and it if did, it repeats again till there is no change. Alternatively, a program can intersect the two circles of position directly and not use any DR at all.

_____

As a closing note on this topic, in the informational section at the back of the Nautical Almanac, called Sight Reduction Procedures: Methods and Formulae for Direct Computation, in Section 11, Position from intercept and azimuth by computation, they address the topic we covered here. 

They propose that the distance to be monitored (equivalent to our fix to AP) should be less than 20 nmi and if not, change AP to fix and recompute.  They can afford to make the distance smaller because they are computing the solution, as we noted that all programs do.  When doing it by hand, we can stick with the "anything approaching 60 nmi" for our trigger.

Does Accurate DR Matter in Cel Nav—Verb vs. Noun

When doing cel nav by traditional books and plotting, we often stress that our choice of the assumed position (AP) based on our DR position does not matter—we can always find out where we are; we do not have to know where we are to find out where we are. Once we have a fix, we can then look over the plot to see if we might gain accuracy by redoing the AP, but this is not often called for.

In other words, we do not need an accurate DR position to ultimately get an accurate fix.  Indeed, at the end of this note, we will illustrate this by doing a fix in the middle of the Pacific using the Golden Gate as our as our initial DR position.

This reasoning rather quickly brings up a conflict that sharp students spot immediately. And, indeed, we got this vary question again just recently. Namely, do we need accurate DR for cel nav? Let's answer the cel nav part first, because more broadly speaking accurate DR is the absolute fundamental aspect of all navigation,  especially ocean navigation. We address this topic numerous places in our textbooks and courses. The short answer for why is simply that no matter how guarded, all or parts of our electronic nav aids may fail us, in which case we must depend on our DR, and if we have not practiced it, we will never know how well we can do it.  Or, when relying on cel nav, it could well be cloudy at the time we depend most on navigation.

So accurate DR is fundamental to good navigation, but to get specific about its role in cel nav, we have to look at dead reckoning or DR as a verb, meaning how well am I doing the process of dead reckoning, versus DR as commonly used to refer to a DR position, which is a noun.

As far as getting an accurate cel nav fix, DR as a noun, i.e.,  how well do I know where I am when I start, does not matter at all. See example at the end.

But once we start moving, then all fixes are running fixes, and the accuracy of the fix depends on how well you know how you are moving, which is DR as a verb.

In other words, to get an accurate cel nav fix when moving, I do not need to know where I am—i.e. I do not need an accurate DR position—but I do need to know how fast I am going and in what direction, and I must have some estimate of current and leeway, which means I need to know good DR as a verb.

____________

An example showing that DR position is not crucial to a cel nav fix. Below are the two sights taken well offshore used in a different post, but this time we start with our DR position artificially set at the Golden Gate, which leads to large a-values.  You can view all work forms to see where the numbers come from.

 Figure 1. A grossly wrong DR leads to large a-values that require an expanded plot.

To accommodate the large a-values we make an exaggerated plot sheet with latitude parallels set at 6º apart. This generates a fix marked FIX GG1.  We then use that fix to improve the DR and do the sight reduction again, shown below.

Figure 2.  Using the Fix from Figure 1 as the new DR, we get very close to the True Position.

We cannot see quite yet how close we are, which would take another plot on a different scale, but we are close, and certainly one more iteration would be enough to get an accurate fix.

Refer to the work forms to note that we are not quite there yet.  The fix is still about 10 mile off, and indeed one a-value was over 60 nmi, which is our flag to redo it.  Then we do one more iteration and get right to the true position.

In this example, it took 3 iterations of manual plotting starting from a DR that was about 500 nmi wrong. Had we done this analysis with a computer program such as the StarPilot, we would home in immediately. In passing, I note that we show elsewhere that it is really difficult to get lost by 500 nmi, even much less than that takes effort when you are conscious the whole time. In other words, what do I have to do in my own boat for how long to not know if I am in WA or CA?

A more practical example of checking that the APs are close enough for a good fix is discussed in the article linked above ( Check Assumed Positions After Plotting a Cel Nav Fix ).

Moving Files Around on an iPhone and iPad

In a recent post I discussed a slick way to transfer files among iOS, Android, PC, and Mac wirelessly at sea (away from the internet)—or at home as needed using your normal wifi connection. The process works great, and away from the internet you can use any local network of your own. The Iridium Go device creates such a network, as does the RedPort Optimizer and the Ocens SideKick—the latter two being devices used to wirelessly share files downloaded from a sat phone to apps on other devices.

We also show (in a video linked in the post) that the $20 HooToo portable router does this job fine if you do not have any of those satcom instruments, and it is literally plug and play. Just use the USB cable provided to plug it into your computer or a phone charger, and you will see, in the wifi setup of all devices in the room, a new network (TripMateNano-xxx) that you can use to share files.

At this point, if you only care about Apple products (iOS devices and Mac Computers), you are done.  Connect all devices to your local network and use Airdrop to move them around.

The bigger challenge is connecting PCs and Android devices into the Apple devices, and that takes a couple extra easy steps.

We also need a free app from the App Store to carry out the transfers. There are several free options. Such things are also numerous on an Android system. Transfers then work among iOS, Android, PC, and Mac... or whatever else you have with a wireless connection option.

The only snag in this system, it turns out, is handling the files within the iPhone or iPad itself. This step is tied to the app you choose to do the transfer.  The first free app we tried (described in the post) worked fine for a while, then failed.  Now we have found a better one called, fairly enough, File Transfer App.  Also free, and so far I have not seen any ads.

Having now attempted several videos to illustrate moving files around in the phone, I realize we need an outline of what it involves and a review of how the phones work with files.

• Phones deal with photos and videos in a special way. Generally if they see anything with an image or video extension they try to force it to the Photos directory on the phone.  That is not a problem, because all of the transfer apps we are dealing with assume the main thing you want to transfer is photos, music, and videos so they have this all dialed in. Usually with special buttons for each of these and then another button for "files."  The navigator can need to transfer images, but we are mostly involved with files: GRB, GPS, TXT, PDF, etc.

• The primary app for moving files on an iOS device is called, simply, Files. I believe this is a stock app that comes with the iOS, but not sure since this one can be deleted, and most stock apps cannot be deleted. If Files is not there (a blue folder icon) then it can be downloaded from the App Store.  The attached video shows the use of this app.

• We also must be aware that there are only certain iOS apps that can work with external files. Any GRIB viewer app is an example, as they download and display GRIB files and then save them, and some offer the opportunity to share these files. A navigation program is another example, as they can create and then share GPX files of routes, tracks, and waypoints. Likewise some can import a GPX file created elsewhere. And the Mail program is another one that can send and receive attached files.

• Some but not all apps that work with external files provide access to them through the Files app, but many others do not, i.e., ebooks apps Kindle and Apple Books keep books in their own private libraries.

• Email attachments such as GRIB files from Saildocs can be transferred without using the Files app.

• In fact, any file in the phone that can be shared can usually be done without the Files app, but the Files app is often a convenient holding tank.

• In many cases the extension of the file is associated with an appropriate app on your phone. This facilitates some aspects of moving files around.

If we get, for example, an email attachment with extension .pdf, then a long press on the attachment will reveal a list of all the apps that can read a PDF file. When you choose to open the PDF in Adobe Digital Editions (ADE) for example, it will copy that file into its own library. On an iPhone—in contrast to an Android phone—that then is a dead end for the file. You can access it from the ADE app but can't move it from there, only delete it.  If you had subsequently deleted the email that had it as an attachment, then that file is gone.

What you can do is, instead of immediately loading into a specific app, save the file in the Files app, just putting it any convenient folder. Then from there you can open it later in any of several apps.

The contrast with Android is, we can go into the Android file directory and see where ADE is storing their library files, and so on, which is not doable in an iOS device.

• The other two videos show how the transfers work, the main step left to cover is the preparation of the files in the phone so the app can send them. Here are some scenarios to be demo-ed.

1) Import a GRIB file as an email attachment and move it LuckGrib folder or open it directly from the email.

2) Transfer a LuckGrib GRIB file to a transfer app so it can be sent to a PC.

3) Move a Bad Elf GPX track to Files app then share it to MotionX GPS

4) Take a screencap or photo and send it to the Transfer app via Files app (only option).


A video demo of the above 4 operations.