There is a couple of similar projects available on the internet. Some of them base on Arduino and PIC performs very basic mount control without math intensive computation implemented in embedded controller. I decided to build my own with the following goals:
ease of use by an inexperienced amateur astronomer (full automatic operation)
precision and resolution of position
last but not least: the price
Final, or better say at the moment, design comprises of the following components:
Stellaris LM4F launchpad central control unit,
two ULN2003 unipolar stepper motor driver chips,
two 28byj-48 stepper motors one moving in azimuth, and in elevation via gear train,
communication module: Bluetooth serial module. It allows sending a coordinate set-point and provides position feedback to Stellarium,
GPS module providing position and precise time reference - PPS gives 1us accuracy,
Nokia 5110 display unit and joystick for standalone operation,
now obsolete mouse (PS/2) modified to provide independent (incremental) position information
Resolution that was reached is a single step of approx. 5". Given the size of Jupiter to range from 30" to 50", this positioning resolution makes the view comfortably stable in standard 60° FOV eyepiece at reasonably high magnification, without the need to adjust AZ/ALT continuously.
During the development I made use of several opensource and projects available online, namely:
AccelStepper for stepper control,
TinyGPS++ for NMEA decoding,
Arduino telescope controller was my inspiration and reference for Taki's matrix method for coordinates transformation,
of course Energia as my IDE
Upon power-up the mount is performing:
acquisition of current location (longitude/latitude) and time via NMEA stream
moves to 3 brightest (most convenient) stars in succession to perform 3 star alignment procedure - they are selected from the list of over 500 stars in built-in catalog (the brightest are used for the alignment, tough),
once aligned the mount is in tracking mode: it tracks the view to counter the apparent movement of objects in the sky,
waiting, either for the user to move to particular object - selected from the library of stars and Messier objects, or
awaits connection via Bluetooth from a PC running Stellarium with a plugin and slews to selected object.
search for the object that should be visible in the eyepiece and display important information on LCD - I compiled in 500 brightest stars from HYGXYZ and full Messier catalog.
I have very little experience as amateur astronomer so far, so some of the objectives might have been not very obvious for me in the beginning. This project was also a good way to make use of my free time and gain experience in embedded system design.
You can drive 4 7-segment LED displays plus a decimal point for one digit using 9 pins with a very simple circuit. This makes it possible to make a display with the 14 pin micro such as the one that comes with a launchpad (MSP430G2231 IIRC). The following description assumes that the segments are common cathode.
The secret is to use 2 npn transistors and 2 pnp transistors for the digit drivers. The segments can be driven directly by ports. No resistors in series with the segment driver pins are required, as the segment current is self-limiting to a reasonable value.
Each of the two digit driver port pins is used to drive one NPN as an emitter follower (collector connected to 3.3 volts), and one PNP as a common emitter (emitter connected to 3.3 volts).
Each driver port pin is connected to an NPN base, and from the driver pin to the base of the PNP via a resistor of about 2K. I used 2n3904 and 2n3906 xstrs with 1.3K base resistors which I think is lower than required. The resistors must be small enough for the PNPs to saturate when they are driving 2 segments.
I drive 2 segments at a time in order not to exceed the total current required by the micro. With an interrupt at 1 MSec, driving 2 segments at a time, for each of the 4 digits, means that there will be 16 cycles (taking 16 MSec). This is fast enough for no flicker and a display that is bright enough to read.
When the driver pin is high the digit connected to the NPN emitter is on. When the driver pin is low the digit connected to the PNP collector is on. When the pin is configured as an input neither digit is on. Repeat for the other 2 digits.
This works great for LEDs that need 2.0 or 2.1 Volts to turn on. I used MSQC4911C displays.
Because the emitter voltage of the NPN will be about 0.6 volts below VCC when it is on, and the PNP collector will be about 0.3 or 0.4 volts below VCC, the NPN digits will be slightly dimmer than the PNP digits. There are two ways to correct this:
1) Put a Schottky diode in series with the PNP collector. This will make the voltage that the digit driver sees about the same as for the NPN digit.
2) In the code driving all this, let the on-time for the NPN transistors be longer than for the PNP transistors. I select them so that the average is 1 MSec.
I have tried both methods with good results, and have tried it with 3.3 Volts instead of the normal launchpad voltage of 3.5 volts.
In order for the circuit to determine what segments to display, the one remaining I/O pin is configured to accept serial data with auto-baud, sort of like the LIN protocol, but simpler. Of course a 32KHz crystal is not installed as the pins are needed for the display, hence the need for auto-baud.
If you want one decimal point to be turned on, connect the cathode of the decimal to ground through a resistor, and connect the anode to the appropriate digit driver pin. The decimal LED will be on whenever the corresponding digit is on.
Once I get around to doing the documentation I will publish a project.
PS - I've done this in two other ways:
1) Use 'Charlieplexing'. This can be done with 6 pins and no other parts, tho the display is not as bright. Only 30 segments can be driven this way, so it won't do a full 4*8.
Charlieplexing requires individual digits, not ones with common cathodes. As a compromise between brightness and flicker, I drove 20 segments with 1 MSec interrupts. If more than 20 segments are on, there will gradually be dimmer displays and some flicker if it stretches out to 30 segments. If fewer than 20 need to be on, just turn them off until 20 MSec have been used; this keeps the display at a constant brightness.
With random data about 20 segments or fewer will be on at a time, usually.
2) Use 2 common-anode digits and 2 common-cathode digits. A pair of CC-CA digits will have their digit drivers driven by one pin. When it is high the CC digit will be on, and when it is low the CA digit will be on. When it is an input neither will be on. No other parts are required. The only problem is that I can't find CC and CA digits that are matched in appearance and in on-voltage. I have a few that seem to be no longer available.
It is probably obvious, but the segments for the CC digit must be driven low to turn them on, and the CA segments must be driven high.
This is easily taken care of with the software. As the MSP430 has fairly symmetrical drivers there is not an issue with differing brightness.
If you use a 20 pin part such as the MSP430G2553, just use 4 NPN emitter followers as digit drivers. Again, no resistors are needed for the segments. You will use 12 pins; 4 for the digit drivers and 8 for the segment drivers (or 7 if you don't need a decimal point or a colon). You could probably do away with the emitter followers; just drive 2 segments at a time as described in the first part of this note.
PPS - I 'invented' the NPN-PNP technique, but like so many inventions it is quite possible that someone else invented it first. Also note that the code I hope to publish uses the excellent naken_asm assembler, but the code could be easily modified for CCS, MSPGCC, or whatever. It could even be done in C if you don't like assembly language.