EQ2 mount motor

[Kyuzumaki]

Hi i'm making a small tracking mount for a dslr using a second hand eq2 and a small stepper motor (a 28bjy-48). I want to have a selector switch similar to the Vixen polarie for star tracking,1/2 star tracking, moon and sun. 

What i'm struggling to work out is the speed needed for these types of tracking at the drive shaft. Obviously the more accurate the better. 

So far I think I have calculated celestial speed is 1/1436 rpm at the output but all my numbers end up being very small decimals so i'm guessing theres a better or more standard way of expressing these speeds and converting them to drive a mount.

[furrysocks2]

My experience with Arduino's and the like, is that you work backwards from desired output tracking rate, through internal mount gearing, external belts/gearing to get stepper shaft speed, through stepper step angle and 16x/8x/etc microstepping to get a value for inter-step sleep in us or ms or whatever. Arduino's typically need an external real-time clock (crystal) to get the desired accuracy. You should be able to avoid drift, if not jitter, but how much that matters depends on your exposure times. I had several spreadsheets going at some point.

Don't know if that's helpful... how are you driving the stepper?

[furrysocks2]

In terms of units, you also want to know your arc-seconds per microstep (1/3600 of a degree) - I think the upper limit is 2 arc-sec/ustep for smooth tracking, but that's just from memory.

[furrysocks2]

You can also convert rpm into degrees/sec or arc-sec/sec.

[Kyuzumaki]

Thats a good point I hadn't considered drift being an issue had just thought the arduino would be able to do a good enough job. I'm guessing exposures of a few mins would be the max I can achieve anyway.  The plan is to use an arduino pro micro and a 6 pole selector switch for the control knob. I do have a real time clock module i got from ebay somewhere but i'm not sure how accurate it is either. How did you keep time in your own project?

I'll calculate the arcseconds per step today!

Any idea where to find the speeds for sun and moon tracking?

[furrysocks2]

With an RTC, drift shouldn't be an issue as you can adjust for cumulative error as a result on non-perfect step intervals as you go - the RTC should always give you an absolute reference. Provided your arc-sec/ustep is low enough, it shouldn't matter if your corrections mean that one ustep is a bit longer/slower than another, so you shouldn't suffer jitter.

I've not actually got any projects completed yet, but an RTC usually runs a watch crystal or similar and it pretty much standard, unless you go GPS.

Perhaps overkill but I got the aaplus library to run on an Arduino by compiling out a few of the high-precision data tables - meaning I could calculate the topocentric horizontal coordinates (local alt-az) for all the planets on the fly, corrected for atmospheric diffraction and the speed of light! So you could take this approach, but you'd have to be a nerd.

 

Re: actual rates, see here: http://www.ascom-standards.org/Help/Platform/html/T_ASCOM_DeviceInterface_DriveRates.htm

This gives 15.041/15.0/14.685 arc-sec/sec as the drive rates for sidereal/solar/lunar tracking rates. Note that if you take account of atmospheric refraction then the ideal sidereal tracking rate is actually a bit lower than 15.041 (cf. King). You should be able to calculate these rates for yourself (solar is just 24hr, lunar you account for orbital period of the moon as well). It's always going to be more complicated than this due to orbital geometries, refraction of light, etc... but you can either assume the error over an hour's tracking is low enough for practical purposes, or calculate it - shouldn't matter for solar/lunar as you can align frames in software, but for long exposures you should know your error.

 

All that said, if you don't have good polar alignment, you're snuffed for long exposures anyway. Which leads you into guiding.

 

(Disclaimer - I'm not an imager, I've just thought about it a bit - you might get a better answer...)

[furrysocks2]

Worth working out your arc-sec per pixel at the camera sensor, too - a function of sensor/pixel size and optics/field of view.

[Kyuzumaki]

That looks like a very useful code library for this kind of project. My aim is to create a portable system that allows me to take some nice night sky photographs when on holidays. Basically the same functionality as a Vixen polarie. I'm going to convert everything to arcseconds now

With my camera at 18mm for wider shots its 44 arc-seconds per pixel and at 200mm zoom it drops to 3.4 arc-seconds per pixel. Found this handy calculator if anyones interested https://astronomy.tools/calculators/ccd

The motor is relatively weak so hopefully with gearing it can manage the task otherwise i'll have to find an alternative 5v stepper or drive it off 12v