Category Archives: Astrophotography

Planetary astrophotography on a low budget

This posting talks about the key equipment needed to do planetary astrophotography on a low budget. For deepsky astrophotography on a budget, a barndoor mount is a better starting place.

One of the first surprises when learning about planetary astrophotography is that you don’t actually want to capture images. Instead, standard practice is to capture videos of the objects in question, a minute or more in length. These are then processed with a variety of applications to produce an image that is far higher in quality than what you could get if you tried to directly capture a still image. So in terms of equipment, what is needed is a telescope and a video camera of some kind.

The Camera (Modification)

There are plenty of video cameras designed explicitly for astrophotography, able to capture either monochrome or full colour images. For a monochrome camera, coloured filters are used to enable separate videos to be recorded for each colour channel. Dedicated astrophotography cameras are at least £100, often much, much more. As a beginner it is hard to know what will be the choice to start with and even whether the interest in astrophotography will stick. The low cost route is to thus go DIY, which involves taking a regular computer webcam and modifying it to make it suitable for astrophotography. There is an enormous selection of USB web cams on sale in the shops, and an even bigger selection second hand on eBay. Some are more suitable for astrophotography than others, so it pays to do a little research on the forums to figure out which have proved effective. Almost every forum thread on the matter will at some point recommend the Philips Toucam, but these are long since discontinued and postings on eBay sell for an unreasonable amount of money.

A little research, suggested that the Microsoft Lifecam Cinema HD is a good contender, and can be had on eBay for as little as £20. This is capable of capturing at a resolution of 1280×720, which is actually higher than many dedicated astrophotography cameras. It is worth pointing out though, that resolution is not king as the individual pixel size, low light sensitivity and noise characteristics all have a huge impact on the end result. The appealing quality of this particular model were the detailed instructions Gary Honis has written about the modifications needed to make it suitable for astrophotography. The images of Jupiter he posted give an indication of what the camera is capable of. Incidentally his website is a fountain of knowledge when it comes to astrophotography camera modifications.

Microsoft Lifecam Cinema HD, as sold

Microsoft Lifecam Cinema HD, as sold

In essence the mod requires stripping off the case to expose the camera assembly and circuit board, followed by very careful surgery to remove the lens and infrared filter, thus exposing the bare CCD chip. Part of the case is then re-attached before fitting it into a 1+1/4″ cylindrical case the same size as a telescope eyepiece. Gary used a pair of eyepiece extension tubes, but the UK company Billet Parts sells a plastic case custom designed & machined for astrophotography mods of the lifecam cinema. If there website shows out of stock just email them and they’ll produce another batch. Highly recommended, as it comes with a dust cap too.

Microsoft Lifecam Cinema HD, modified

Microsoft Lifecam Cinema HD, modified

One final point is that the CCD chip is sensitive to infrared and the built-in IR filter was removed during the modification. So for doing normal colour imaging of planets, a replacement IR filter will be required. Any standard 1.25″ eyepiece filter can screw into the custom billetparts case, and suitable 1.25″ IR filters can be had for about £20-25 online.

The Capture Phase

With the camera chosen (or built), the first actual step in producing an image is to capture a video. When targetting Jupiter, it is generally recommended that video captures be no more than 2 minutes in length, otherwise features will begin to suffer from motion blur due to its high speed of rotation. If capturing the 3 colour channels separately with a monochrome camera & filters, that means each individual channel is limited to no more than about 40 seconds (and that assumes you have a filter wheel for fast changes). When targetting the Sun or the Moon, it isn’t necessary to worry about rotational speed of the target, so videos can be as long as desired.

For video capture on Linux, the open source program guvcview offers full control over all the camera settings and the video codecs used, which is an important requirement for astrophotography. Maintaining maximum possible detail/quality in the initial video is key to being able to bring out good details in the final image. Critically, transcoding the video from one format to another is to be avoided, as this will usually loose information. The goal is thus to capture in a format that the video stacking application will be able to read directly. The best choice is thus an AVI file, ideally with raw uncompressed codec, or failing that something common like MJPEG. Before going out at night to capture something important, do a quick test capture of 15 seconds and try to load it into the stacking program you intend to use, to verify that it can indeed understand the codec you chose. Using raw uncompressed video results in massive file sizes even for a 60 second capture and may have a lower maximum frame rate; MJPEG is inherently throwing away detail so can compromise the final image quality but allows for higher frame rates. The frame rate is fairly important as the more frames that can be stacked the better the final image will typically be. Pick your poison.

Accurate focusing of the telescope is also a very important factor when capturing the videos. Slight mistakes in focusing can really badly impact the final result. It is worth investing in a focusing aid like a Bahtinov mask for your telescope instead of trying to judge it by eye. While you can make your own, another UK company Morris Engraving produces high quality masks from toughened black acrylic, custom designed for every telescope you’re likely to need, at a very reasonable price on eBay. Again, highly recommended.

Bahtinov Mask

Bahtinov Mask

I am using a Celestron Nexstar 4 GT telescope, which is a Maksutov Cassegrain design with 4″ / 102mm diameter lens and 1398mm focal length, giving approx f/13 aperture. The long focal length is quite good for planetary imaging & observing, but makes it fairly poor choice if deepsky imaging is your plan (a fast refractor is a better choice for deepsky). The equivalent model sells new for about £500, but I got mine second hand from a friend for considerably less.

Celestron Nexstar 4 GT

Celestron Nexstar 4 GT

The final piece of equipment is of course a laptop, which presumably most people have access to. Laptops screens are optimized to work in pretty bright ambient conditions, so their screens are correspondingly bright. Upon taking a laptop outside at night it quickly becomes obvious that the screen is far too bright, even on the lowest brightness setting. This totally ruins night vision adaptation and will be very annoying to any other astronomers near by. The solution is to place a piece of red acetate film over the screen which reduces the brightness to a level which does not negatively impact night vision adaptation. Some astronomy shops sell this pre-cut to the size of your laptop screen at vast expense. The secret to getting a deal is to know the word “Rubylith”. Type this into eBay and many vendors will appear offering the perfect material for the purpose. It is also suitable for use as safe-light protection in photographic darkrooms. A sheet for £4.99 was large enough to cover a large laptop, a small netbook, a smartphone and a little left over to make a red light torch.




To summarize the key pieces of equipment for doing planetary astrophotography on a low budget are

  • Microsoft Lifecam Cinema HD – £20 from eBay
  • Lifecam eyepiece adapter case – £16 from Billet Parts
  • 1.25″ IR blocking/cut filter – £20 from eBay or other sources
  • Bahtinov mask – £15 from Morris Engraving via eBay
  • Rubylith sheet – £5 via eBay
  • Laptop – any that can control the webcam.
  • Telescope with tripod & mount – almost any, but Cassegrains are a good option for Planetary use. £200-300 for a second hand Nexstar 4, or £300-£350 for a brand new Skywatcher 127 which is a real bargain for what it provides – pretty comparable to the Nexstar in what it provides. Or pick from 100’s of other possible scopes.

The setup described above is suitable for imaging The Sun, to capture sunspots, but it is MANDATORY to have a protective filter in front of the telescope. These can be built using a sheet of Baader Astrosolar Safety Film for approx £20. For carrying all the kit around, skip the official cases and adapt a regular sports / holdall bag.

For a selection of the photographs I’ve produced using this setup, browse the ‘lifecamcinema’ tag on my Flickr profile

Building a barn door mount, part 5: the finished device

Part 1, part 2, part 3 and part 4 of this series consider the electrical circuit construction, mathematics behind the drive mechanism, the control software code and construction diagrams. At this stage readers are probably wondering if the finished device will ever appear. This final part will answer that question via a short picture gallery.

Mount in closed position

To begin with consider a picture of the complete barn door mount in the initial closed position. This shows how it is attached to the tripod below the mount and how the camera connects above the mount. The power supply cable to the electronic control circuit box can also be seen
Barn door, closed position

Tripod head mounting

In the construction diagrams it was explained that the tripod head could not be attached directly to the upper panel of the mount. The adjustment handle for the tripod head needs to be able to rotate through 360 degrees. It was sufficient to place two small panels of wood beneath the tripod head to raise it up. The primary bolt going into the base of the tripod head is thus concealed inside the lower panel.
Tripod head mounting

Tripod captive nut

In the lower panel of the mount there is a captive nut embedded in the wood. A captive nut has three spikes which stick into the wood and prevent it from turning or otherwise coming loose. It is embedded in the panel from above so that the force exerted by the coupling to the tripod is actually pulling the nut into the wood. A good amount of epoxy resin ensures there’s absolutely no chance of this nut coming loose, which is good because it takes the entire load of the mount and camera.

Captive nut and tripod

Panel hinges

The two primary panels of the mount are connected with a piece of continuous “piano” hinge. Using a single continuous hinge rather than a couple of separate hinges avoids the problem of having to accurately align the two separate hinges.
Primary panel hinge

Threaded rod nut

The threaded rod passes through the pivoting part of the top panel. A small nut is recessed into this top panel and held in place with some epoxy resin. Care had to be taken to not get any epoxy on the thread of the embedded nut as that would have totally ruined the ability of the threaded rod to smoothly screw into it
Threaded rod and nut

Motor shaft flexible coupling

The pivoting part of the bottom panel has the motor attached. To enable the mount to be completely closed, the motor shaft and flexible coupling had to be recessed. This picture shows the flexible coupling attached to the motor shaft. The end of the threaded rod was squared off so that it can just slot into the coupling whereupon it is held by the tiny screws in the coupling. This makes it easy to remove the threaded rod when the mount is not in use.
Motor shaft flexible coupling

Motor mounting

As mentioned earlier, to allow the mount to be completely closed the motor shaft needs to be recessed slightly. Thus two small panels are added to the pivoting panel, attached with short bolts and thumbscrews. The holes through which the bolts pass are rectangular so that they panels can be adjusted horizontally to ensure the motor shaft can be accurately aligned with the pivot hinges. Also seen on the left is the edge of the electronic circuit box with two small switches sticking out. Through a bit of poor planning there was barely sufficient clearance for the switches with the box mounted in this location.
Stepper motor mounting

Pivot panel hinge blocks

The movable panels to which the motor and threaded rod are attached need to pivot smoothly as the mount opens. After a prolonged period of indecision the final approach was to make use of some simple plastic furniture fixing blocks. These are attached to both panels and then connected with a small bolt. Two plastics washers keep them separated to the requisite degree and ensure they can move with minimal friction.

Pivoting panel blocks

Pivoting motor panel

A further view of the pivoting motor panel from below
Stepper motor mounting panel

Threaded rod and motor

As the two primary panels open the two pivoting panels should remain parallel to each other as seen in this image. If they don’t remain parallel this indicates that the hinges and / or threaded rod were not correctly aligned with each other.
Pivoting panels and threaded rod

Electronic control box

The electronic control box had two strips of velcro attached to its lid, which are used to stick it to the mount, a simple but reasonably effective attachment.
Electronic control box

Mount from below

Viewed from below it is possible to see the tripod plate attached to the mount, the other velcro strips to which the control box is stuck and finally the pivoting motor panel
Mount viewed from below

Mount in open position

Finally to remind ourselves what the complete mount looks like, consider the mount in a partially open position, as it would be after tracking for 30 minutes or so.

Barn door, open positionThoughts on the construction & design

The more observant readers may have noticed something missing on the mount, specifically a means of aligning it with Polaris. Some people suggest it is possible to align by just visually sighting along the continuous hinge. It only takes one attempt to determine that this is a really unsatisfactory approach. An alternative idea is to attach a green laser pointer to the mount, aligned parallel with the hinge. This would certainly make it easier to visually align with Polaris but unfortunately living near the flight path into Heathrow airport means use of laser pointers is a pretty bad idea in general. Probably the better idea is to get a small gun sight or a red dot finder or some small finder scope. Thus far though I’ve not decided on which solution to go for. Since a big motivation for building a barn door is to keep the costs low, this needs to be taken into account when choosing an alignment method, lest it double the price of the parts !

As mentioned earlier, a mistake was made in positioning the captive nut used to attach the mount to the tripod, which left insufficient clearance for mounting the electronics control box. Also the positioning of the switches, power socket & USB socket on the electronics box was really poorly chosen. They should have all been positioned on the short edges of the box, rather than on the long edges.

The coupling of the motor shaft to the threaded rod was not entirely satisfactory. A flexible coupling seemed like a good idea to avoid undue stress on the apparatus, but in the event there is actually too much flexing in the coupling which means that the pivoting panels don’t always stay parallel to each other as the threaded rod rotates. A rigid coupling of the threaded rod & motor shaft would probably have worked better. As a hack I might attempt to bind the flexible coupling in tape and/or glue to make it less flexible and reduce the wobble in the panels.

Overall the project took a bit longer to complete than anticipated and cost more than is really necessary to build an effective barn door, due to cost of the electronics. As a person commenting on an earlier part in this series says, using a threaded rod would provide a much simpler design which could be powered with a simple fixed rate motor and no need for the arduino. A large part of the motivation (and fun) of the whole enterprise though was to actually learn about arduino programming and electrical circuit construction. In this respect it has been a very successful project, even if overkill for a barndoor. The arduino also has the capability to be used to correct for construction errors, meaning it was not necessary to be too accurate with the measuring of the mount, and could be extended in future to also automate triggering of the camera shutter for specific time periods.

Unfortunately a combination of other life commitments, awful weather in the first part of the year and heavy light pollution mean that I’ve not had much opportunity to actually use the completed barn door mount yet. It has just had a few simple tests to check that the electronics and mechanics were working correctly. In these tests I determined that the tripod I have for holding the mount is not very well suited to the job, as it has a head which freely moves in any of the 3 axis of rotation at once. This makes it a really pain to align the mount with Polaris. What is needed is a tripod which allows each of the 3 axis to be adjusted completely independently. As a result of this and lack of a good polar alignment method, it hasn’t been possible to get any decent pictures of the night sky using the mount yet, hence why none are shown here. Hopefully I’ll be able to put this right over the coming months at which point I’ll post them to demonstrate the mount capabilities.

Building a barn door mount, part 3: drive control software

Part 1 and part 2 of this series considered the electrical circuit construction and mathematics behind the drive mechanism respectively. There was a short demonstration of arduino code to drive the motor in part 1 but this did not attempt to do any kind of proper rate tracking since it was awaiting the mathematics in part 2. This part of the series of blog postings will thus consider the actual code required to do accurate rate tracking. For the impatient, the full working code is published under the GPL version 3 or later license at gitorious.

EDIT 2015/7/22: With gitorious going away, the code now lives at gitlab

Since the writing of part 1, a slight change was made to the usage of the two switches. The ON/ON switch, connected to analogue pin 3, is to be used to switch direction of rotation between forwards (moving with the earth’s rotation) and backwards (moving against the earth’s rotation). The ON/OFF/ON switch, connected to analogue pins 4 and 5, is to be used to control the mode of operation between automatic tracking, stopped and non-tracked high-speed. The idea of the latter mode is to allow the mount to be more quickly reset back to the starting position. For convenience the code defines constants for the analogue input and digital output pins based on their intended function

static const int pinOutStep = 9; // Arduino digital pin connected to EasyDriver step
static const int pinOutDirection = 8; // Arduino digital pin connected to EasyDriver direction

static const int pinInAutomatic = 4; // Arduino analogue pin connected to automatic mode switch
static const int pinInManual = 5; // Arduino analogue pin connected to manual mode switch
static const int pinInDirection = 3; // Arduino analogue pin connected to direction switch

The core design concept for the code is to have a finite state machine associated with the ON/OFF/ON switch. Rather than implement the finite state machine concept from scratch, it reuses the existing FiniteStateMachine module. Thus in order to compile the sample code, the ZIP file for this module must be downloaded and imported into the arduino project. The same is true of the AccelStepper library used for motor control. Since the switch has three positions, there are three states in the FSM declared as global variables. When declared, each state is provided with three callbacks, one to be invoked when the state is entered, one invoked on each tick while the state is active and one to be invoked when the state is left.

static State stateAuto = State(state_auto_enter, state_auto_update, state_auto_exit);
static State stateManual = State(state_manual_enter, state_manual_update, state_manual_update);
static State stateOff = State(state_off_enter, state_off_update, state_off_exit);
static FSM barndoor = FSM(stateOff);

The state machine is used to control the operation of the stepper motor object

static AccelStepper motor(AccelStepper::DRIVER,

Off state

Starting off with the simplest, stateOff, there is only one callback that needs any logic in it. When entering the ‘off’ state the motor needs to stop turning:

void state_off_enter(void)

Manual running state

Moving on to the next, stateManual, there is again only one callback that needs any logic in it. On each tick while in this state the motor needs to be told to move a fixed amount in the correct direction. The code arbitrarily uses a speed of 5000 – this can obviously be changed to whatever suits. There is one safety measure built-in, when the mount is running in reverse, it should automatically stop when it gets to the completely closed position. Fortunately the AccelStepper library tracks how far the motor turns, so if we assume the mount was set to the completely closed position when first turned on, it is just a matter of checking whether the motor position is zero. As a future enhancement it would also be desirable to add an upper limit on the position because if the mount opens too far it’ll run off the end of the threaded rod and likely flap open causing any attached camera to bash against the tripod legs.

void state_manual_update(void)
    if (analogRead(pinInDirection) < 512) {
    } else {
        if (motor.currentPosition() == 0) {
        } else {

Automatic tracking state

Finally, stateAuto, requires quite a lot more complicated code in its callbacks. At any given point in the time, the speed at which the threaded rod needs to turn is dependent on how far open the mount is. First of all, the code needs to know the position of the mount when automatic tracking started, bearing in mind there could have been arbitrary movement forwards or backwards when in manual mode. As noted before, the code assumes that the mount is in the completely closed position when the electronics are first powered on, which corresponds to motor step count of 0. Thus when entering the automatic tracking state, the position of the mount can be determined from the total number of motor steps. Given the step count, the mathematics from the previous blog post show how to calculate what this corresponds to in tracking time, so a function is defined to do this conversion:

long usteps_to_time(long usteps)
    return (long)(asin(usteps /
        SIDE_REAL_SECS / PI);

To record the state of the mount at the time automatic tracking begins, three global variables are defined

static long startPositionUSteps;
static long startPositionSecs;
static long startWallClockSecs;

These are initialized by calling another helper function, which also records the current wallclock time reported by the arduino runtime:

void start_tracking(void)
    startPositionUSteps = motor.currentPosition();
    startPositionSecs = usteps_to_time(startPositionUSteps);
    startWallClockSecs = millis() / 1000;

With the initial position determined, the next job is to determine the speed to move the mount. Since the tangent errors from the mechanical design are quite small, it is not necessary to change the speed on every tick of the arduino code – calculating in 15 seconds blocks is sufficiently accurate. The target for the next 15 second block will be recorded in three more global variables

static long targetWallClockSecs;
static long targetPositionSecs;
static long targetPositionUSteps;

The target wall clock time is just updated in increments of 15, but the target position tracking time is updated based on the delta between the start and target wall clock time. It would be possible to just update the target position tracking time in increments of 15 too, but by using the wallclock time delta, the code automatically accounts for any execution time overhead of the tracking code itself. A subtle difference, but worth doing. Once the target position tracking time is decided, the mathematics from part 1 once again show how to convert it back into a motor step count with a small helper function:

long time_to_usteps(long tsecs)
    return (long)(USTEPS_PER_ROTATION *
                  THREADS_PER_CM * 2.0 * BASE_LEN_CM *
                  sin(tsecs * PI / SIDE_REAL_SECS));

The three target variables are all updated by yet another helper function

void plan_tracking(void)
    targetWallClockSecs = targetWallClockSecs + 15;
    targetPositionSecs = startPositionSecs + (targetWallClockSecs - startWallClockSecs);
    targetPositionUSteps = time_to_usteps(targetPositionSecs);

With all these helper functions defined, it is possible to show what action is performed by the callback when entering the automatic tracking state. Specifically it will record the starting position and then plan the first 15 second block of tracking

void state_auto_enter(void)

Now the automatic tracking state is ready to run, it is necessary to actually turn the motor. This is simply a matter of taking the remaining wall clock time for the current 15 second tracking block and the remaining motor steps to achieve the target position and then setting a constant speed on the motor to accomplish that target. The code to do this will recalculate speed on every tick in order to ensure smooth tracking throughout the 15 second block. Once again a helper function is declared to perform this calculation

void apply_tracking(long currentWallClockSecs)
    long timeLeft = targetWallClockSecs - currentWallClockSecs;
    long stepsLeft = targetPositionUSteps - motor.currentPosition();
    float stepsPerSec = (float)stepsLeft / (float)timeLeft;


With this final helper function it is possible to implement the callback for running the automatic tracking state. It simply has to apply the current tracking information and occasionally update the tracking target.

void state_auto_update(void)
    long currentWallClockSecs = millis() / 1000;

    if (currentWallClockSecs >= targetWallClockSecs) {


Switching FSM states

With the code for operating each state defined, all that remains is to actually switch between the different states. This is done by writing the arduino main loop function to check the input pins which are connected to the operation switch.

void loop(void)
    if (analogRead(pinInAutomatic) < 512) {
    } else if (analogRead(pinInManual) < 512) {
    } else {


Hardware specific constants

The actual speed of tracking depends on various constants that match the physical construction of the barn door mount. There are only 4 parameters that need to be figured out. The stepper motor will have a number of discrete steps to achieve one complete rotation. The code records this as the number of degrees per step, so if only the step count is known, simply divide that into 360, eg 360/200 == 1.8. The arduino EasyDriver board for controlling the stepper motor is very clever and can actually move the motors in smaller increments than they are officially designed for, currently 8 micro-steps. The next important parameter is the pitch of the threaded rod, which can be determined by just putting a ruler alongside the rod and counting the number of threads in one centimetre. The final piece of information is the distance between the centre of the hinge joining the two pieces of the mount, and the center of the threaded rod. This should be measured once the actual mount is constructed. All these values are defined in constants at the start of the code

static const float STEP_SIZE_DEG = 1.8;
static const float MICRO_STEPS = 8;
static const float THREADS_PER_CM = 8;
static const float BASE_LEN_CM = 30.5;

As mentioned earlier, all the code snippets shown in this blog post are taken from the complete functioning code available under the GPL version 3 or later license at gitorious. With that code compiled and uploaded to the arduino, the electronics are completed. The final part(s) of this blog series will thus focus on the mechanical construction of the mount.

Now read: part 4, construction diagrams.