Part 1: What complicated electronicality goes into your average GoTo mount?
Answer: Not as much as you’d think!
In fact, that’s it. The above picture comprises the entire guts of an early generation (circa 2000) Celestron Nexstar GoTo Mount that accompanied a 90mm refractor scope. This particular example is a dead one, but it’s enough to show us what’s going on.
So what have we got there? Let’s break it down…
The Control Board
Ooohhh… it’s got chips on it. Must be clever.
No. Ultimately there are 3x components here that do the work. On the right are 2x XIC0014 oscillators with a 4mhz crystal each. We can summarise their job as: timing. These keep tabs on timing for signals going to and from each motor.
On the left in the middle we have a 74HC240D. This is an octal line driver which takes 8 incoming teensy pulse signals and amplifies them into 8 larger pulse signals.
In the lower left corner we have an L293DD. This is a part of interest. This is a 4channel H-Bridge motor driver.
The pins on the right hand edge are for the hand controller. The pins on the left hand edge are for the Azimuth motor (left & right horizontal motion). The pins on the top edge are for the Altitude motor (up & down vertical motion). That’s a lot of pins for a motor tho…
There’s also a MOSFET up top, which will be involved in regulating the incoming 12v DC down to 5v DC to run the electronics.
The Handset board
Nothing complicated here. It’s an RJ45 socket, mounted on a board along with the 12v power connector. Black & Red are 12v, which goes up to the handset, and across to the controller. The remaining 4 wires carry TTL signals from the handset to the control board.
The Motors (x2)
The mount contains 2x motors (EDIT: I suspect these are 38mm low profile 12v DC Brushless ~4000rpm). These are DC controlled, and rely on 2 wires only. So what are the rest of the wires (6x) for?
Mounted to the rear of each motor is an optical encoder wheel (45 steps per revolution). The black box at the top has an LED mounted in it, pointing at a light sensor (These are Honeywell HOA 0902-11 Optical Encoders). In between these, the wheel passes. Note the slots. The sensor detects the light being blocked and unblocked by the wheel, and converts these into pulses. So there are 2 wires providing Grnd and 3.3v to the LED.
The encoder itself outputs one pulse for each slot. This is our speed signal (by counting pulses over a period of time), and by storing the count they can be used for position also. That’s one wire.
It also outputs a direction signal. This is a high or low (on or off) signal. If the output is high, the motor is moving forwards. If the output is low, it’s moving backwards. That’s another wire.
The encoder circuit needs power… 5v & grnd. That’s another 2 wires, giving our 6.
Each motor mounts to a gearbox. I haven’t a clue of it’s ratio [EDIT: It’s basically a 1000:1 Type 225 Spur Ovoid from Rotalink), but from the surface dimples we can see that it contains an input gear, which translates it’s motion through 4 other gears, then to a 16 tooth output gear on the other side…
…which in typical fashion is smothered with the stickiest cheap & nasty grease known to man. This drives the 120 tooth transmission wheel, which uses a friction plate to move the relevant part of the actual mount. Again, this is liberally smeared in sticky cheap mank.
[UPDATE: I later worked out that the optical encoders are 45 steps per revolution, and the gearboxes are 1000:1 ratio, so that gives us 45000 pulses per revolution at the output gear. This then drives a 120 tooth transmission wheel. So, that turns into 45000 * 7.5 pulses per revolution, thus 337500 pulses per revolution at 937.5 pulses per degree, and a final resolution of 3.8 arc seconds per pulse at the transmission wheel… I think!
Sidereal tracking rate is 15.035 arc seconds per second, so that’s 3.9 pulses per second = 234ppm(?) needed at the motor – my maths probably went screwy there, so don’t trust those figures at this stage!]
All the control board does is translate signals from the handset directly into drive commands for the motors. ALL the intelligence is in the handset. A bit of diagnosis tells me that the handset for this mount has been fried, along with the control board, but both motors and encoders are in perfect working order, so how can we resurrect this setup?
Seeing as all the control board is is a 2 channel H Bridge motor driver and feedback sensor board, we can replace the lot with a Raspberry Pi and a few bits.
The Raspberry Pi’s GPIO pins can quite happily output 2 channels of PWM to control the motors themselves, and can easily receive 4 channels worth (2 per motor encoder) of feedback pulses. All we need to do is get power to everything. Conveniently, all the bits needed can be picked up for a grand total of sod all (or less) from most robotics hobby places.
I already have a veritable mountain of Raspberry Pi boards so I don’t need to acquire one. These cost me £18 each.
To hook up the motors, I’ll need a dual channel Pi motor driver board, so I’ve opted for a DRV8355-based kit which can take a 12v DC power supply to run the motors, and with the addition of a 5v step-down board it can also power the Raspberry Pi itself which in turn can power the encoder boards (which also run at 5v). The Pi also provides a 3.3v output which can power the LEDs on the encoder boards. These two components from the provided links total £12.36 inc shipping. Add the cost of the Pi, and that’s £30.36 for a replacement control board.
That’s it for today. Mainly because I’ve just ordered the aforementioned bits, and now need to wait for them to arrive before we can proceed with connecting the motors to the Pi and starting this journey properly…!
Continued in Part 2 – where we strap the bits together and make things spin.
You must be logged in to post a comment.