Chris.Rowland
Posts: 239
Joined: Thu Jan 12, 2012 5:45 pm

### Re: A question about timing

Dan,

I couldn't get to the interinair site because the system here complained about it being high risk.

The qkits thing looks like what's needed, I suppose the step rate for each motor can be set in the controller, that's what controls the tracking rate.  It isn't neccessary to adjust the rate that frequently, every few seconds will be fine. One thing to watch is that when you send a command to the controller to change the rate it does so smoothly.

I hadn't realised that you were using three motors, that should avoid field rotation.

The ability to do imaging will depend on the stability of the scope more than the tracking rate, a search round the astronomy forums on imaging from an equatorial ptatform will come up with a lot of opinions, unfortunately they will range from Totally Impossible to Easy.

Chris

drgeoff
Posts: 12417
Joined: Wed Jan 25, 2012 6:39 pm

### Re: A question about timing

Let t = time in minutes of a run

Let a= telescope's angle of view in degrees

Let p = number of camera pixels corresponding to the angle of view ('a' above)

Let d= "blur" measured in fractions of a pixel. ie d=10 means a tenth of a pixel accumulated error from true

Then earth's rotation over the run is 15t/60 degrees

1 camera pixel = a/p degrees

Earth's rotation is equivalent to (15t/60)/(a/p) pixels

For accuracy d, integer(15tpd/60a) must be accurate to 1 least significant digit.

eg t=90 minutes, angle = 1 degree, 4000 pixels across, d=20

Clock accuracy needs to be better than a 1 part in 15*90*4000*20/(60*1)

which is 1 in 1.8*10e6 ie 0.5 ppm

This is approx 10 to 100 times tighter than a bog standard crystal.  This implies:

1.  A "shrink wrapped" ready to go software package would not be viable.

2.  If some calibration method were devised to tweak the timings for individual RPs it would not be a "once and for all" procedure.  Aging and temperature variations are comparable with the accuracy needed.

The only number I really guessed at was the field of view angle.  Clearly making this wider helps.  There might be scope for a modest reduction in d but probably not below 2.

Others need to check and agree with the above before it is considered gospel.
Quis custodiet ipsos custodes?

Caleb9849
Posts: 6
Joined: Tue Feb 21, 2012 5:56 pm

### Re: A question about timing

Chris Rowland said:

There's been a number of things like this, such as Mel Bartels scope drive system. This uses the parallel port of a PC to drive two stepper motors, but it has to run under DOS.  This is because Windows will take over the CPU for enough time to give unacceptable jitter in the stepper pulses. I expect Linux will be the same.

Well, we did have some issues with jitter on heavier systems, but on a minimalist Debian install (no graphics, networking, etc., just basic needs and good old Bourne Again shell) that's dedicated to controlling the stepper motor, we fortunately get jitter-free results

It's unlikely that this would be used for long exposure astrophotography becuause field rotation will prevent long exposures and even if it is then guiding would cope with tracking rate errors.

I guess you already realize that field rotation is not a problem, but I wanted to point out for informational purpose that eliminating field rotation is part of the whole point of this particular class of platform -- the equatorial platform.  Because the platform counter-rotates the Earth and thus rotates in tandem with the sky, it can be seen as rotationally (in every direction) "affixed" to the sky, as if great long steel beams were rigidly attaching points on the platform to moving points in the sky.  Equivalently, had we not been using three motors, it woudld be physically impossible for this to be an "equatorial platform" to begin with.

The qkits thing looks like what"s needed, I suppose the step rate for each motor can be set in the controller, that"s what controls the tracking rate.  It isn"t neccessary to adjust the rate that frequently, every few seconds will be fine. One thing to watch is that when you send a command to the controller to change the rate it does so smoothly.

I have already developed a software application which guides the motors appropriately based on the latitude.  It doesn't even muck around with pulsing "rates" to accomplish this; it does so very precisely by constantly guiding the platform into "exactly" the position it should be in at the current time, based on a precise mathematical algorithm, with individual pulses to the motors (by "exactly", I mean as close as possible, given integral motor stepping).  I communicate to the hardware through a translation layer / software driver that I also wrote myself, which converts instructions like "I want to pulse a certain motor twice; just do it" or "I want to pulse a certain motor 4,000 times, with gradual speed acceleration and deceleration so as not to jilt the platform too much" into the low-level binary signals that need to be sent out through the hardware driver.  In a nutshell the basic problem of implementing tracking has already been solved on our current test equipment; thus the functionality that our new hardware driver is going to provide will be largely, if not completely, unneeded.  All I need is the ability to say "I want to pulse that motor once" and what I've written knows how to take care of everything else.

juniordevxd
Posts: 2
Joined: Thu Dec 29, 2011 2:47 am

### Re: A question about timing

Hi,

Just wanted to throw in a lil tidbit at the moment.

It seems as though the controller is alot more complex than it needs to be....

(I hate to point towards a non Rpi soln but this may work better for you)

Have you considered using a launchpad msp430........It has a 16bit timer which is acurate enough for your needs, is cheap (\$4.30) and uses less power than the Rpi.

Now the MSP430 is only a microcontroller (it does have a USB interface so it can be hooked up to a computer to capture information while running and for programming).

It would obviously depend on wether or not it could run your calculations fast enough but if it can then no paralell or serial interface needed it can directly drive your stepper controller.

Pairing this with the Rpi would be a better call than either individually as the Rpi can record data or provide an interface for controlling the mcu.

Caleb9849
Posts: 6
Joined: Tue Feb 21, 2012 5:56 pm

### Re: A question about timing

Wow, that actually looks a lot more like what we were looking for originally as a main operating platform for the controller software, before I discovered the Raspberry Pi and proposed it as a solution.  I see a 2-line text LCD there, is the programmer able to control that?  We've already ordered a *way* more expensive module for both user input and output, which includes a very similar LCD (although it is red-lit, to please astronomers) plus nice-looking navigational and accept/cancel buttons.  How the heck is this thing you point out so cheap?  Does it not have any capacity for accepting user input?  Sorry if I seem ignorant -- I am.  Despite being an experienced programmer, I'm pretty unfamiliar with microcontrollers/microcomputers.

VSid
Posts: 3
Joined: Tue Dec 27, 2011 9:27 am
Contact: Website

### Re: A question about timing

I actally got the launchpad about a month ago, just getting started on microcontrollers, but you can find more info about it here http://processors.wiki.ti.com/index.php ... -EXP430G2). It comes with 2 microcontrollers as well as a 32.768 kHz crystal for more accurate timing and its programmable both in C and assembly.

rurwin
Forum Moderator
Posts: 4257
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

### Re: A question about timing

Caleb9849 said:

I see a 2-line text LCD there, is the programmer able to control that?

Controlling those text LCDs only takes about six digital I/O.

rwaltman
Posts: 31
Joined: Mon Sep 05, 2011 3:16 pm

### Re: A question about timing

Caleb,

As already pointed out, the precision and stability of a garden variety crystal oscillator may not be enough for your needs, but the later is easy to improve.

The main factors affecting the (short term) frequency stability of an oscillator are [a] voltage supply, temperature and [c] (depending on the internal circuitry) output loading.

Make these three factors constant and you will get a very stable frequency source.

[a] and [c] are easy to deal with - There are many temperature compensated voltage regulators for [a], and a few inverter gates in series will take care of [c]. (Add a flip-flop to get a precise 50% duty cycle for almost no cost.)

For put the oscillator in a closed box and warm it up to a (constant) few degrees above the highest ambient temperature you are likely to encounter in normal use.  (45C?) - Use a small micro and PID loop controller.

Of course you will still have to compensate in software if your very stable 10.000 MHz frequency source turns out to be 10.002.
How to measure and correct for that deviation is left as an exercise for the reader.

With regards to you post on small boards with an LCD controller, check the following:

http://www.st.com/internet/eva.....250990.jsp

http://www.cutedigi.com/develo.....creen.html    (I saw it cheaper than that.)

--

Roberto Waltman