I’ve tried to describe this project thoroughly, but if you have questions please leave a comment below and I’ll try to answer them.

Introduction

Setting circles on an astronomical telescope are used as an aid to pointing the telescope at a particular object in the sky based upon the object’s celestial coordinates. However, setting circles can be difficult to use effectively and are usually not precise enough for putting objects in the telescope’s field of view. Digital setting circles, on the other hand, can be made to be much more precise and fairly easy to use, making it relatively simple to find faint fuzzies in the sky without lots of star hopping.

What are digital setting circles? You’ve probably seen them in ads in the astronomy magazines: NGC MAX, Sky Wizard, and Sky Vector, to name a few. They’re hand-held electronic devices which, when coupled with encoders which precisely measure the movement of the telescope on its axes, can tell you precisely where your telescope is pointed, or can guide you directly to an object you specify. (It’s worth noting that digital setting circles do not move your telescope. Rather, they simply give you feedback as you move it yourself.) Some digital setting circles systems interface to a PC and can be controlled by software. TheSky, Megastar, and Earth Centered Universe are examples of commercial PC software which can communicate with digital setting circles systems. All of these packages integrate a planetarium view with the system and can be quite useful on portable computers used with the telescope in the field.

The project which I describe below is simply an interface between the encoders mounted on the telescope and a PC running appropriate control software. It is not a stand-alone unit–it is useless without a PC to communicate with it. It is compatible with several other types of digital setting circle interfaces, including BBox, NGC-MAX, SGT-MAX, and MicroGuider III. This compatibility means that the interface described below will work with many commercial software packages. My design is simple, inexpensive, and easy to build.

I’ve worked hard to document this design so that you can build it yourself. The parts are readily available and construction is straightforward. There is nothing terribly challenging in building this device. If you have some experience with building electronic kits, you can build this interface with no problem. If you don’t, find someone to help you through it, and get some experience for yourself.

System Overview

Rotary Encoders

There are three components to a digital setting circles system. First, rotary encoders must be mated to the two axes of the telescope’s mount. Rotary encoders are devices which measure rotational motion. Visually, they bear some resemblance to potentiometers, except that they have no stops (they are able to rotate continuously). Inside, the shaft of the rotary encoder has a clear plastic disk with alternating opaque lines and clear spaces between them, all around the periphery of the wheel. When the shaft and wheel turn, the movement of the opaque lines alternately blocks and unblocks the light path between two emitter/sensor pairs. This is translated into voltage pulses which indicate rotation of the shaft (low when the emitter/sensor pair is blocked by a line, high when not). The two emitter/sensor pairs are arranged such that when one sees the middle of a line, the other sees an edge of a line. The two emitter/sensor pairs are usually labeled as channels A and B.

If the encoder shaft is turned at a uniform speed in one direction, and the voltages from channels A and B are observed, the pattern in Figure 1 would be observed. Note that channel A leads channel B by one quarter of a full cycle (a full cycle is the time taken from when a pulse begins to when the next one begins).

fig1

Figure 1. Example voltage output for rotary encoder turning in one direction.

Figure 2, on the other hand, shows the voltages when the encoder shaft turns in the opposite direction. Note that now channel A lags channel B by a quarter of a full cycle. Knowledge of the relationship between channels A and B allows the direction of rotation to be determined. Additionally, by counting the transitions of the pulses from both channels, we can improve the resolution obtained from the encoder. Knowing what we do about this quadrature mode of the encoder (that is, comparing both channels to determine direction), we can obtain a resolution of four times the stated cycles per revolution of the encoder. Thus, an encoder which has 1000 cycles per revolution can be used to measure rotation down to 1/4000th of a revolution. In this case, we say that the encoder has 4000 tics per revolution.

fig2

Figure 2. Voltage output for rotary encoder traveling in the opposite direction of that in Figure 1.

Decoder

Our second component, the decoder, is an electronic device which monitors the two channels of each of the two rotary encoders and keeps track of the relative angle of the encoder shaft. To do this, the decoder must know how many tics will occur per revolution of each axis on the telescope. If the rotary encoders are mounted directly to the axes of the telescope, then this number will be the same as the number of tics per revolution of the encoder (this is commonly the case for dobsonian scopes). If gears or pulleys are used to connect the encoders to the telescope, then the appropriate gear ratio must be used to compute the number of tics per revolution for each axis.

The decoder stores a single number for the position of each axis. If the number of tics per revolution for an axis is 4000, for example, this number might be stored in the range from 0 to 3999, or alternatively, in the range from -2000 to 1999. By taking that number, dividing it by 4000, and multiplying by 360 degrees, you can determine the relative angle for the axis. However, this is not a celestial angle. It is merely the angle between where the telescope was pointing at startup and where it points now. The next step is to convert each of these two angles into the celestial angles which indicate where the telescope is pointed.

Computer

The third component of our system is a computer. The job of the computer (which might be a PC, or it might be some special-purpose dedicated circuit) is to convert the relative angles from the decoder into absolute celestial angles. To do this requires the employment of a coordinate transformation algorithm. There are two coordinate systems in play here. The first is the system defined by the telescope axes and the angles returned by the decoder. The other coordinate system is the celestial coordinate system, defined by the positions of the stars. It is possible (see the “Astronomical Computing” column of the February 1989 issue of Sky and Telescope for further explanation) to mathematically define the relationship between the two coordinate systems if the coordinates of three positions are known in both systems. Thus, one of the activities when preparing your digital setting circles for an evening of observing is to perform an alignment. Commonly called a two star alignment, this process requires that you aim your telescope at two stars for which the coordinates are precisely known, and to tell the computer those coordinates (I said three positions were needed–the third is obtained by using the cross-product of the angles of the first two stars). The computer then computes the mathematical relationship between the two systems, and then uses that relationship to convert the encoder angles into celestial angles.

Stand-alone systems like the Orion’s Sky Wizard incorporate the decoder and the computer in one small box which contains a display and some buttons for user manipulation. Other types of systems use a decoder box which connects to a PC through the serial port, relying on the PC software to do the work of converting the angles. My system is of the second type. The circuit I describe below is the decoder box, and it connects to the serial port of your PC.

My Decoder Box Design

My decoder box design centers on the use of a PIC16F84 microcontroller chip from Microchip, Inc. This versatile chip is easy to program–the software development tools are available from Microchip for free, and the hardware programmer (the device which places the code into the chip itself) can itself be built cheaply and easily (and reused for other projects).

Here is the schematic diagram of the decoder box:

Digital Setting Circles schematic diagram
Digital Setting Circles schematic diagram

Some words about the design are warranted. Starting in the top left corner of the schematic is the voltage input and voltage regulation. U1 is a 7805 voltage regulator which supplies a regulated +5V DC output for the rest of the circuit. D1 is a polarity protection diode, to protect the rest of the circuit in case the battery is connected backwards. The battery itself should be able to supply +9 to +15V DC at at least 50 mA (I’ve used a 9V transistor battery and gotten a few hours of operation). You could also use a wall-wart type DC power supply with the appropriate voltage and current rating. D2 is an LED power-on indicator, and R13 serves to limit the current through D2. If you don’t want the power-on indicator, simply omit those two parts (and the corresponding ground connection, of course). Capacitors C1 and C2 help filter out any voltage ripple in the input.

U2 is the heart of the circuit–the PIC16F84 microcontroller. It performs two functions: monitoring the encoder channels and tracking encoder positions, and communicating the encoder positions to the PC. There are six data lines coming into U2, described in the table below. Two are for serial communications with the PC, and the other four are the A and B channels for the two encoders. U2 monitors the encoder channels, updates the encoder angles (which it stores internally), and listens for and responds to queries for the encoder angles from the PC. The PIC16F84 has to be loaded with a program for it to perform its function. This is detailed on the construction page.

Pin Label U2 Pin Number Function
RB0 6 Serial input from the PC
RA1 18 Serial output to the PC
RB1 7 Altitude encoder channel A
RB2 8 Altitude encoder channel B
RB3 9 Azimuth encoder channel A
RB4 10 Azimuth encoder channel B

The unused I/O pins on U2 are tied to +5V using 10K pullup resistors (R6 through R12). Power is applied to pin 14, and pin 5 is ground. Pin 4 is the reset pin, held high through 10K pullup resistor R1. The connector labeled RESET provides an easy way to short pin 4 to ground momentarily to reset U2 (restart its program) if necessary. C3 is an additional filter capacitor (to take out any voltage ripple).

OSC1 is a TTL oscillator which supplies U2 with a 4.0 MHz clock signal. The output of OSC1 goes to pin 16 of U2. The speed of OSC1 determines the speed at which the program in U2 will execute. U2 instructions execute at 1/4 the rate of OSC1 (in this case, 1 MHz). The speed of OSC1 must be 4 MHz for the device to work properly, as the timing for the serial communications is based upon a 1 MHz instruction time.

U3 is a MAX232 TTL-RS232 level converter. The serial communications pulses generated by and expected by U2 are at TTL levels (0V and +5V), while a PC expects RS232 levels (-12V and 12V). The MAX232 takes care of converting one to the other so that the PC and U2 each get the desired levels. Capacitors C4 through C7 are specified by the MAX232 data sheet, although I don’t know exactly what their functions are. J1 is the DB9F serial connector for a serial cable connected to a PC serial port. Note that some of the pins on J1 are connected to each other. This is to simulate serial handshaking if the serial port on the PC requires it.

JP2 and JP3 are the connectors for the two encoders. There are 10K pullup resistors on channels A and B of both encoders (these are R2 through R5). You might notice that I connected pins 4 and 5 on each connector. This is so that I can use a four-pin connector instead of a five-pin connector if I desire, since pin 4 is not used. That way, I get ground from pin 4 instead of pin 5. Shorting pins 4 and 5 on each connector has no effect if you’d rather use five-pin connectors, though.

Special Note for PDA Users

The interface circuit can be used successfully with Palm and Handspring PDAs as well as Pocket PCs (and probably others, though I haven’t tested them). See my software page for software that can be used with PDAs. Note that you will need a serial cable for your PDA–a USB cable will not work, even with a USB-to-serial converter. The serial cables for these PDAs generally have a female serial connector rather than a male, so you’ll need an adapter in order to plug it into the interface board. DO NOT simply replace the female DB9 connector on the interface board with a male DB9 so that you can plug in the visor cable. The pinouts between male and female are reversed (so the pins line up when male plugs into female). An easier approach is to just leave the female connector in place and buy or make a null modem adapter. You can make one from two male connectors if you connect them as follows:

pin to pin
2 – 3
3 – 2
4 – 6
5 – 5
6 – 4
7 – 8
8 – 7
(pin 9 is not connected)

Special note about Handspring Visors: the Visor serial cable expects to be supplied with power from the PC it’s plugged into, but in your case there is no PC–only the DSC interface. You can supply power to the cable by connecting pin 8 of the DB9F connector on the cable (or pin 7 of the DB9F connector on the interface, because of the null modem adapter) to +5V using a 270-ohm resistor. Since the interface uses a voltage regulator to supply +5V to the chips in the circuit, it’s easy to find a spot in the circuit from which to tap the +5V. Be sure to include the 270-ohm resistor to limit current flowing to the Visor serial cable. This modification should work for the Visor, Visor Deluxe, and Visor Platinum.

Communications Protocol

The interface communicates with the PC through one of several predetermined protocols. I’ve implemented protocols for BBox, NGC-MAX (which is also SGT-MAX and a few others), and MicroGuider III. Each of these protocols requires the interface to wait for a command from the PC via the serial port, and to return information (such as the current encoder positions or interface status) based upon the command received. In other words, the interface doesn’t speak until spoken to.

Besides the other interface types I’ve mentioned above, I also implemented my own protocol for communications. Here’s the protocol I implemented. Note that everything is byte-oriented. A, B, C, and D are always single bytes (hence the usage of low byte and high byte).

Received Reply Description
zABCD r Set the encoder resolution (ticks per axis revolution):

A = declination resolution low byte
B = declination resolution high byte
C = right ascension resolution low byte
D = right ascension resolution high byte

h ABCD Report the encoder resolution (ticks per axis revolution):

A = declination resolution low byte
B = declination resolution high byte
C = right ascension resolution low byte
D = right ascension resolution high byte

y ABCD Report the encoder positions (range from zero to [resolution-1]):

A = declination position low byte
B = declination position high byte
C = right ascension position low byte
D = right ascension position high byte

p A Report the number of encoder errors and reset the counter to zero:

A = number of encoder errors

Construction

My construction page covers the building of this interface.

24 thoughts on “Circuit Description

  1. Hello,

    I need more information for communications protocol :
    I have 2 encoders with 4000 ticks, so

    1) if i send the command ‘zABCD’, what is the value of A,B,C and D ?

    2) if i send the command ‘h’, i receive ‘ABCD’. The declination position is Ax256+B ?

    Thanks for your help.

    Reply
    • 1) The z command sets the encoder resolutions (ticks per axis revolution):

      A = declination resolution low byte
      B = declination resolution high byte
      C = right ascension resolution low byte
      D = right ascension resolution high byte

      declination resolution is 256*B + A
      right ascension resolution is 256*D + C

      So if the resolution on the declination axis is 4000, then the high byte is 15 and the low byte is 160 (15*256 + 160 = 4000).

      2) declination position is 256*B + A, and right ascension is 256*D + C.

      Reply
  2. Hi Dave,
    I got the Bluetooth module today and it’s a surface mount module that would look much nicer properly mounted on a new board, so I’m going to do a new board (after I wire into your current board to make sure it works).
    I was reviewing your schematic and I was wondering if you felt that R6-R12 were really necessary? Can’t those pins all be tied to VCC directly? Also, how could I go about getting another PIC?

    Thanks!

    Craig Combes

    Reply
    • R6-12 can be omitted completely (there’s no need to tie those pins to VCC because there are internal pullup resistors). Also, you can obtain another PIC from FAR Circuits–just email them and ask for a price.

      Reply
      • HI Dave.
        With regard to your statement that
        “:R6-12 can be omitted completely (there’s no need to tie those pins to VCC because there are internal pullup resistors). Also, you can obtain another PIC from FAR Circuits–just email them and ask for a price.”, are you saying that P6-12 does not need to have resistors, And, Do not have to be connected to VCC at all and left untouched with no power at all?
        Thanks, Jim

        Reply
  3. Hi Dave,

    I have made a Dob mount for my scope. Can I use your DSC with an alt-azm mount? I am not sure if your onboard software take care of calibrating the sensors (via multi-point alignment) or is it the PC software?

    I don’t want to build a GOTO; a PUSH TO would suffice.

    (I am new to the topic of DSCs).

    Thanks,
    Harshad

    Reply
  4. Hi Dave.
    Great project this. I am working on a PCB-board for Mel Bartels system but with better motordrivers and an IR remote interface, and the abillity to work standalone if you just want a quick setup without computer. I would like to incorporated your interface too on the PCB. I see that people has asked for the sourcecode of your settingcircles and if you agree on this it means that I can incorporate the code in my bigger proc that handles the other stuff and minimise my board some. If you want to send me the code I would much apreciate it (but understand if you dont..).

    Best Regards

    Per

    Reply
  5. Dave – I came across your site 5 years ago and was inspired to do my own DSC system with a PIC. I did it and it works great. The software I wrote also has a Messier catalog for look-up. The system is accurate.

    Currently, I use the Hand-held wand (that I designed with a cool red LCD) and it’s hardwired via a plug-in phone wire. I’m thinking of using my Android phone and going Bluetooth to the DSC and started surfing the net for transmitter/rcvr. I came across your site – it’s been a long time since I checked you out – really glad to see/know folks use you as a resource.
    You can check out my digital setting circle at my site
    http://www.galaxypoint.com

    Reply
  6. Am interested in building this project, but the laptop I would use does not have a serial port only USB are there any work around for this

    Reply
    • There are two options. First, you could use an inexpensive usb-serial converter to add a serial port to your laptop. Second, you could use bluetooth–you’d need a serial-bluetooth converter plugged into the encoder box that would connect to your laptop’s native bluetooth support. If your laptop doesn’t have built-in bluetooth, you can buy a usb-bluetooth adapter. I use the bluetooth method.

      Dave

      Reply
  7. I have build the your circle setting usb from far circuits. i `m ordered
    the ftdi TTL-232R-5v cable in Germany. The cable outputs are red 5V black ground, white RXD, green TXD, yellow RTS, blew CTS. Is not the same at the circuit. can you help to connected the cable.

    Ulli

    Reply
    • Ulli,

      The datasheet I have for the TTL-232R-5V shows different colors, but I bet the pins are in the same order. Connect the wires as follows:

      TTL-232 ground (BLACK) -> board BLACK
      TTL-232 5V (RED) -> board RED
      TTL-232 TXD (GREEN) -> board ORANGE
      TTL-232 RXD (WHITE) -> board YELLOW

      I’ll bet the TTL-232R connector pins line up with the board pins. If they don’t, make sure you double-check your information before you connect.

      Hope this helps.

      Dave

      Reply
  8. hi dave, i am trying to decide on what cpr to get for the encoders, 1000 or something more. i have far circuts kit (serial). and plan on using blue tooth. i want to be as acurate as possible but i don’t want my dsc to skip. I have a dob 15′. Can you offer any advice. I dont care about price to much. thanks .

    Reply
    • Bill, if there is no gear ratio between your encoder and your dob mount, 1000 cpr encoders would work fine. You could probably go up to 2000 cpr, but I wouldn’t go any higher. Remember that your actual resolution will be 4 times the cpr rating of your encoders because you’re using them in quadrature mode, so with 1000 cpr encoders you’ll get 360/4000 = 0.09 degrees/encoder tick, which is perfectly fine for finding objects in the sky. Imperfections in your mount will prevent you from being much more accurate than that.

      If you have a gear ratio (you’re using pulleys or gears to connect the encoder to the mount, and the encoder doesn’t turn one time for each one turn of the mount) you’ll have to adjust accordingly. For example, if your gears cause the encoder shaft to rotate twice for each revolution of the mount, then a 500 cpr encoder would work fine.

      Hope this helps –

      Dave

      Reply
  9. Hi Dave, thanks for sharing your work!
    I have built the circuit but I can not find the pic 16F84,
    ¿can I use a pic16F84A instead?, ¿can you give me the source code for that pic?
    For serial connection, ¿is sufficient to connect the pins 2-3, pin3-2, pin 5-5?
    Best regards
    Alejandro
    Montevideo, Uruugay

    Reply
    • Hi Alejandro,

      Yes, you can use the PIC16F84A with no problem. And the three serial connections are all you need. I don’t usually give out the source code for this project.

      Thanks,

      Dave

      Reply
  10. Hi Dave,

    I’m curious, where did you find the specs for the BBox & NGC-Max protocol? I’ve looked all over the place and haven’t been able to find it. Also, is the NGC-Max protocol more complicated then what they show in their example BASIC code or are there other commands other then just ‘Q’ as well?

    Reply
    • Hey Aaron, as far as the BBox protocol goes, I was able to obtain that from the Software Bisque back in the 90’s. As far as NGC Max goes, I think the Q command is pretty-much it. I don’t really have any solid documentation on that.

      Hope this helps –

      Dave

      Reply
  11. Hi Dave,

    I have the USB-version of your circuit.
    When I plug it in to USB I have de red numbers in the tester.
    But I measure 5.09V at the two pins CHA en CHB.
    I controlled all my solder joints and I have de right USB-cable.
    Is this normal?

    Best regards,
    Stijn

    Reply
    • Stijn, if you do not have any encoders connected, the voltages should be about 5V (5.09V is okay). Resistors R2-R5 act as pull-up resistors on CHA and CHB to “help” the encoder. If you have encoders hooked up, you should see the voltages change between 0 and 5V on each channel if you can rotate them slow enough to change only one channel at a time.

      Dave

      Reply
  12. Hi Dave, just came across your project and would like to build it for my 12 inch dob (soon to be “planted” in the garden on a permanemt polar mount- but that’s another project…). I have also done quite a bit with pics over the years, a look in the junk box shows a number of 16f88’s and some 20MHz crystals. Would it be possible to get you to recompile the firmware to suit a 16f88 running at 20MHz?
    I will be laying out my own board with a bluetooth module on-board so I can dispense with the ttl-rs232-ttl conversions and associated wiring, as I don’t have any pc’s with serial ports any more, only laptops with bluetooth.

    Thanks, Ken, vk7krj
    http://www.vk7krj.com

    Reply
    • Sorry, Ken, but it’s actually a major change to the code to run it at a different clock speed–all the timing loops would have to be rewritten in order for the serial communications to function correctly. The same is true for a major change in chips–the architectures are often very different. I’m afraid you’ll have to shell out a few bucks to get the specified chip and crystals. :-)

      Dave

      Reply

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> 

required