Text entry on Arduino 1602 LCD display with only three push-buttons

Working on Stellarduino (an Arduino-powered telescope computer) has taught me many things about programming, especially the art of doing a lot with very little.

In this case, my Arduino sketch needed to know the date and time in order to figure out which stars are overhead, which can then be used to automatically select two ideal stars for alignment. The obvious solution was to use a Real Time Clock, which I did, and it’s great, but you still need to set it the first time, and adding an RTC to the build meant just another barrier to entry for users.

Stellarduino text entry

So, I wanted to provide a way for a user to enter the date using only a few push-buttons, and a 16 x 2 LCD display. After toying with the idea of adding numeric keypad, then writing it off as more of a barrier than just buying an RTC module, I decided to go with something akin to the way old arcade machines let you enter your initials if you get a high score.

Arduino UIs lend themselves to being implemented as a state machine, with each button press triggering a transition of states. This means you need some way of waiting for one of a number of buttons to be pressed, and to solve this I came up with probably the worst bit of code I’ve ever written:

int waitForButton()
  int button;

  while (true) {
    // Poor man's "wait for button to be pressed".
    while (digitalRead(OK_BTN) == 0 && digitalRead(UP_BTN) == 0 &&
      digitalRead(DOWN_BTN) == 0) {}

    // Poor man's "which button was pressed?".
    button = digitalRead(OK_BTN) ? OK_BTN :
      digitalRead(UP_BTN) ? UP_BTN :
      digitalRead(DOWN_BTN) ? DOWN_BTN : -1;

    // Poor man's debounce.
    return button;

It’s horrific, but it works.

The next challenge was creating the state machine that would allow a user to navigate across the LCD display, altering the number displayed at each location. Fortunately the Arduino LiquidCrystal library has pair of methods show and hide the underline cursor at the current location, and the position and current character can be stored as integers.

Because the text to be entered is a date, it needs a placeholder and some special formatting to guide the user in what to enter. To implement this, a placeholder answer is printed to the display first, and certain characters are designated to be skipped when the user is moving past them.

String lcdDatePrompt(LiquidCrystal lcd)
  char question[] = "Enter UTC Date";
  char answer[] = "YYYY-MM-DD HH:MM";
  int answerLength = 16;
  int skipPositions[] = {4, 7, 10, 13};
  int skipsCount = 4;
  char characters[] = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9'};
  int charactersCount = 10;
  int cursorPosition = 0;
  int currentCharacter = 0;
  int button;

  // Print the question to the display.
  lcd.setCursor(0, 1);

  // Print the answer to the display as placeholder text.
  lcd.setCursor(0, 1);

  // Enable the cursor.

  while (true) {
    // Write current character to screen, then reset cursor on top of it.
    lcd.setCursor(cursorPosition, 1);

    button = waitForButton();

    if (button == OK_BTN) {
      // Store selected character in answer output string.
      answer[cursorPosition] = characters[currentCharacter];

      // Move cursor along, skipping cells if necessary.
      while (inArray(cursorPosition, skipPositions, skipsCount)) {
      lcd.setCursor(cursorPosition, 1);

      // Reset currentCharacter.
      // TODO: Remember char when returning to a position that's already set.
      currentCharacter = 0;

      // If at end of answer, break out of loop.
      if (cursorPosition >= answerLength) {
    } else if (button == UP_BTN) {

    } else if (button == DOWN_BTN) {

    // Prevent currentCharacter from wrapping the characters array.
    if (currentCharacter < 0) {
      currentCharacter = currentCharacter + charactersCount;
    } else if (currentCharacter >= charactersCount) {
      currentCharacter = currentCharacter % charactersCount;


  return answer;

The currentCharacter int is always wrapped to a value between 0 and charactersCount, this means selecting the next character after ‘9’ returns a ‘0’. The function inArray is just a loop through the array that returns true if the requested element is found. Very similar to the PHP equivalent.

If you’re interested, the full code to Stellarduino can be seen on GitHub. It’s very much a work-in-progress, but hopefully commented enough to be quite readable.

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.