Stellarduino May Update

An Arduino-powered telescope computer, offering two star alignment, Push-To navigation and Meade Autostar compatible serial output for displaying telescope orientation on a PC.

I’d been tinkering with the idea of building my own “telescope computer” for my Dobsonian mounted telescope since late last year (2012), and when I discovered the Brisbane Makes competition, I decided it was time for less tinkering and more making.

What is Stellarduino?

Put simply, Stellarduino is a device that when attached to a telescope, determines its orientation in the sky. It achieves (or will achieve) this using high-resolution rotary encoders attached to the telescopes axes, some moderately complex matrix transformation math, and a sprinkling of magic. Stellarduino solves an age old issue for telescopes: “What am I looking at?”

That said, it certainly isn’t the first such device. In my research I discovered many other products that solve this issue – the Wildcard Argo Navis is a perfect example. First, because it does exactly what I want Stellarduino to do, and second, because it’s over $800 AUD. Stellarduino will be fully open source, and leverage cheap, readily available components. In this way, it will be a first.

Why is this so complex?

From the description above, Stellarduino doesn’t sound like much – it just converts rotary encoder readings into coordinates, right? Unfortunately, no. Why? Well, I’ll tell you…

Much like earth’s geographic coordinates, the night sky is similarly partitioned by it’s own celestial coordinate system. It has a north and south pole that align with earth’s, and a meridian at the Vernal Equinox, in the same way Greenwich is the earth’s arbitrary meridian. Now, if you go outside and look straight up, directly above you, you’re looking at a point astronomers call your local zenith, which is sort of “north pole” of another set of coordinates – the direction you’re looking in relevant to your current viewing location.

We measure all three of these in different ways – geographic in degrees from the equator (latitude) and Greenwich (longitude); celestial in degrees from the celestial equator (declination) and hours from the vernal equinox (right ascension); and your viewing coordinates in degrees above the horizon (altitude) and from north (azimuth). In order to convert from viewing coordinates to celestial, you need to record the altitude and azimuth of the observation, the time it was made, and the geographic position on the earth of the observer, then parse these values through a complex mathematical equation.

On paper, it works perfectly, but falls over in practice because it requires the telescope to be “perfectly aligned” – that is, the base is perfectly level, and the initial horizontal orientation of the telescope is perfectly north. When you’re dealing with fractions of a degree accuracy, this is basically impossible. The solution then, is to perform an alignment procedure – take a couple of known points in the celestial coordinate system (typically bright stars), and move the telescope to those locations. Then, using some handwavy matrix magic, you can convert back and forth between the two.

If you’re interested in the math, be sure to check out Toshimi Taki’s website, and his Matrix Method for Coordinates Transformation document.


One of my big goals with Stellarduino was to use cheap components to keep the build price down. That way fellow tinkerers could build their own without breaking the bank.

High resolution rotary encoders to read the rotation of the telescope as it’s moved around. Expensive high resolution encoders are best, but lower resolution ones would work, like the kind in old ball-mice, you’d just have to gear them down. Fortunately, I already have a pair of 1000 steps-per-revolution US Digital optical encoders that I’ll be using – but CUI’s new capacitive encoders offer similar resolution for a fraction of the price ($30 each instead of $100).

16 x 2 character display to show the current orientation of the telescope, status messages, etc. I bought a cheap black-on-green one from RS for $7, but I plan on getting a snazzy red-on-black one for the final product.

Push buttons for user input – Stellarduino needs up, down and a select button for entering time, location, cycling through modes, etc.

Real time clock to avoid having to enter the time each time you power Stellarduino up.

Arduino Uno / Nano to do all the math. The Uno/Nano v3 scrapes in as barely powerful enough to do the job – the ATmega 328 chip provides only two hardware interrupt pins, which are split between the encoders, the 8-bit microcontroller barely manages single-precision floating point operations, and with the real time clock, display and buttons installed, there’s not many pins left over. That said, the Uno is probably the most ubiquitous microcontroller ever made, and using it as the backbone for this project means it’s accessible to just about anyone.

5V battery pack because any time you’ll be using this thing, you’ll be out in the middle of nowhere, beyond the harsh lights of the city.

Milestones / Where I’m starting

1. Proof of concept (complete)

Goal: A float math test on the arduino using fixed inputs for alignment, to see if it can keep up with input from the rotary encoders.

Initially I was worried that because the encoders are such high resolution, they would generate so many interrupts that it would fill up the Arduino’s interrupt buffer and “slip”, losing its place. To test this, I devised a sketch that dims an LED (via PWM) based on how much processing time is left over while it’s handling input from the encoders. The idea being that you turn the encoders, and if the LED drops to 0V, the Arduino is using 100% CPU to process interrupts and would have no time to do the computationally intensive float math.

Fortunately, when I tested it, I had to spin the encoders incredibly fast to even notice any change in LED brightness.

So, the next step was to actually have it do a set of matrix transformations based on input from the rotary encoders. The photo above is exactly that – the alignment star locations are hard coded, but the display updates live with decimal degrees as you turn the rotary encoders.

I’m now confident that the Arduino Uno is sufficiently capable to be the controller for Stellarduino.

2. Alignment using preselected stars

Goal: Useful output from alignment using preselected stars

Next up will be to add the realtime clock module to the mix (you can see it to the left of the display in the image above), and instead of using hard coded positions for alignment stars, use the actual values for preselected stars, from a preset location (my backyard). For instance, I know that Rigel and Arcturus will be visible from Brisbane all evening during June/July, so they will be suitable for the rest of the project.

At this milestone, Stellarduino will actually provide meaningful useful data, and is actually quite useful as a digital setting circle.

3. Implement Meade Autostar serial protocol

Goal: Get the output of Stellarduino to be visible as a “reticle” in Stellarium.

Another big goal of Stellarduino is to interface with the popular free planetarium software Stellarium. Meade Autostar mounts use a simple and well documented serial protocol, and when you connect this to Stellarium, come up on the screen as a reticle (aka crosshair) that shows you where the telescope is pointing. This is SUPER HANDY, and pretty much the whole reason I want Stellarduino.

4. Automatic selection of alignment stars using current location and time

Goal: Stellarduino picks the best alignment stars to use from an internal catalogue of 50 bright stars.

To achieve this, I’ll have to fill the Arduino’s EEPROM with a bright star catalogue. To determine which to use as alignment stars, it will have to calculate the altitude and azimuth of each one from the viewer’s location – that is, how far above the horizon, and in which compass direction. Once it has done this, it can discard any with altitudes below 30 degrees (too low) or above 80 degrees (too high), then pick the brightest two.

Actually getting the star catalogue onto the EEPROM is the main challenge – with 50 stars and only 1024 bytes of storage, that’s a scant 20 bytes per star.

Name: an 8 byte string, e.g. Arcturus
Magnitude: a 4 byte float, e.g. -0.04
Right ascension: a 4 byte float, e.g. 14.261 (here decimal hours, but I’ll probably end up storing it as radians)
Declination: a 4 byte float, e.g. 19.183 (decimal degrees, but again, likely to end up as radians)

5. Display mode selection

Goal: Allow the user to cycle between different display modes.

In the photo above, the display is showing current Right Ascension and Declination coordinates. It would be nice to also show calculated Altitude and Azimuth observer coordinates, and the raw integer values coming from the encoders.

That’s pretty much it. At that stage I’ll consider it done and push it all to github.

11 thoughts on “Stellarduino May Update”

  1. Awesome work thus far, I stumbled across this while trying to provide tracking/go-to for my dob. I decided to see if I can first develop a push-to system then devise a drive system. I cant wait to begin working with your code on github. Keep up the great work I’m VERY excited to see how this project works out.

  2. Very interested to hear how you are getting on with this project.
    I have 2 arduino projects lined up before I tackle a telescope control.

    1st a timed UV exposure box for etching PCBs
    2nd a 3d printer to fabricate custom parts (for a telescope/an other projects I have on the boil).

    I’ve had a good look about and there aren’t many projects like this especially being open!

    Good luck and I look forward to reviewing your progress and sketches.

  3. Hi, I’m trying a similar project using just passive sensors (Accelerometer + Gyro + Compass) and RTC. While accuracy (0.5 to 2 degrees) may not be great, it should be sufficient to place the object in finderscope’s FOV (5 deg). This way, it will further decrease the cost of the project.

    Just a hint: Instead of using floats for magnitude, why not use int8_t for EEPROM storage? Just multiply any star mag value(0.0 to 9.9) by 10. For example, for a star of mag 1.4, multiply by 10 and it will give 14. giving a range of 0 to 99. Only when extracting the values, divide it by 10. This way it will store 1/4th storage bytes (1 byte vs 4). Just a suggestion.

  4. Hello, I am very interested in this project and possible improvements, I use the last code early 2014 and my micro-controller Mega2560, I tested the sketch with a connected button on A0 as shown in the program but I do not see no programming and connection pins for the other two up and down buttons to select menus and geographical positions etc, my button allows me to select only two stars and view AD and Azimuth on LCD, I would be very interested in the code complete with 3 buttons and connection, thank you. ‘Otherwise I’m on the connection with the locating Stellarium circle telescope) .Please for help.

  5. Yes, it worked, at the time just on the breadboard, but i can connect to Stellarium.
    I thankful for your work.

    With greetings from Denmark

  6. Hello,
    you hard coded positions for alignment stars, where did you get the values from ?
    If I like to use Procyon or similar star which values have to take ?
    With greetings from Denmark

  7. Hi Casey,

    I just tried your star upload to eeprom and used StarChecker to verify the result. The stars are there but it seems that some didn’t have good coordinates like polaris or Nunki. Didn’t verify other stars, maybe you should check your sources.

    Great work by the way. I’m on the process of building one based on your code with a Teensy 3.2. In the process i discovered Arduino world and c programming. Thank you for that and keep on the good work.

    Oh by the way! This PushTo gadget will be used with the 16 inch dob that i just finished.

    Mine is be a little more expensive with the addition of a sd card containing a couple of catalogs like Messier , Hershell, NGC. For my entry I use a rotary encoder and two push buttons. A GPS give me Longitude, latitude and time reference. A DS3231 is also there to keep time in the advent that the GPS is unable to find satellites. I use the temperature sensor in the DS3231 to control heater resistor in the enclosure because of our cold winter. Negative adjustable level red on black 16×2 is used for display. A voltmeter is implemented to check for the state of the 12 volts battery used to power the scope, the Stellarduino, dew heaters and other accessories.

    All this because of your generosity by sharing your code and your thought.

    Thanks a lot. And sorry for my poor english. ;O)

  8. Trying to figure out module connections while waiting on encoders and RTC .
    Do you have a schematic?
    Or have I missed it somewhere?

Leave a Reply

Your email address will not be published. Required fields are marked *