Tracker testing (1)

My equipment is a Canon 5D3 with a 70-200mm L USM F4 lens at 200mm, ISO 800.

I started with 30 sec exposure.  Until these were looking good there wasn't any point in trying any longer exposures.

Initial results were disappointing, and inconsistent which made it difficult to understand exactly what was going wrong. There was a mixture of issues:

1. star images streaked inconsistently in the tracking direction
2. star image movement in other directions, sometimes in a sort of horseshoe shape
3. the whole star field drifting in the tracking direction from image to image

(3) is fairly clearly that the tracking speed is too slow (or fast, depending on the direction of drift).

(1) would also appear to be a tracking speed issue, although the inconsistency of the streaking made it difficult to understand quite what was going on.

(2) would seem to show movement in some other direction: the "horseshoe" shape wasn't always exactly that shape, and often with different orientation. Nevertheless it suggested some sort of oscillating movement, not random like a shaky tripod.

30 sec exposure of the Pleiades showing "horseshoe" errors

I concluded that there were two main issues:

The first that there was something wrong with the stepper motor, which could account for problems (1) & (3). I was already suspicious that it was not turning consistently. I also had tried tweaking the speedfactor setting on the Photon to fix issue (3), and had varied it by up to 20% before the star field stopped drifting (and even then it wasn't completely consistent). I had difficulty believing that my calculations for the code could be this much wrong. I decided there was something broken or slipping in the internal gear train so I replaced it (£10 for a pack of 5 on eBay!). It turned out that there are a number of variants of this ubiquitous 28BYJ-48 motor, and my original was one of the unusual ones, with a different gear ratio. This went some way to explaining some of the problems I'd had.

Secondly I decided that issue (2) was down to the play in the gimbal axes. I'd assumed that the quality hinges would prevent any lateral movement of the plates, but this appeared to be what I was seeing, driven by some oscillation in the gimbals. I'd crudely made them of a steel rod (actually a sawn-off nail!), so I replaced these with screws that fitted into the gimbal blocks tightly but still allowed free movement.

These two changes improved things significantly, with most of the issues disappearing.

30 sec exp. Pleiades: no tracking and tracked

 

120 sec Orion Nebula

Stars still don't render as perfect points, so more investigation needed. The 120 sec image of the Orion Nebula is encouraging. Testing is painfully slow because of the scarcity of clear nights.

Notes on Imaging Sessions

I estimate my night sky in Leamington Spa is a Bortle  class 7.

I record images directly onto my Linux computer via a 5m USB cable, using gphoto2 to control the camera. It means that, once I'm set up, I can stay inside in the warm :)

Barn door astrotracker project

I built myself a barn door tracker.

This is an astrophotography device to cancel the movement of stars caused by the Earth's rotation. Without something like this, photographs of the stars will rapidly show trails. There are many forms of equatorial drive to counter this movement, mostly costly, and a barn door tracker (aka a Scotch mount) is something that can be built cheaply as a DIY project (and I like those). Search the internet for more general info about them.

My tracker is based on the common design of two hinged boards (plywood in my case) driven apart by a straight threaded rod. The rod is an M6 size, which has a thread size (pitch) of 1mm, and is driven by a motor fixed to the lower board, and rotates in and pushes against a M6 nut fixed to the upper board. I was intending to fix the boards using a piano hinge, but it had too much play in it to be useful. Instead I used two high quality brass hinges, which are tight and have no play at all.

The simple rod type barn door tracker inherently suffers from the fact that the relationship between the length of the rod and the change in angle between the boards (i.e. the tracking angle) is not linear, but varies as the sine of the angle. This means the increase in the angle for a same amount of rod gradually decreases as the rod lengthens. The discrepancy is not significant for small angles but increases as the angle increases. Rods driven by a constant speed motor will therefore suffer this problem; there are more complex designs involving multiple boards that can reduce the error, but all this goes away if the motor speed can gradually increase to compensate.

At the time I chose to use a microprocessor and stepper motor, I don't think I really appreciated all this. Building something that needed a precisely geared arrangement from a fixed speed motor without any obvious means of finely adjusting it looked too hard, whereas I had a spare microprocessor lying around and have a background in IT. And importantly, this way looked way more fun!

So, this is what I did...

The rod is driven by a stepper motor controlled by a microprocessor. The motor (underneath the blue shaft collar) and upper nut are gimballed, allowing the rod to remain perpendicular to the axis of the hinge. This somewhat simplifies the calculation of the tracking angle.

The Particle Photon microprocessor drives the 28BYJ-48 stepper motor via a ULN2003 driver (the latter two £6 together on eBay). The motor is a real budget job but is the only stepper I've found that uses 5V and can be easily driven by a processor such as the Photon (and more commonly an Arduino).

Polar alignment

For polar alignment I use a green laser that was originally fixed to the top board, but I felt it was more accurate to fix it tightly against the hinge(s). One problem I discovered with green lasers is that they stop working in the cold (below around 5C). To overcome this, I bought a USB powered cloth heater to wrap around the laser.

Software control

The microprocessor cycles continuously through the code. In each cycle it calculates the angle between the boards required to match the sidereal turning rate and converts it into the amount the rod needs to turn. Using simple trigonometry this is translated into the length of the rod, the number of turns of the rod required to achieve it, and hence the number of motor steps. If the calculated number of steps has not yet been made, the motor makes one step forward. The tracker needs the rod to turn at roughly 1 rpm;  the processor cycles at a vastly higher rate than is needed to avoid missing a step.

Software control has at least two major benefits:

• The motor speed can be varied and determined by the tracking angle required; that is, the tracking angle determines the motor speed, and not the other way around as in a purely mechanical design. This means there should be no inherent error in the tracking speed.
  
• It's easy to fine tune the tracker's motion by tweaking the programming.
  

Other designs I've seen have the boards initially parallel so the starting angle of the tracker is zero. With mine, the angle does not start at zero because of the way I constructed it (I wanted space between the boards to install the electronics). The initial angle - formed by the hinge pivot and the gimballed fixings of the rod - needs to be added to the angle delta before the corresponding rod length is calculated, and then the initial length of the rod subtracted from the result. The code looks like this:

elapsedMillis = millis() - startMillis;
delta = 2 * PI * speedFactor * (elapsedMillis/millisPerSideralDay);
d = 2 * r * sin (delta+theta_init/2); // length in mm the bar should now be
turns = d - d_init;                   // number of turns (1mm per turn)
stepsNeeded = turns * stepsPerTurn; // number of steps to achieve this
while (stepsTaken lt stepsNeeded) { // are we there yet?
  setOutput(step);
  stepsTaken++;
}

The inaccuracy from not doing this correction is actually quite small, and very small for small angles, but nevertheless easy to fix in the code.

The variable speedfactor is a fudge factor, initially set to 1 but can be modified to fine tune the speed to match actual observation. A bank of DIP switches is wired into the processor, the settings of some of which can be read by the code and applied to speedfactor. The remaining DIP switches are used to control other aspects of the code, such as whether the Photon's wireless connection is enabled - needs to be disabled if a connection cannot be made.

 

Testing

Initial testing was disappointing, but more of that later.