Introduction: Star Finder

The star finder is a little gadget that always points to the same star, as long as you align it with a compass. I made this to always show, day and night, where Arcturus, the brightest star in the Northern Hemisphere (and the 4th brightest in the entire sky) is located.

The project relies quite a bit on the understanding of celestial movements, rotation axes, how star positions are given and how ones location on the earth and the local time all play their part.

I thought long about whether I should make this a full two-axis pointer, with configurable star positions to track from basically every part of the world, but I decided not to. If you want to build such a system there are other instructables for that. This link is just an example.

Edit: actually, after having written this instructable, I decided to give it a go and build a two axis tracker in the same style..

I wanted it to look extremely simple yet have some mystical elegance, not a geeky device that needed a computer or smart phone hookup. Add that I am not a very good mechanical builder and the list of requirements became simple.

  • A bit of a mystical device. It should look simple, almost bare, yet not reveal immediately what it is.
  • No geek stuff. The maximum interface should be an on-off switch.
  • Fairly easy to build.
  • Following one star, from one location should be enough. There is only one brightest visible star and I did not expect this thing to be taken on long travels.
  • The planets and the sun are no candidates. Their motion is much more complex than the stars in the night sky.

The next three steps will go into some basic theory about star tracking, then off to building something.

I will not describe the device in detail. Once explained, you can design your own as you will see shortly. You can add a compass, variable angles, etcetera. Be creative!

On the hardware side, things are pretty simple. Just wire up an Arduino, a stepper motor with driver and a real time clock.

The software focuses on two things: create the proper rotation and keep power levels very low. I believe this thing can run up to a year on a small 1 Ah LiPo cell.

Now, on to some theory!

Step 1: The Night Sky

When we exclude the sun, the planets, comets and a few close by and very fast moving stars, the night sky is remarkably static, at least in the context of a couple of decades. For this project, it is absolutely fine to imagine the night sky as a static painting, surrounding us. "But the stars move" you say, and you are right. Luckily all stars move in unison. A good mental image is that we are inside a huge black sphere with the stars painted on the inner surface. Wikipedia has a slightly more formal article on this Celestial Sphere with tons of more links to background.

Note that with the sphere model we have removed one dimension: distance. Each star is only defined by its position on the sphere's inner surface, using two angles, a bit like latitude and longitude but now in the sky. Indeed astronomers have mapped the night sky using a very comparable system, called the Equatorial coordinate system.

Latitude on earth is the angle between a location and the equator. 90 degrees is the north pole, everything positive is in the northern hemisphere, 0 is on the equator, negative is in the southern hemisphere and -90 is the south pole. The night sky uses exactly the same system to define an angle from the equator. It is called the declination of the object. Arcturus, the star we're going to track, has a declination of a bit over 19 degrees above the celestial equator. We'll come to the definition of the celestial equator in a moment.

Longitude on earth is the angle between the Greenwich meridian and the location. A meridian is simply a line over the earths surface going from pole to pole. Note that while latitude more or less naturally follows from the equator, and is thus completely defined by the earths rotation axis, longitude uses this completely arbitrary reference. The same is true for the celestial sky. Simply put, this "Greenwich of the night sky" is called the vernal equinox.

Now unfortunately celestial longitude, called right ascension (or RA) is not given as an angle, but as a time, 24 hours corresponding with the full circle. However, an hour RA simply corresponds to 15 degrees. Intuitively, this is messy but for astronomers there are good reasons to use right ascension in time units instead of angles. Those reasons are beyond the scope of this short introduction though. Things gets worse as the vernal equinox drifts over time, but for this project, this drift is so slow it can be ignored.

So, for now it is enough to know that a star is located by its declination and right ascension, and both are are effectively angles, just like latitude and longitude, and that these two angles are, for the sake of this project, fixed. We will see shortly that the absolute RA of Arcturus is not of much importance to the build, as long as we can calibrate our device once.

Step 2: Everything Moves!

Now the question of course is: how do the poles of the celestial sky align with the poles of our earth? And where is the vernal equinox? Here things get deceptively simple and awfully complex. Lets start with the simple part.

The celestial north and south pole align, while not precisely but good enough for us, with the Earths north and south pole respectively. Think about this for a moment. The earth, while it rotates around the sun, points it rotation axis to a fixed point in the sky! No wobbling, no complex calculations. It is as if there is a huge axle going through the earths poles as well as trough the static, celestial sky. This means that when we ignore all drifts and offsets that do exist, it seems like the sky simply rotates around the earth rotational axis. Consequently, if you look up to the night sky in the same direction as the rotational axis of the earth, the entire sky slowly rotates around that point, roughly one revolution per day. That point corresponds pretty good with the star Polaris. You can easily find Polaris by finding the Big Dipper, finding the two rightmost stars, extend the line going through those stars 5 times upwards and there it is.

Armed with this knowledge it is very easy to track a fixed point in the night sky. Just point an axle in the direction of Polaris, mount a little pointer sideways on it and let it rotate once per day to correct for the rotation of the earth. But wait: our day is defined with respect to the sun, and ignoring Galileo for a moment, for us the sun revolves around us, once a year. So while we live and breath in a 24 hours-a-day rotation, the rotation of the earth with respect to the night sky is actually slightly faster. One such full rotation is called a sidereal day and it lasts 23 hours, 56 minutes and 4 solar seconds, again ignoring some side effects. The extra 3 minutes and 56 seconds are needed to catch up with the sun again: It's no coincidence that 03:56 is roughly one 365-th of a day.

So, as long as our latitude angles is right, and our axle rotates once per sidereal day, we have a pointer pointing to a fixed position in the night sky. As every star is fixed on the sphere of the night sky, following one specific star is now a matter of "bending the pointer", in other words, calibrate our device for a specific star.

Step 3: If It's So Simple, Why Is It So Hard?

It really is this simple! The problem is that our intuition spoils the fun, because (unless you live on the North Pole), the ground plane where we live is not only rotating, but also angled with respect to the equatorial plane. So, assuming a position somewhere in the northern hemisphere, our natural notion of "north", at the horizon where the capital N is in above picture, is absolutely not pointing to Polaris. East and West is even more counter intuitive, as it's celestial equivalents rotate slowly during the day.

In the picture the blue lines are the meridians and parallels of the celestial sky, called the equatorial grid. The celestial north pole is almost at the same location as Polaris. The celestial equator is the line starting close to the left top corner and marked with +0.

In orange our intuitive reference of the sky, called the azimuthal grid is shown. The zenith, being the point straight above you is in the top middle and our horizon displayed as a black shadow.

Remember if we kept gazing westwards as shown here, the horizon and the entire azimuthal grid would remain static, but the equatorial grid and indeed the entire star sky would rotate around Polaris, counter-clockwise. Our instinctive notion of "straight up" is depicted by the azimuthal (orange) grid. The blue lines most certainly do not align with that notion, except in the straight north and south direction.

Armed with this knowledge, we can now build our star finder.

By the way, the picture is a screen shot of the sky simulator Stellarium. It is free for PC's and about 2 euro's for a phone or tablet. I can recommend it if you are even moderately interested in the positions of several types of objects in the night sky.

Note that Arcturus will set in a bit over two hours in this picture.

Step 4: The Device

This step describes in broad terms how I build the device. In the next steps the schematics, part list and software are described. I would encourage you to create completely different designs.

What we need is:

  • a motor, turning a full resolution per sidereal day;
  • mount it in a way that the axis points to Polaris.

Furthermore we need to

  • add a pointer to the motor's axle;
  • bent the pointer up to the declination of the star we want to follow;
  • calibrate and drive the rotation to always align with said star.

The first two prerequisites are easy. As I assume a fixed observer latitude, Polaris is always on a straight northern azimuth, and is always at an altitude angle equal to the latitude of that location. I live at roughly 52 degrees latitude, so the axle of the motor is tilted 52 degrees up. I used a very common small stepper motor plus driver PCB and a candy tin as a base and glued the motor in position using epoxy resin and a small carton support. I had to cut the 5 wires otherwise the hole in the tin for them would have to be as large as the connector. Alternatively, pry the pins from the connector, push them through the hole and refit them. I added some shrink wrap for protection against the rim of the metal hole and re-soldered the wires later to the original connector. Next, I spray painted everything in a neutral dark gray color. Make sure you protect the motor axle with masking tape when spray painting your device.

The next two prerequisites are fairly easy to do too. I made a pointer out of relatively thick copper wire, which I straightened by pulling it and twisting it at the same time using a drill. This also gives it a subtle spirally texture. I then bended the ends up to create two spikes. Gazing over the spikes would point to the star. Mounting the pointer and also at an angle, in this case 19 degrees being the declination of Arcturus, was a challenge. It was was done using an end cap of a BIC pen. The inner diameter fitted the motor axle very nicely, and I drilled a tiny hole at the 19 degree angle through the top. Yes, there was a little mishap as you can see. When I was happy I put some resin into the end cap securing it on the motor and securing the pointer at the same time.

To control the stepper motor I used an Arduino pro mini clone. I also needed a real time clock. I glued an old phone battery, a small USB charger PCB, a micro switch for the power, a button switch, the Arduino pro mini, the motor driver PCB and the real time clock PCB in the lid of the can using more epoxy and wired everything up. The power switch is actuated by a small piece of wood glued in the tin can. Two markings, one on the can and another one on the lid must be aligned for the switch to engage and the device to power up. The aligned markings should be facing north. This dual function of the markings maintains the minimalistic look.

Step 5: Part List and Schematic

  • An Arduino pro mini, or clone, see below;
  • A LiPo battery, i.e. an old phone battery;
  • A TP4056 charger PCB;
  • A DS3231 precision real time clock PCB;
  • A 28BYJ-48 Stepper motor with ULN2003 driver PCB;
  • A small power switch;
  • A small pushbutton switch for motor calibration.

I would advice to get an 8MHz pro mino, as they reliably run on lower battery voltages. These usually come with an ATMega168 processor but that is fine, the software will fit in there easily.

To keep power usage to an absolute minimum, de-solder the power LED and the voltage regulator from the pro mini. While my clone had a slightly different layout, this instruction is very helpful.

The motor unfortunately is on the market in several versions, differing in their gearing (16 or 64) and coil voltage (5 or 12 volt). Make sure you get the 5 volt 64 reduction version. I actually received one with a true true 1:64 reduction, not mentioned in the linked article, so the steps per revolution was 2048. There are constants defined for different gear ratio's in the code in case you get one with different gearing. There is a test in the calibration program (next chapter) to determine which motor you have.

Soldering equipment, connecting wire and epoxy resin are also needed, as well as something to put everything into, such as the candy tin can I used.

All items in the list are easily obtainable through i.e. ebay and will set you back about 10 USD.

The schematic should speak for itself. Just hook up the modules as indicated. Note that the VCC of the clock module is wired to a digital pin of the Arduino. The software only provides power to the module when it is needed, keeping power consumption as low as possible. When the VCC to the clock module is cut off, it will run the clock and keep its registers using a coin battery.

I did not use header pins and soldered all wires directly on the Arduino pro mini. This saved space and made the connections more reliable. I strongly advice you though to solder in the serial header on the short edge of the Arduino so you can re-program the processor easily when needed.

Step 6: Set the Time and Date in the RTC

Now, you need to set the current date and time in the real time clock. Clone and edit the program (or sketch as is called in Arduino parlance) listed here to reflect UTC date and time and load it on your Arduino pro mini.

A link to the gitlab repository is here. It contains the source plus supporting libraries in platformIO format. I strongly recommend using vscode with the platformIO plugin, as it is a much more mature development environment compared to the Arduino IDE, even though it might take a bit more time to get used to it.

Just connect to the serial port, reset the Arduino pro mini and follow the instructions. Set the RTC power pin (8 in the schematic), year, month, day, hour (use 00-23 notation), minute and second. Use UTC time, NOT your local time. You can check using option 0.

A note on loading software on an Arduino mini pro
For an Arduino pro mini you need an USB-to-TTL serial converter to load your programs, or sketches as they are called in Arduino parlance, into the chip's flash memory. This instructable is not about how to do this, nor how to use vscode, platformIO or, alternatively, the Arduino IDE.

If you're new to Arduino programming or these development environments, there are many instructables available.

Step 7: The Software

The software itself is well documented and should be self explanatory. A link to the gitlab repository is here (in platformio format.

Note that I have offloaded complex 3D trigonometric computing to what is in effect a very simple analog computer. The software contains not a single floating point instruction. The source, shown here in codebender, basically does a computation, rotates the pointer if needed, and then goes to a low power state for half a minute. Sometimes after wakeup it rotates one step, sometimes it doesn't need to.

The software keeps the stepper motor position in the real time clock chip. If a new position is required, the difference between the new and old position is calculated and the number of steps in the required direction are commanded. After each individual step, the new position is stored in the RTC chip. Arduino's own EEPROM cannot be used for this because it will wear out after roughly 100.000 writes, which is about a year of operation. The cheap but precise DS3231 real time clock, has no free NVRAM, so the code is misusing the memory positions of that chip's alarm registers, that should be formatted in BCD.

Motor positions are used and stored from 0 to a full rotation, 2047 in my case. No shortest path is calculated, as the gearing in the motor might not have integer ratio. Therefor, if the motor is assumed to be at position 2047 and position 0 is commanded, the pointer will make an almost full counter-clockwise rotation, keeping errors from accumulating.

Calculating the position is relatively straightforward. First, the real time clock is read. It's date and time are taken as solar seconds since midnight 01-01-1970 UTC. This value multiplied by 1000 to get milliseconds, then taken modulo the number of solar milliseconds in a sidereal day. This is divided by the number of solar milliseconds corresponding to one single step of the motor. Note that I have made no attempt whatsoever to calculate the absolute value of the local sidereal time. There is simply no need for that as you need to calibrate the device anyway. See also the epilogue about precision.

A lot of effort has gone into power management. The entire system sleeps for roughly 40 seconds only to wake up, do a quick recalculation, rotate the motor if needed, and go to sleep again. I use the lowPower.h library to power down the Arduino. In addition to that during sleep, the VCC to the RTC modules is switched off and the I2C functions of the processor are disabled. Note that the time.h library needs to be resynchronized after each wakeup, since a power-down destroys the millis() function, on which the library depends.

Actual rotation is done using custom code instead of using the standard Arduino stepper.h library. Main reason is that the standard library has no call to power down the motor once we have finished rotation. Also, to minimize the chance on stepper errors, I start with energizing the motor in the current position, then start rotation. Again for power conservation reasons, I have made the step time as short as reasonably possible.

Step 8: One Time Calibration and Go!


Technically, calibration is performed by rotating the motor without updating the RTC chip. The easiest way to calibrate is to find a reference date and time when your star is facing exactly south in your location. In Stellarium this is easy: find your star, and rotate it using the time Fast Forward and Rewind buttons until it aligns perfectly with the +180 degrees orange meridian. Clone and edit the sketch, then record the date and time in the setTime call in the set_south_local_time () function. For Arcturus and my location I used

setTime (3, 57, 56, 20, 2, 2016);        // hr, mn, se, dy, mo, yr

In the code you will also find a date and time for Alcyone, the brightest star in the Pleiades cluster for two locations, just to show how easy it is to change the system. Of course for Alcyone, the pointer should be set to a 25 degrees declination, which is a hardware change.

Upload the sketch and reset the device while holding the calibration button. Then, use the button to align the pointer to the south and therefor the highest position of the star. The direction will alternate between each button press. It's best to end calibration with a clockwise motion. Reset again to start normal operation.


The motor should step once per roughly 40 seconds. You can and probably should leave the device on. On a moderate cell phone battery it can run for close to a year without recharging. Switching the device off should not loose it's calibration. The only way a calibration error can occur is if the Arduino commands a rotation, but the battery cannot provide enough power to actually rotate the motor. In that case, just recharge the battery and re-calibrate.


Step 9: Epilogue: Precision

A couple of factors influence precision, and some errors are cumulative (drift) while others are not. To put errors into perspective, the diameter of a full moon is 3 steps of the motor, and it would be pretty difficult to set the declination of the pointer or align the device device to the north within one degree of error, corresponding to 6 steps of the the motor.

  • We keep the motor within one full rotation, so there is no drift problem if the gearing reduction is not an integer value per rotation;
  • The motor always rotates in one direction, except when it reverses once per day, so there is hardly a slop problem because of gear tolerances, except after reversal. To counter that, it over-rotates 25 steps and then positions in a forward motion;
  • As there is virtually no torque needed, except to overcome the internal resistance of the motor itself, there is almost no slop for that either. Actually, I added a tiny bit of fixed resistance later using some steel wire from a pen spring so the gearing slop is always kept constant, see the picture above;
  • The code wakes up just a bit faster than the 42.2 seconds needed between steps. It then either commands one step, or none. This introduces a non cumulative error of on average half a step;
  • Next there is some rounding error in the calculation of the rotational position. This error is kept low by using milliseconds in 64 bit precision. The non cumulative error is less than two-hundredth of a step over a day and thus totally neglectable;
  • The calculation of the sidereal time introduces a cumulative drift of less than two-hundredths of a step per year, and is therefor also neglectable;
  • The clock drift of the DS3231 or DS3232 is roughly two steps per year (4 for the DS3232M). You can use a DS1307 RTC clock with an external crystal, but as it's usually not temperature compensated it can make the device drift up to 17 steps per year, by far the biggest error in the system. The only solution when using a DS1307 is to simply set it again, probably not less than twice per year if you want to stay close to one degree precision. Set the time again once per 1.5 year for a DS3232M and once per 3 years for a DS3232.

As you can see, when using the more precise DS3231 or DS3232, and keeping the battery charged so the calibration is not lost, acceptable drift is maintained over several years. Calculation drift, meaning the error, even if the device is calibrated, is not noticeable over more than 100 years between the calibration of the star's date-time and real time. Non-drift precision is almost entirely determined by the quality of the mechanical build and components.