Actual corrections are in red.
(p. 16) Transferring files from one computer to another: One method I use is to copy them to a 32-GB SD card. However, the default file system (FAT32) will not accommodate files larger than 4 GB, so you must format the card as exFAT or NTFS instead (which also makes it faster). With exFAT there is a further problem that some Linux systems do not timestamp the files correctly when Daylight Saving Time is in effect. NTFS works reliably, but then the card cannot be used in digital cameras, only computers.
(p. 47) Nikon Manual Movie Settings:
|to:||1/60, 1/50, or 1/30|
This bug has not been fixed in D5300 firmware 1.01, 1.02, or 1.03. Manual Movie Settings still needs to be turned off when you are doing still photography with Live View.
(p. 82) Dark frames: When taking dark frames indoors, particularly for sensor testing, note that your lens cap may not be perfectly opaque to infrared light; also, a tiny amount of light can enter through the eyepiece. It is best to take dark frames in the dark.
(p. 85) Acquiring flat fields: There are two problems with using the daytime sky as the light source. One is that the color is so bluish that one risks overexposing the blue pixels while inadequately exposing the others. The other is that when first set up in the daytime, the telescope is not focused on infinity, unless you can focus it on the moon or a very distant terrestrial object.
Ten years ago, it was common to decolorize the flats by binning (averaging) pixels 2×2. We now know that one of the important functions of flats is to compensate for differences between individual pixels, not just dust motes and vignetting, so this is no longer recommended.
Currently I'm using an LED-illuminated, USB-powered artist's light box as a light source for flats. If you use an 8-inch (20-cm) telescope, bear in mind that some "A4 size" light boxes are slightly more than 20 cm wide, and some are slightly less; you'll need one that is bigger than the telescope objective, of course.
(p. 108) Lens quality: One of several good sites for published tests of newer lenses is www.lenstip.com. Their plots are not MTF curves, but rather the resolution at which 50% MTF is achieved, plotted versus f-stop. You want the center and edge readings (red and blue dots on the graph) to stay close together so that star images will be round. Most lenses nowadays are sharpest wide open or nearly so, and resolution falls off at higher f-numbers; that is normal. The publishers of this site are harsh critics of lens quality (just like us), and they share my impression that many of the best lenses are made by Sigma.
(p. 158) A futile quest: See note to p. 160.
(p. 158) Noises from mounts: One aspect of mount performance that I didn't mention is noise. Computerized mounts with servo or stepper motors can make strange noises and move in irregular jerks when slewing. Noises mean nothing unless there is actually a problem with tracking performance and the noise is correlated with it. Some mounts squeal, hum, buzz, creak, and alternately fall completely silent at unpredictable times while tracking. As for irregular jerks, when the mount slews from one place to another, an algorithm manages the motor acceleration, and sometimes the criterion for using a higher speed is fulfilled for only a fraction of a second. As long as the telescope ends up pointed correctly, the noises it made getting there are of no significance.
(p. 160, bottom) Unguided subs: The length of unguided exposure that you can make with a particular mount is not inversely proportional to focal length. For example, if you can go 2 minutes with a 100-mm lens, that doesn't mean you can necessarily go 1 minute with a 200-mm lens.
The reason is that periodic error is an oscillation, not a steady drift. The error in a 2-minute exposure is anywhere from 1 to 2 times that of a 1-minute exposure, depending on the waveform. At shorter focal lengths, the error can be completely invisible no matter how long you expose, and then, at a particular focal length, it suddenly starts to make a difference even in short exposures.
There is a proportionality, but it only works in one direction. If you can expose 1 minute with a 200-mm lens, then you can expose at least 2 minutes with a 100-mm lens, possibly more, possibly a lot more.
(p. 161) Backlash: Celestron tells me there can easily be 60 arc-seconds of backlash in the gearbox (not the worm gear); this is normal, and no adjustment of the worm gear will affect it. They also say that when the mount is deliberately unbalanced for better tracking, it is acceptable for the unbalance to be so large that the telescope actually moves when brakes are released.
Celestron's specification for total backlash on a mid-sized German equatorial mount is 60 to 180 arc-seconds. Zero backlash is not the goal.
(p. 165) Communication with the mount: Regarding INDI see second note to p. 189.
(p. 165) INDI and Windows:
|change||as well as Windows.|
|to:||and can be bridged to ASCOM under Windows.|
(p. 166) When autoguiding with a color camera, bin the pixels 2×2 if possible, to eliminate the Bayer matrix.
(pp. 185-6) Alternative to lamp cord: The ideal power cable would be the same size (of wire and insulation) as lamp cord, but more flexible thanks to silicone insulation (rather than PVC) and wires made of many very thin strands. I've found a supplier of such wire, BNTECHGO, in China, and their product is available on Amazon at this link. Do not confuse it with other BNTECHGO products, nor with red and black "zip cord" from other sources.
(p. 189) Linux is better supported with every passing day: For greater long-term stability, many amateurs (including me) are migrating to Linux for telescope and camera control (a process I have nicknamed "defenestration"), and the available software is getting better rapidly. Open PHD Guiding (PHD2), FireCapture (for video), and KSTARS (for star maps), and especially Ekos (for camera and telescope control) have free Linux versions. PixInsight supports Linux and macOS as well as Windows.
(p. 189) Telescope controller need not be a laptop: If you're going to have a dedicated computer for your telescope, autoguider, and camera, it need not be a laptop. The latest trend is to use a very small computer that rides on the telescope and is accessed remotely.
The small computer may be a Raspberry Pi or an Intel Compute Stick, but ready-to-use solutions are becoming commercially available. One is the Stellar Mate, much cheaper than a laptop. The computer is small enough to ride on the telescope, runs on 5 volts, comes pre-configured with suitable software, and totally frees you from worrying about whether your main computer will remain compatible with your equipment-control software. Stellar Mate runs as an INDI server, which interfaces with your equipment and enables you to control it with Ekos or other software from the computer you are sitting at.
(p. 202) PixInsight dark frame optimization should not be used if the sensor has appreciable amp glow. It assumes the dark frames are genuinely dark.
(p. 212) DeepSkyStacker calibration:
|change||On subsequent runs, it uses the master frame to save time.|
|to:||On subsequent runs, you can select the master frames rather than the whole set of calibration frames, to save time.|
(p. 295-297, 302) Dynamic range as reported by PhotonsToPhotos is not the same as reported by DxOmark (even when derived from DxOmark data). PhotonsToPhotos uses a different SNR limit and produces values that are about 2.5 stops lower.
(p. 302) Formulae for dynamic range:
|change||Bias = the average (or preferably median) of the dark frame|
|to:||Bias = the average (or preferably median) of the flat dark|
There is no dark frame other that the flat dark already mentioned.
(p. 304) Here is Table 16.1 with a third-generation Canon added, the 200D.
I don't plan to keep adding to the table indefinitely, but this step in technological progress is noteworthy. The Canon 200D is ISOless but has more read noise than the Nikon D5300 — and we don't know if this reflects a real difference in sensor technology or if the Nikon performs some noise reduction in the camera before writing the raw file. In general, past experience is that Canon raw images are "rawer."
(p. 308) Filter modification can bring out chromatic aberration in lenses. This point needs to be emphasized. With my Nikon 180/2.8 ED IF (non-AF) lens on a modified camera, the stars have bright red haloes. With some other lenses, it is necessary to "focus out" the red haloes, and the star images are not quite as compact as with an unmodified camera.
(p. 309) Benefit from filter modification: Here is a more dramatic example than the one shown on p. 309 and on the back cover.
These are the nebulae NGC 7822 (top) and Cederblad 214 (bottom) (conflated with NGC 7822 in some older catalogues), very thin red emission nebulae. Both are stacks of ten 2-minute exposures, taken in town (not at a dark-sky site), with the same 180-mm lens at f/4. Because the sensors had different size pixels, the scale does not match exactly.
Left: Nikon D5300, unmodified; right: Canon 60Da, which comes from the factory with a special filter for greater hydrogen-alpha sensitivity.
(p. 324 Fig. 18.5) Incorrectly reported orientation in Astrometry.net: This problem seems to have been corrected in the version of the software that is now on the nova.astrometry.net server, but I still advise caution. It has not been corrected in the versions that are available for you to run locally. The problem apparently arises from some ambiguities about the orientation of FITS files, and other files are converted into FITS for processing. What you really want, of course, is to identify objects and determine the arc-seconds per pixel, and those always come out correct.
(p. 324) Unreliability of astrometry.net web site in November 2018: As this is written, the web site is dealing with hardware failures and is only partly functional. New York University, which hosts it, plans to restore full functionality, but you may want to run the software locally (see below).
Running Astrometry.net locally under Linux:
The following is how I got it working under Linux Mint; the
same procedure works under Ubuntu, Debian, and Windows Subsystem for Linux (Bash on Windows).
(1) Acquire and install the Debian package:
sudo apt update
sudo apt install astrometry.net
(2) Install the index files of star positions:
sudo apt install astrometry.net astrometry-data-2mass-08-19
sudo apt install astrometry.net astrometry-data-2mass-07
sudo apt install astrometry.net astrometry-data-2mass-06
(3) Example of solving an image:
solve-field --downsample 2 -L 0.1 -H 180 myfile.jpg
Here --downsample 2 means to downsample the image before solving (this will not affect pixel size calculations; omit it if the image is small, and change it to 4 if the image is large). The parameters-L 0.1 -H 180 tell the software the field is between 0.1 and 180 degrees wide; you can save time by giving a more precise guess.
You'll get dozens of messages saying that a certain set of objects at a certain scale "did not solve" — that is normal. Eventually, if successful, the program will write out several files. The most important are myfile-ngc.png (the annotated image) and myfile.wcs (coordinate information). You can render the latter into readable text using the command:
The other files are disposable. Most of them are FITS format data files but do not contain viewable images.
See also /etc/astrometry.cfg for configuration settings that you can change, and use the command man solve-field for very concise instructions.
Note that the Debian-packaged version does not identify NGC or Messier objects, only bright stars. That is because of copyright problems with the NGC catalogue that is bundled into Astrometry.net — the Debian repository system does not consider it legal to distribute. Simply adding the files does not help; the software compiled for Debian does not use them. Instead, you can go to https://github.com/dstndstn/astrometry.net, get the source code, and build the software yourself, or use one of several Windows plate solvers that use Cygwin and include the full set of files. I hope to add more information about this.
Back cover: See note to p. 309.