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

Re: A question about timing

Tue Feb 21, 2012 6:06 pm

Hi all...

I would like to use a Raspberry Pi for an astronomical project which requires very precise timing...it does *not* matter what "time of day" it is, but I've developed an application which needs to perform a series of computations and operations repetitively at a high rate which is currently 50 hz, and may increase.  It is very important that the software repeats these calculations and activities at *exactly* the rate I specify, no faster and no slower.  Thus I need to be able to measure time (not time of day, merely time elapsed since a reference/datum measurement) very accurately, to the degree of milliseconds and possibly even microseconds if the need arises.

This is pretty easy to do on a standard PC but I have looked around at other threads etc. and am having trouble understanding what would be required in a Raspberry Pi context.  I'm aware that the Pi possesses no "real time clock" out of the box, but I'm pretty amateur when it comes to low-level electronics, and can't discern whether a "real-time clock" is actually required for such timing...it seems that perhaps a "real-time clock" is only necessary if you want time-*keeping* over a long period of time (such as for outputting an accurate calendar).  But I'm unsure whether that's the case.  Can anyone tell me what modifications, if any, need to be made to the Raspberry Pi in order to accurately measure time passage on a short-term, no-calendar basis?

Thanks in advance!

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

Re: A question about timing

Tue Feb 21, 2012 6:18 pm

It depends on what you mean by very precise timing. Seconds, Milliseconds, Microseconds?

At the second level connecting it to the internet and using a time server may be good enough; for milliseconds a GPS can provide a pulse per second output that's accurate to the millisecond. For better than that it will be very specialised.

The asteroid occultation people are the ones to talk to.

Chris

timgiles
Posts: 101
Joined: Thu Jan 12, 2012 8:58 am

Re: A question about timing

Tue Feb 21, 2012 6:18 pm

Hi Caleb,

Gosh you have us other astronomers wonder what you are up to!! Any chance of spilling the beans!??

Anyway, the clock that the RPi comes with will have a certain specification. If that is accurate enough for your needs, then no, you dont need a RTC. However, you might find that the external RTC components people are looking to produce are more accurate.

Sorry if not a complete answer.

Regards and hope the nights are clear for you

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

Re: A question about timing

Tue Feb 21, 2012 7:02 pm

Thanks for the quick replies, guess this forum is pretty active

Timothy Giles said:


Gosh you have us other astronomers wonder what you are up to!! Any chance of spilling the beans!??


Absolutely didn't want to make too bulky a post to begin with....thought I'd start with the point and expand upon it only if desired.  My dad and I have been developing a new style of equatorial tracking platform, one which works at *any* latitude with a very high degree of precision, and does not need the user to change wedges, arcs, or anything like that....all you do is punch your latitude, in degrees, into the software, and then the software drives the platform around the proper arc.  My dad is a machinist by trade and has engineered the physical design, and I (being an avid programmer and mathematician) have written the software that controls/interfaces it (and provides some nice additional features as well, such as automatic polar alignment compensation: you just tell the software how far off-axis the machine seems to be, and it fixes it for you, with no physically moving the platform).  We've created a forum for advertising/discussing the project, if you're interested, where you can find a lot of information about the project and its history, and a few videos demonstrating the platform and the software.  I'd like to post a link to our site, but I've looked in the forum rules/stickies and I don't see anything specifying whether or not external links are okay?  :S

Timothy Giles said:

Anyway, the clock that the RPi comes with will have a certain specification. If that is accurate enough for your needs, then no, you dont need a RTC. However, you might find that the external RTC components people are looking to produce are more accurate.
Okay, I didn't realize the RPi was going to come with a clock at all.  Basically, if I can say "fetch me the number of elapsed milliseconds since X reference time" and get the answer with reasonable accuracy then it is likely to be fine on its own.  I take it that information (what kind of clock it will come equipped with) is not yet known?

Chris Rowland said:


It depends on what you mean by very precise timing. Seconds, Milliseconds, Microseconds?


Well, like I said, it's currently re-computing all it needs to at a rate of 50 hz, so technically all it needs right now is fiftieths of a second, but I don't believe there is any standard time resolution between seconds and milliseconds; correct me if I'm wrong.  However, this is a work in progress, and it's difficult to tell for sure how precise it will end up needing to be.  Milliseconds would *probably* be good enough, but it's just not easy to know.  I am very confident, however, that nothing finer than microseconds will ever be deemed necessary.

Chris Rowland said:


At the second level connecting it to the internet and using a time server may be good enough; for milliseconds a GPS can provide a pulse per second output that's accurate to the millisecond. For better than that it will be very specialised.


NTP is just not an acceptable solution in this context, unfortunately.  The time-checking needs to be very quick (many many times per second), and on top of that, the unit needs to work in very remote locations. 

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

Re: A question about timing

Tue Feb 21, 2012 7:06 pm

There are two aspects to the OP's question.

1.  The absolute accuracy.  That is if he wants things done at 50 Hz how close to 'standard atomic' time that does it need to be?  50.1 or 50.01 or 50.001 etc.  This really needs some reference or calibration to a known external time source or perhaps just knowledge that the frequency tolerance of some 'master' oscillator on the RP itself is good enough.

2.  Relative accuracy over time (no pun intended).  Really the jitter around the average time between the calculations.  If at a 50 Hz rate what variation is allowable on the nominal 20 millisecs?  This likely has some impact on the software design and interrupt latency variations, cache hits/mishits etc.  Can a non-RT kernel be good enough?

User avatar
liz
Raspberry Pi Foundation Employee & Forum Moderator
Raspberry Pi Foundation Employee & Forum Moderator
Posts: 5202
Joined: Thu Jul 28, 2011 7:22 pm
Contact: Website

Re: A question about timing

Tue Feb 21, 2012 7:08 pm

External links are fine. Go for it!
Director of Communications, Raspberry Pi

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

Re: A question about timing

Tue Feb 21, 2012 7:24 pm

Thanks Liz!

https://www.globaleqplatform.com/

There's our forum, for Timothy and any other interested astronomers.  Feel free to look around, or register and post if you have questions/suggestions

drgeoff said:


There are two aspects to the OP's question.

1.  The absolute accuracy.  That is if he wants things done at 50 Hz how close to 'standard atomic' time that does it need to be?  50.1 or 50.01 or 50.001 etc.  This really needs some reference or calibration to a known external time source or perhaps just knowledge that the frequency tolerance of some 'master' oscillator on the RP itself is good enough.


Appreciate the response very much but I'm not sure why you say that an "external" time source would be necessary (can you clarify, possibly?).  Like I said before, I don't care what time of day it is or what year it is or anything, I just want to be able to measure passage of time on the short-term.  What I'm envisioning is being able to constantly ask "How many milliseconds have gone by since 'x'?" and then judge, based on the answer, whether or not it's time yet for another cycle.


2.  Relative accuracy over time (no pun intended).  Really the jitter around the average time between the calculations.  If at a 50 Hz rate what variation is allowable on the nominal 20 millisecs?  This likely has some impact on the software design and interrupt latency variations, cache hits/mishits etc.  Can a non-RT kernel be good enough?


I don't care if there is a little bit of non-accumulating error that gets canceled out.  For example, a 15 ms cycle and then a 25 ms cycle later to make up for it.  That should be fine.  As far as RT vs. non-RT, so far all the testing has been done on a standard (non-RT kernel) Debian install on an old, low-power laptop, and it's been working perfectly.

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

Re: A question about timing

Tue Feb 21, 2012 7:45 pm

@caleb9849

I wrote my reply before seeing your reply.

My mention of absolute accuracy was to do with to what extent your notion of "one second" needs to agree with what everyone else thinks is one second.  That depends on what you are doing.  Not sure that you have explained that well enough and I'm even less sure I would understand it if you did. .  But from your reply above it sounds like you don't need your "clock" to have any absolute accuracy at all.  I mean that if you thought you were running at 50Hz but it was really 51Hz, that would not be a problem for you.

Your mention of anything between 15 and 25 millseconds being OK provided the long term average is 20 sounds quite achievable with the RP without needing to take any extra special precautions.  If you had said 20 milliseconds +/- 5 nanoseconds that might be a different story.

User avatar
Gert van Loo
Posts: 2486
Joined: Tue Aug 02, 2011 7:27 am
Contact: Website

Re: A question about timing

Tue Feb 21, 2012 8:21 pm

Every computer has a clock. The accuracy comes from a Crystal which has a precision in the order of 15-50ppm. (Parts Per Million). Internally this is boosted up to a higher frequency (e.g. the ARM runs of 700MHz) but that does not give you a higher precision. Every Linux computer has an periodic interrupt timer which interrupt your processor X times per second. But the processor may be busy and need a small time to repond to that interrupt. That gives you about the normal basic Linux precision of X.

You will get the highest precision if you set a separate timer to go off at exactly 50Hz. connect it to the ARM FIQ and run your program in the FIQ interrupt routine. This may upset the timing of other parts of Linux but you may not care about that. My rough estimate is that you can get the interrupt routine accurate to +/- 10 micro (10e-6) seconds. You must make sure that the timer clock stays the same as some clocks on the chip get automatic slowed down to save power.

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

Re: A question about timing

Tue Feb 21, 2012 8:22 pm

You can measure the time between two events with good accuracy. However you can not guarantee to schedule two events to take place with a defined delay with the same accuracy. If you try to you will tend to get a cumulative error.

There are two ways to work around this limitation. You can arrange that the events happen faster, say 5ms, and only execute the algorithm on those invocations that closest match the cumulative average time. But then you have less time to execute the algorithm and the jitter may have a bad effect on the accuracy of your control.

However it is generally possible to arrange your algorithm so that it calculates the required change since its last invocation, rather than assume a fixed interval. That will give you better and smoother control and fewer bugs at the expense of complicating your algorithm.

User avatar
mkopack
Posts: 242
Joined: Mon Nov 07, 2011 8:46 pm

Re: A question about timing

Tue Feb 21, 2012 8:31 pm

Right, so basically what rurwin is saying is that you can do something like this (in pseudocode:

while(1) {

currenttime = now();

timediff = lasttime-currenttime;

Do calculations based on timediff

lasttime=currenttime;

}

You adjust your calculations based on the actual elapsed time since you last calculated.

Phil Spiegel
Posts: 210
Joined: Tue Jan 17, 2012 8:17 am
Contact: Website

Re: A question about timing

Tue Feb 21, 2012 8:57 pm

Apart from internal timers and counters, what opportunity is there on the Pi board (or Gerb) to access video timing registers or even, if all else fails and hdmi is not in use, to slice the video sync pulses?....15,625Hz/50Hz

Without looking at the linked website, this sounds like an optical (or radio telescope?) implementation similar to vehicle/vessel-mounted tracking satellite dishes? A portable dish we have includes a gravitational field sensor, or similar as found in smart phones to determine elevation. A gps module could also be used to source the location data for calculation?

arm2
Posts: 253
Joined: Thu Dec 15, 2011 3:46 pm

Re: A question about timing

Tue Feb 21, 2012 9:34 pm

Gert said:


Every computer has a clock. The accuracy comes from a Crystal which has a precision in the order of 15-50ppm. (Parts Per Million). Internally this is boosted up to a higher frequency (e.g. the ARM runs of 700MHz) but that does not give you a higher precision. Every Linux computer has an periodic interrupt timer which interrupt your processor X times per second. But the processor may be busy and need a small time to repond to that interrupt. That gives you about the normal basic Linux precision of X.

You will get the highest precision if you set a separate timer to go off at exactly 50Hz. connect it to the ARM FIQ



I can't see any reference to ARM FIQ on the GPIO "6.2 Alternative Function Assignments" in the datasheet! Did I miss it. Lots of references to the registers/software for ARM_FIQ but no mention of a physical connection!

Johannes
Posts: 64
Joined: Sun Jul 31, 2011 8:05 pm

Re: A question about timing

Tue Feb 21, 2012 10:22 pm

Caleb9849 said:

drgeoff said:

There are two aspects to the OP's question.

1.  The absolute accuracy.  That is if he wants things done at 50 Hz how close to 'standard atomic' time that does it need to be?  50.1 or 50.01 or 50.001 etc.  This really needs some reference or calibration to a known external time source or perhaps just knowledge that the frequency tolerance of some 'master' oscillator on the RP itself is good enough.


Appreciate the response very much but I'm not sure why you say that an "external" time source would be necessary (can you clarify, possibly?).  Like I said before, I don't care what time of day it is or what year it is or anything, I just want to be able to measure passage of time on the short-term.


Allow me. The rest of your comment indicates that you don't need a high precision (i.e. you're not so much concerned with the jitter or spread between the exact time and each individual time value you get), but you don't want an accumulating error (i.e. the errors have to cancel each other out over a short time). The question is, how much clock drift can you accept? I.e. how much accumulated error can you tolerate?

A time keeping instrument that is very precise can still be very inaccurate if you leave it running for some time. Gert already mentioned that the principal source of timing inside a computer is a crystal which can be up to 50ppm slow or fast, depending on temperature. That's about 4 seconds per day, with no other negative influences on the accuracy. If you need better accuracy than that, you need a more accurate time source, for example a GPS receiver.


I don't care if there is a little bit of non-accumulating error that gets canceled out.  For example, a 15 ms cycle and then a 25 ms cycle later to make up for it.  That should be fine.  As far as RT vs. non-RT, so far all the testing has been done on a standard (non-RT kernel) Debian install on an old, low-power laptop, and it's been working perfectly.


In that case there should be no problem running it on a Raspberry Pi.

If you want to know more about the way the Linux kernel keeps time, read the fine documentation:

http://www.kernel.org/doc/man-.....ime.7.html

For anyone wondering about the difference between accuracy and precision:

http://en.wikipedia.org/wiki/A....._precision

Someone with access to an RPi may be able to inform us about the availability of high resolution timers by posting the output of

cat /proc/timer_list

Johannes
Posts: 64
Joined: Sun Jul 31, 2011 8:05 pm

Re: A question about timing

Tue Feb 21, 2012 10:38 pm

arm2 said:

I can't see any reference to ARM FIQ on the GPIO "6.2 Alternative Function Assignments" in the datasheet! Did I miss it. Lots of references to the registers/software for ARM_FIQ but no mention of a physical connection!
FIQ is not an I/O feature. FIQ is an interrupt line to the ARM core that isn't masked by an active IRQ. External interrupt lines are connected to an interrupt controller which triggers the IRQ or FIQ. You can program the interrupt controller to route a timer interrupt to the FIQ. This avoids waiting for the end of a running interrupt routine and thus creates a low latency interrupt.

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

Re: A question about timing

Tue Feb 21, 2012 11:24 pm

drgeoff said:


My mention of absolute accuracy was to do with to what extent your notion of "one second" needs to agree with what everyone else thinks is one second.  That depends on what you are doing.  Not sure that you have explained that well enough and I'm even less sure I would understand it if you did. .  But from your reply above it sounds like you don't need your "clock" to have any absolute accuracy at all.  I mean that if you thought you were running at 50Hz but it was really 51Hz, that would not be a problem for you.


Ah, well this needs to be pretty darn close.  I think 51 hz would probably be too much error, but 50.1 or 50.01 *might* be okay.  The idea of the tracking platform is that an astronomer sits his telescope atop a motor-driven platform, and the platform turns in such a way as to keep his telescope pointed at the same object as it moves through the sky.  Now, *if* all you care about is that the object stays in view, you can be pretty sloppy.  What we're crossing our fingers for is a product that is suitable for astrophotography, and this creates a big deal: when someone is taking a long exposure through a telescope, a tiny bit of error in tracking will cause a noticeable smear/blur of the photo.  Does this make sense?


Your mention of anything between 15 and 25 millseconds being OK provided the long term average is 20 sounds quite achievable with the RP without needing to take any extra special precautions.  If you had said 20 milliseconds +/- 5 nanoseconds that might be a different story.



Great, thanks.

mkopack said:


Right, so basically what rurwin is saying is that you can do something like this (in pseudocode:

while(1) {

currenttime = now();

timediff = lasttime-currenttime;

Do calculations based on timediff

lasttime=currenttime;

}

You adjust your calculations based on the actual elapsed time since you last calculated.



Excellent, that's pretty much what I want to do.

Phil Spiegel said:


Without looking at the linked website, this sounds like an optical (or radio telescope?) implementation similar to vehicle/vessel-mounted tracking satellite dishes? A portable dish we have includes a gravitational field sensor, or similar as found in smart phones to determine elevation. A gps module could also be used to source the location data for calculation?


No, nothing like that.  It's an equatorial tracking platform.  The basic concept is that the entire platform, and anything sitting on it (i.e. the telescope), rotates about the same axis  (orientation-wise) as the Earth and with the same angular velocity, but in the opposite direction.  Thus the Earth is "counter-rotated" and the platform can be thought of as being affixed to the sky, moving in (ideally) perfect tandem with the sky.  The only major variable is the user's latitude (the orientation of the Earth's axis of rotation with respect to where you're standing changes with your latitude)...so these platforms are generally engineered for a specific latitude, but that's the point of our new design: you punch in your latitude, and my software knows how to drive my dad's platform appropriately.

Johannes said:


Allow me. The rest of your comment indicates that you don't need a high precision (i.e. you're not so much concerned with the jitter or spread between the exact time and each individual time value you get), but you don't want an accumulating error (i.e. the errors have to cancel each other out over a short time). The question is, how much clock drift can you accept? I.e. how much accumulated error can you tolerate?



On a per-tracking-run basis, the thing only runs for a maximum of an hour and a half.  If time measurement drifts by even a full second or two during that length of time, I *think* that would be acceptable.  That would equate to 24-48 seconds per day, way over the 4-second-per-day figure you gave.  So it sounds like I'm in the clear.

Thanks again for the overwhelming amount of help!

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

Re: A question about timing

Wed Feb 22, 2012 12:20 am

Ok, so you do need your concept of "one second" to agree to a certain extent with the "standard" one second because you are trying to match the rotation of the earth.  (So that the camera maintains a fixed position relative to the constellations.)

You should be able to compute an accuracy ratio starting with the requirement that over the period of interest (eg 90 minutes) the drift between your clock and the earth's clock should correspond to less than, say, a tenth of a pixel.

I reckon that the pixel resolution you are working to and the angular field of view that corresponds to will appear in the calculation.  Once that accuracy figure has been calculated it can be compared with what the crystal in the RP is likely to achieve.

laszlo
Posts: 25
Joined: Thu Jan 26, 2012 6:03 pm

Re: A question about timing

Wed Feb 22, 2012 12:35 am

I messed around with something similar and actually got more interested in time keeping in the end.  In short the best thing to do would be to get a GPS which provides a PPS signal (pulse per second) or better and discipline the linux clock off of it, as has been mentioned already.

The linux system clock is not reliable for anything.  It has to be counting _something_ and on many machines there are no reliable clock sources.  The rate is simply not constant and this is why NTP is needed to keep the time from drifting off.  In some cases you will see the clock running at half or double rate on some combinations of hardware/software.  The resolution of the system clock is limited by the resolution of the clock source.  Depending on the platform and the hardware linux finds, it will choose a clock source which can be overridden with the clock=<source> command line option.  The common types you find on x86 PCs these days are pit, acpi, hpet and tsc.  HPET is supposed to be specifically for timing, as is the power management/ACPI timer but these both have low precision.  The best thing you can usually get is the TSC (RDTSC instruction) but this was not intended to be used for timing for multi processor and dynamically clocked systems.. the rate the TSC runs at varies constantly.  Some of the recent intel processors have a feature called constant TSC or invariant TSC.  If this feature is present, then the TSC is a good choice for the linux system clock, otherwise HPET.. the other options provide very poor resolution.

Still, the processor is cycling thermally, the power is not constant and clean, and so TSC is still not constant enough.. through the magic of cesium clocks on GPS sats and some fancy logic built into these GPS receivers, you can get a significantly more constant time source and hook it to a GPIO pin.  Linux even has support built in for this..

I don't know if the Raspberry Pi will have any type of 'constant' timer that is high precision.. so it may not be possible to do use it.  You can check the precision of the clock by running ntpd and querying like this: ntpdc -c kerninfo

I ended up using an Intel Atom based mini board for my project, since it had serial ports and a constant TSC to provide the higher level of precision I wanted.  I used this GPS which is known to provide a PPS signal accurate to within 1 microsecond of UTC.  It is also very sensitive and works in a window without a full sky view.

Garmin GPS 18x LVC - http://www.newegg.com/Product/.....6858998157

Here are some pictures of my crappy rigging job when I was testing:

http://eclipse.heliacal.net/~s.....min18xlvc/

And here's the rig that I ended up using for it:

http://eclipse.heliacal.net/~s.....ages/atom/

You can check the current clock source linux is using in /sys/devices/system/clocksource/clocksource0/current_clocksource

I have no idea what clock sources the RPi has but I wouldn't expect them to be constant enough for what you want to do.

The GPS is _almost_ as good as your own cesium clock, which, depending on your budget, may be even better:

HP/Agilent 5071A - http://www.testequipmentconnec.....ucts/30797

Even with the GPS or cesium standard disciplining the system clock you will see some variation from temperature changes throughout the day.  What you _really_ need to go with your atomic clock is what is called a 'temperature compensated crystal oscillator' =)

stormy1
Posts: 60
Joined: Fri Jan 06, 2012 3:44 am

Re: A question about timing

Wed Feb 22, 2012 5:34 am

What is done in very high end cnc drives is buffer the output.

Then use a precision clock to control the output of the buffer to the controller.

20 step buffer is not uncommon.

This means the timing of the calculations is non-critical, it just has to be fast enough to fill the buffer as needed.

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

Re: A question about timing

Wed Feb 22, 2012 7:35 am

50ppm would be good for a PC crystal, 150ppm is more likely, but even that would only be 12 seconds per day.

The only question I would have is whether you can keep the clocks running at a constant speed. One assumes you can, otherwise Linux could not keep time.

In the worst case, all you need to do is to have an oscillator or GPS signal attached to the GPIO. That's not difficult, and you could market it as the "high-precision" alternative.

But anything an old PC can do, the RaspPi should be able to do as well.

Johannes
Posts: 64
Joined: Sun Jul 31, 2011 8:05 pm

Re: A question about timing

Wed Feb 22, 2012 10:01 am

laszlo said:

The linux system clock is not reliable for anything.  It has to be counting _something_ and on many machines there are no reliable clock sources.
I don't know if the Raspberry Pi will have any type of 'constant' timer that is high precision.. so it may not be possible to do use it.
If I read the published kernel source correctly, the Raspberry Pi uses a free-running 32bit 1MHz counter to keep time. That should result in a clock which is as good as the quartz crystal allows. This means that if a standard PC can do the job, then a Raspberry Pi can too.

User avatar
Burngate
Posts: 6063
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: A question about timing

Wed Feb 22, 2012 11:23 am

Johannes said:


arm2 said:


I can't see any reference to ARM FIQ on the GPIO "6.2 Alternative Function Assignments" in the datasheet! Did I miss it. Lots of references to the registers/software for ARM_FIQ but no mention of a physical connection!


FIQ is not an I/O feature. FIQ is an interrupt line to the ARM core that isn't masked by an active IRQ. External interrupt lines are connected to an interrupt controller which triggers the IRQ or FIQ. You can program the interrupt controller to route a timer interrupt to the FIQ. This avoids waiting for the end of a running interrupt routine and thus creates a low latency interrupt.



OK, so FIQ comes from the interrupt controller. If I've got a gubbins outputing a clock edge on a piece of wire, where do I connect that wire (which GPIO pin) and how do I tell the R-Pi to route that GPIO to the interrupt controller, and how do I tell the interrupt controller to route it to the FIQ?

On a related note, some-one on another thread had looked at the Fedora kernel; while the reset vector is set up to point to code further up the memory map, the other vectors - IRQ, FIQ and SWI - seem to be uninitiallised, ie 0000. Do these get set up later in the boot, or are they just not used?

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

Re: A question about timing

Wed Feb 22, 2012 11:38 am

It was not the kernel he was looking at, it was the boot-loader.

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

Re: A question about timing

Wed Feb 22, 2012 11:58 am

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.

Typically people put the low level stepper control into a microcontroller - possible one for each axis - and use the higher level system - Windows or Linux - for the overall control, calibration and UI functions.  See EQMOD for an example, it provides a front end to a commercial system which is running the stepper motors from hardware.

The sidereal tracking rate is 15 arc seconds per second of time, so a 2 second error in the time will give an error of 30 arc seconds- about the diameter of the planet Jupiter. In reality errors of several times this an hour will be acceptable.

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.

Chris

dhanger
Posts: 1
Joined: Wed Feb 22, 2012 12:44 pm
Contact: Website

Re: A question about timing

Wed Feb 22, 2012 1:13 pm

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.

Typically people put the low level stepper control into a microcontroller - possible one for each axis - and use the higher level system - Windows or Linux - for the overall control, calibration and UI functions.  See EQMOD for an example, it provides a front end to a commercial system which is running the stepper motors from hardware.

The sidereal tracking rate is 15 arc seconds per second of time, so a 2 second error in the time will give an error of 30 arc seconds- about the diameter of the planet Jupiter. In reality errors of several times this an hour will be acceptable.

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.

Chris


Hi Chris-

This is Caleb's dad, the hardware designer of the tracking platform. Your post interested me enough to register and reply to. Your hardware description is a very close match to our setup, I don't know whether it's pertinent to Caleb's original question, but it may be. Yes, we are using 3 stepper motors with low level controllers (http://www.interinar.com/bsd-02lh.html) and a parallel interface (http://www.interinar.com/ppi-04.html) to control the three drivers. Since we want to use the Pi, we can't use the parallel interface anymore, so in the next revision we will be using a serial interface (http://store.qkits.com/moreinf.....fm/KTA-190). Bottom line is, and I don't claim to know what I'm talking about here, the computer itself is freed up from some of the burden. Maybe that makes a difference in the timing issue?

Off-topic, regarding the imaging, since we are using three motors for control, the compound motion we designed for creates a true equatorial motion suitable for imaging, no field rotation. Of course, there are more factors than that to be successful at imaging, but at least we have that part conquered. We've found that even at higher magnifications (220X) the accuracy of tracking is remarkably good, at least visually. Since we have no experience with imaging we are trying to setup a test with someone who is, so we can at least find out how close we are. My hope is that it's close enough to be able to incorporate auto-guiding to really nail it down, but that's a long term goal for now.

Dan

Return to “General discussion”