logo
background
 Home and Links
 Your PC and Security
 Server NAS
 Wargames
 Astronomy
 PhotoStory
 DVD making
 Raspberry Pi
 PIC projects
 Other projects
 Next >>
[PIC GoTo  Dobson controller] [What do we want from a GoTo  mount controller ?] [Dobsonian Push-To controller] [Sense accuracy] [The HMC5883L 'digital compass'] [Using a rotary encoder] [Rotation sense using a potentiometer] [Maximnising PIC DAC sensing accuracy] [Push-to user GUI]
PIC Push-To

PIC GoTo (Push-To) Dobson controller

The low-power PIC is ideal for battery operations = it will run from 2v to over 5.5v (unlike the Raspberry Pi which 'falls over' unless supplied with 5.2v) and it's power consumption is essentially OSC dependent (so low speed OSC = low power)

[top]

What do we want from a GoTo (Push-To) mount controller ?

No doubt a 'top end' PIC device can be used as a complete stand-alone 'GoTo' controller = indeed, the commercial SynScan, Meade AutoStar and Celestron NexStar hand controllers all contain 'PIC style' controllers - however the software effort required makes it a rather daunting task

In any event, why bother to 're-invent the wheel' ?
 
Theres lots of suitable software (such as Stellarium) whihc will runs on multiple devices (including the Raspberry Pi) that can provide excellent 'GoTo' functionality (including a GUI and telescope control)

The most basic function required of the actual telescope 'controller' is thus to act on movement commands and support the detection and transmission of the actual movement (or 'current location') data back to the (external) software

If the control software is running on a tablet or smart phone, communicating with the PIC does present some challenges.
 
Whilst some PIC devices do come with built-in USB hardware support the necessary software drivers take up the majority of the progream space (and CPU cycles). Further, they emulate 'Keyboard' style 'slave' devices - so allow USB cable connection to a 'controller' but can not drive common 'USB dongles' (such as IrDA, Bluetooth or WiFi)

The simple way to communicate with a PIC is via a serial link. This means using an older laptop (or a Raspberry Pi) to host the 'GoTo' software  

[top]

Dobsonian Push-To controller

 

The function of the PIC is to 'sense' the 'position' of the telescope and pass this back to the GoTo software. The GoTo software then sends back 'move' instructions which the PIC converts to a 'user interface' for 'push-to' operation

 
The simplest way to detect 'position' is to use some sort of rotary sensor. Many exist that can detect movement, but only a potentiometer allows the 'absolute' position to the detected (a 'movement step' sensor always has to 'start' counting from a 'known start position')
 
Fortunately, even many of the low-end PIC devices incorporate an 8 or 10 bit A-D converter = so sensing a potentiometer position to an accutacy of 1 in 256 (or 1 in 1024) is 'dead easy'.

Sense accuracy

If a pot. is connected to the Dobsonian vertical axis, we only need to sense the angle from vertical to horizontal i.e. cover an angle of 90 degrees.

An 8 bit DAC gives an accuracy of 90/255 = 0.35 degrees.
 
A 9mm eyepiece on a 10" Donsonian typically covers approx 0.5 degrees, such accuracy is (only) just enough to place the chosen object in the eyepiece.
 
Using a more typical 25mm eyepiece, the FOV is 1.25 degrees meaning the object will be in the eyepiece FOV when the telescope is pouinted to within 3 or 4 steps of the target count

However whilst it's easy enough to 'calibrate' the vertical position (all you need is a spirit level to measure from 'perfectly flat' to 'absolutely upright' (and a button or two on the PIC i/o pins to tell the PIC to 'reset' it's count), horizontal positioning requires both 360 degree sense and the ability to start (calibrate) 'pointing North'

If the Dob. base is to be moved through 360 degrees, it's going to be hard to use a potentiometer (whihc has a limited travel).
 
Even if we 'wind it back' at the end of each session, there's still the issue of how to initialise it (i.e 'point North').
 
A rotary encoded could be used, however the probelm with these is that they provide no 'absolute' position. The electronics has to 'count' steps - so a PIC that goes off to perform time sesitive things (like serial comms) can miss steps. Further, they tend not to be very good when it comes to small back and forth movements (as you would get when 'hunting' for position)
 
One solution is to use a digital compass - this solves the 'dfind North' problem and provides absolute position, but they are not the most accurate things in the world.

[top]

The HMC5883L 'digital compass'

This is the chip fitted to most (if not all) Reaspberry Pi 'digital compass' modules. It's described as a "3-axis digital compas" however what it actually does is to measure the (Earths) magnetic field in the X,Y and Z direction and deliver the 'raw' data vaules. External software then has to convert the readings into a 'compass heading' (and inclination, if that's needed).

It's not obvious from the data sheet, this overview reveals it has a 12 bit DAC. This performs serial measurements on the axis sensors.
 
The 16 bit raw X,Y,Z values are processed by the host software driver to give a 'pointing' accuracy of about "1 to 2 degrees" - but thats NOT from a single measurement :-)
 
Whilst you can perform 'single' measurements, the only way to get an accurate result (to better than 5 degrees) is to have the chip perform continuous measurements and have the software discard obviously 'wrong' values (the chip will 'give priority' to I2C data comms, which means the measurement sequence can be truncated) as well as 'averaging' at least 32 successive data sets.
 
User reports suggest that it's rather sensitive to it's orientation in the Earths field, however this can be addressed by using 2 modules offset by 45 degress in the X,Y and Z direction.
 
Further, the Earths field is extremely weak and easily effected by any nearby metal objects = and this would include the Dobsonian OTA.
 
Although the tube rotates with the 'compass', this will still cause an 'offset' (as it rotates throiugh the Erths field) and when the inclination of the tube is adjusted this is bound to result in other changes in the field detected (even when it's not being rotated). Of course, the inclination is being measured, so the software can detect inclinaion changes and should (at least to some extent) be able to compensate.
 
Next is the bolts holding the 'feet' to the Dobsonian base plate. These are going to have a massive effect when the sensor moves over them and whilst metal bolts could be replaced with nylon ones, we then have to worry about the other bolts holding the base together !
 
Finally, it turns out that Earth magnetic field sensors are sensitive to the magnetic fields generated by flowing currents (a 50HZ 'wobble' will be seen when making measurements inside any building with UK mains power) - and if our push-to GUI relies on "blinking LED's", each LED blink can upset the sensor (although running the LED drive wires inside the OTA might be sufficient to eliminate any external effect) !

The demo code found here requires a 'declination angle' - in other words it needs to know your local Earth field angle (about -0.75 degrees where I live) and assumes the sensor is 'flat'. The code will then read the sensor and give the compass heading. Typically, 'noise' (variation between successive readings with no movement of the sensor) is about 0.5 of a degree

[top]

Using a rotary encoder

The difficulty in getting decent compass direction accuracy as the OTA is rotated encouraged me to look again at using other sensors. The rotary encoder was initially 'ruled out' becuase it couldn't give an 'absolute' position - however IF the 'compass' can at least be used to detect 'pointing North', then an encoder can be used to detect 'steps away from North' !

By placing the sensor in a position such that the OTA is 'symmetrically' aligned (i.e. is causing an 'equal' distortion in each directions), magnetic North can be determined by rotating the Dob. mount back and forth and looking at the 'raw' East-West data value for a 'minimum' (assuming -ve = East, +ve = West, then 0 = North (or South))
 
All we then need is some way to detect 'steps away from North'.
 
The goal is 'at least' 1/3rd degree accuracy. This means that in 360 degrees we want just over a thousand steps (3x360)
 
Ideally, this means an encoder bolted to the axis (any gearing can be a cause of 'backlash').

A standard rotary encoder contains a 'gear wheel' and a pair of switches. The switches are activated by the gear teeth, and positioned 'offset' by 'half a tooth' (so when one is 'closed' (CLK) by the tooth the other is 'open' (DET = detent, between the teeth). By noting the order in which each switch opens and closes you can work out the direction. They typically have between 9 and 24 teeth ('detents') per revolution

Plainly this is not going to work = even a 10:1 gear would only give 240 'clicks' (and wear out the switches and teeth really fast). What we need is a non-mechanical encoder = and that's exactly what I built for my 'Barn Door' Electronic drive.
 
My Barn Door position sensor had 96 'marks' and movement only had to be 'detected' in one direction. To detect direction, two sensors are required (offset by half a 'tick mark'). However to get even close to 1000 steps per rev., 10:1 gearing would be needed, and as direction detect depends on which sensor is activated first, any backlash will be a real issue.
 
So we need to look for 'off-the-shelf' uits that will give at least 1000p/r (pulses per rev)

At the time of writing (Jan 2017), the OMRON Rotary Encoder E6B2-CWZ6C range can be had from China at a reasonable cost = a search on eBay for '200P/R' found me the "OMRON Rotary Encoder E6B2-CWZ6C 2000P/R" for a very reasonable £17.96 (yep, about 10% of the UK 'list' price)

A "600P/R Incremental Rotary" can be had for £7.25, however these are 'no name' brand with no data (but do come with a warning that wiring them up incorrectly will burn them out = so, rather a shame they don't bother to tell you which color wire is Vcc then, unlike the Omrons where the wire coding is printed on the sensor itself ..)

[top]

Rotation sense using a potentiometer

The 'only' problem with using a Pot. is the need for > 360 rotation without running into the end stops

Whilst few observing locations offer a full 360 degree 'panorama', we can always point 'straight up' and track stars all the way around Polaris. So 360+ is a must (and fitting mechanical 'stops' to limit the Dob. base rotation is not really acceptable, even if the 'end stop' can be switched from the North to the South as required)
 
The only simple (direct connection = minimal backlash) solution is to use a 5 turn Pot. and 'reset' it's position to '2.5 turns' after each observing session.
 
Even so, some sort of 'slipping clutch' is still going to be needed to avoid wreaking the Pot. if (when) it's end stop position is reached.

A PIC processor with a 10Bit DAC will provide the necessary 1024 positions, and can even be used to provide a flashing LED guide to assist the 'reset to 2.5 after use'

[top]

Maximnising PIC DAC sensing accuracy

The PIC DAC 'reference' voltage sets the 'full range' voltage.
 
 
 

[top]

Push-to user GUI

 

All the calculations can be done on the Raspberry Pi (or whatever). So all it has to do is send the required 'count' (potentiometer position) to the PIC - and all the PIC has to do is indicate 'up' or 'down' to the user

 
This can be done with a couple of LEDs = the faster the up or down LED is 'blinked' the faster the user has to move the Dob. = when 'on station' the LED's are turned off (so as to avoid interfering with 'seeing')
 
NOTE - the LED's can be positioned at the mirror (so will work no matter what the eyepiece) and DP-DT switch (or PIC control i/o pin) used to swap the LED's over (to compensate for field inversion when 90 diagonal etc. is used)

Next subject :- PIC Video Time Insertion - (OSD)

[top]