Return to the Cloudy Nights Telescope Reviews home pageAstronomics discounts for Cloudy Nights members
· Get a Cloudy Nights T-Shirt · Submit a Review / Article

Click here if you are having trouble logging into the forums

Privacy Policy | Please read our Terms of Service | Signup and Troubleshooting FAQ | Problems? PM a Red or a Green Gu… uh, User

Equipment Discussions >> Mounts

Pages: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | (show all)
Raginar
Postmaster
*****

Reged: 10/19/10

Loc: Rapid CIty, SD
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5806271 - 04/18/13 08:52 AM

Keep at it orly

Post Extras: Print Post   Remind Me!   Notify Moderator  
orlyandico
Postmaster
*****

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5806395 - 04/18/13 10:39 AM

Another business trip.. So next weekend I'll have another go using the RTC chip. Fingers crossed this will eliminate the clock drift.

Post Extras: Print Post   Remind Me!   Notify Moderator  
rpineau
member


Reged: 05/30/12

Loc: CA, USA
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5806498 - 04/18/13 12:07 PM

Yes you just need to enable the internal pull-up on the INT0 pin and wire the INT* output of the PCF8583 RTC to whatever pin is INT0 on the AVR you're using (and of course define the ISR in you code for INT0).
Regards, Rodolphe


Post Extras: Print Post   Remind Me!   Notify Moderator  
orlyandico
Postmaster
*****

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: rpineau]
      #5835199 - 05/01/13 08:49 PM

I was able to fix the timing problem without any added hardware (just got rid of delay() function call).

However I have found another source of long-term drift: the periodic error of the encoder itself over a full rotation.

Initially I thought of running the mount for 24 hours and capturing data, but then I realized that I could run the mount at a higher speed so it could complete one entire rotation in < 24 hours.

And the result:



this is not a full 360 degrees rotation, it's about 200 - 220 degrees. But the sinusoidal waveform is obvious. That's probably encoder swash.

Since the encoder doesn't have an indexer or absolute positioning, it's impossible to correct this long, very slow, but very large magnitude (about 500" p-p) periodic error.

One solution is not to keep track of the absolute position, but keep resetting the origin every 1 - 2 minutes. That way the long-term error doesn't accumulate.

Another solution is to keep track of speed, rather than position. I can't get this one working right though - but keeping track of position works (except for the long-term drift due to the encoder's gross PE).


Post Extras: Print Post   Remind Me!   Notify Moderator  
Mert
Post Laureate
*****

Reged: 08/31/05

Loc: Spain, Pamplona
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5835833 - 05/02/13 09:02 AM

Hi Orlando,

Ever since I use EQMOD, the PE-curve sometimes get "un-
synchronized" with the worm due to power failure or whatever.
Then, in order to maintain the PEC data and resync, it's
just using the flat surface on the worm-axis oriented to
a reference point and bingo.
IMHO using a little optocoupler, we could use that flat
surface or whatever other reference point, to "trigger"
the absolute start for the encoder, that might enable
PE for the encoder-swash I believe.
Just my 2
Very interesting data, looks more like it now!!!!


Post Extras: Print Post   Remind Me!   Notify Moderator  
orlyandico
Postmaster
*****

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: Mert]
      #5836050 - 05/02/13 11:13 AM

from Adaptive Correction of Periodic Errors Improves Telescope Performance (Toomas Erm, Stefan Sandrock)

Quote:

Likewise if the speed is low enough to make the frequency to be within the bandwidth of the control system the servo can follow the error and no position error can be seen, but the telescope will be moving with the error.




Doh!!!

Using an indexer is not an option.. because the Arduino can't command the mount to move to the index via the ST-4 interface (at least, not in our lifetime :P )

I did some exploring with Freemat (darn! where was this thing all my life, and me futzing around with Excel) and... it's not possible to recover the encoder gross PE from the corrected data.

So I'm stuck. How to get rid of the slow drift... actually the slow drift is not a problem because... it can be autoguided out!

but... my design goal was 20 minutes unguided. Currently that's not possible with the 1" / minute slow drift. Definitely though the encoder tames the fast periodic errors, so long guide exposures can be done (e.g. 5 - 10 second guide exposures).

but.... I know the TDM has solved this problem. Cannot... rest..


Post Extras: Print Post   Remind Me!   Notify Moderator  
tjugo
scholastic sledgehammer


Reged: 11/06/07

Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5836068 - 05/02/13 11:22 AM

Hi,

If slow drift is the problem what is preventing you to add a digital low pass filter in your code? You already know the frequency of the drift, so it is trivial to implement the low pass filter in software with the specified cut off frequency. Am I missing something?

Cheers,

Jose


Post Extras: Print Post   Remind Me!   Notify Moderator  
tjugo
scholastic sledgehammer


Reged: 11/06/07

Re: Encoder-based PE Correction on the cheap new [Re: tjugo]
      #5836074 - 05/02/13 11:23 AM

Sorry, I meant high pass filter!

Cheers,

Jose


Post Extras: Print Post   Remind Me!   Notify Moderator  
orlyandico
Postmaster
*****

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: tjugo]
      #5836106 - 05/02/13 11:38 AM

Jose,

Might work. Not sure how to do an LPF (to extract the error term for correction) except with an FFT.

I have seen that with a 512-point FFT covering 256 seconds (1/2 of the worm period) the encoder PE can't be extracted. I suspect at least 1-2 worm periods (so, 900+ seconds) would be needed to extract the encoder PE.

It's not enough to know the encoder PE frequency - you also need to know the phase, so you can subtract it.

I'm thinking I'll just cop out. The TDM is only rated for 5-10 minutes unguided. I think I can do that level by resetting the encoder origin every 5 minutes. This ensures that the encoder PE drift doesn't get too large.


Post Extras: Print Post   Remind Me!   Notify Moderator  
tjugo
scholastic sledgehammer


Reged: 11/06/07

Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5836125 - 05/02/13 11:54 AM

Orly,

You don't need to wait to record a whole cycle to apply the filtering. Depending on the frequency you want to filter out you have to wait a short number of samples to start filtering out the low frequencies.

Digital filters easy to implement in software, and you don't need FFT or complex math to do it.

Let me try to find some samples for you.

Cheers,

Jose


Post Extras: Print Post   Remind Me!   Notify Moderator  
orlyandico
Postmaster
*****

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: tjugo]
      #5837844 - 05/03/13 08:58 AM

OK so I did the "reset the origin every 120 seconds" and..... It sorta works. The AP600 can now maintain about 0.43px RMS (about 1.2" RMS) over a 20-minute period. This same mount can do 0.9" RMS when actively guided.

So the encoder solution is (almost) as good as auto-guiding. It would not be terribly useful on a midrange or high end mount. On the AP600 it's not that amazing but there's a definite improvement.

I thought of regulating the axis speed instead of its position (this avoids long-term drift effects). Used the Arduino PID control library and it seems to be working... but it clouded out and I can't verify that it works.


Post Extras: Print Post   Remind Me!   Notify Moderator  
pfile
Post Laureate


Reged: 06/14/09

Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5838908 - 05/03/13 06:55 PM

nice work! it's been a very long road but it seems it was worth it.

Post Extras: Print Post   Remind Me!   Notify Moderator  
orlyandico
Postmaster
*****

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: pfile]
      #5839540 - 05/04/13 04:24 AM



The plot is the position error (while correcting). When correcting based on encoder position the error doesn't increase - a false measurement because the mount is getting slaved to the encoder's errors.

Here there's drift because I'm regulating the RA rotation speed and not its position - this reflects the encoder's 24-hour period error, but the graph is straight, I think this shows that PID-controlling the speed successfully controls short-period errors while being insensitive to the long-period error of the encoder itself.

Hopefully a test against PHD on a star will prove the validity of this approach. I'm growing tired of this particular project. still.. considering it's cloudy all the time, the time I've sunk into this has prevented me from buying stuff on astromart, so overall I'm out ahead.


Post Extras: Print Post   Remind Me!   Notify Moderator  
Starhawk
Space Ranger
*****

Reged: 09/16/08

Loc: Tucson, Arizona
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5839931 - 05/04/13 11:28 AM

Hold on- it looks like this is likey mechanical mismatch between the encoder and the mount. Move the RA axis by hand and see if it wobbles.

Also, this is a 3" over 6 hour effect- I suggest this isn't the spot to sink a lot of time at the moment.

-Rich


Post Extras: Print Post   Remind Me!   Notify Moderator  
orlyandico
Postmaster
*****

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap *DELETED* new [Re: Starhawk]
      #5839969 - 05/04/13 11:50 AM

Post deleted by orlyandico

Post Extras: Print Post   Remind Me!   Notify Moderator  
orlyandico
Postmaster
*****

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5840263 - 05/04/13 03:02 PM

Rich, it is a mechanical mismatch. Either encoder swash or non concentricity. And its not that small - it's 500" over 24 hours.

The SiTech guys have a spreadsheet for calculating PE based on non concentricity. Even a 0.005" non orthogonality would result in over 1000" of PE with a 24 hour cycle.

Here are the results from doing PID control of the RA axis speed (rather than tracking the axis position):

This is the best case, the Arduino + encoder can beat autoguiding (normally I only manage 0.3px RMS with autoguiding). The worst case is less pretty, but I'm not sure if it's due to seeing effects or the encoder issue itself.



PECPrep output (including the bad spikes). Fundamental has been knocked down to about 4" p-p (from about 15").



Unfortunately the 2nd strongest harmonic is the 17.2-second one. Which is from the encoder! (it's the grating period, 86164 sec / 5000 slots)



The encoder PE adds about 1" to 2" of additional periodic error. The overall PE including all the ugliness is about 5" to 6". But the numbers from PECPrep are what they are - PECPrep reports my Mach1 has 3" p-p after PEM, but PEMPro reports 0.5" p-p. So the encoder might be performing better than these graphs lead me to believe.

I guess the real test will be trying to take long (e.g. 10 minute) unguided exposures, and see how that works out.


Post Extras: Print Post   Remind Me!   Notify Moderator  
Raginar
Postmaster
*****

Reged: 10/19/10

Loc: Rapid CIty, SD
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5840809 - 05/04/13 09:55 PM

The truth is in the pudding sometimes. Can't wait to see a picture.

Post Extras: Print Post   Remind Me!   Notify Moderator  
Starhawk
Space Ranger
*****

Reged: 09/16/08

Loc: Tucson, Arizona
Re: Encoder-based PE Correction on the cheap new [Re: Raginar]
      #5841116 - 05/05/13 03:21 AM

Egad,

What pain in the neck. The orthogonality itself seems to argue for special tapered fittings. I'm trying to think of ways to cause it to find its own center accurately. Come to think of it, it's a special procedure to get things centered on a milling machine.

OK, at the risk of annoying someone who is already frustrated, I'm going to back up a little bit and ask how one either (A) gets the encoder to magically give up what is needed or (B) get the data needed some other way? Note, I'm only going to post this if I feel like I made progress on the issue by the time I'm done thinking on what you're seeing.

So, I have an observation about Celestron drives: The system commands a set of drive movements which will result in perfect tracking on 1 rotation intervals, or 8 minutes in this case, if the drive repeats on one worm rotation. Now, thanks to the 8/3 weirdness, that means the real interval for seeing a "Perfect" reference come back from the drive itself is every 24 minutes. Or, in other words, if you look in on a CGEM drive every 24 minutes as your sampling point, you would conclude it was perfect. However, if the drive didn't have the 8/3 business, it would appear to meet perfection every 8 minutes (and those wacky NexStarSE mounts with the triangle wave tracking actually do this). So, the drive will come close to accurate every 8 minutes with the 8/3 error overlaid, and will be correct every 3 rotations no matter what, at which point any cumulative corrections must total out to zero, even if there is encoder eccentricity.

So, the corrections have:

(1) a set which will repeat every revolution of the worm.

(2) a set which has repeated 8 times for every worm 3 revolutions.

So, is it possible to ONLY look for frequencies matching those behaviors? One frequency is repeating 8 times in 24 minutes, or every 180 seconds, with an overlay of the worm repeating every 8 minutes.

So, if the system can filter based on these being the longest allowable periods, then that might be a way to cause it to run based on the possible drive errors, since the error in the timing for the 8/3 error is actually correct every 3 minutes, any 3 minute interval is long enough to see the entire performance of the upper drive reduction.

Now, on Milby's point about looking for a reference on the shaft, there is nothing to say the system couldn't look for the shaft reference with multiple detectors, so it would have to be visible during alignment.

Anyway, that's what I've got for now. I'm kind of swimming thinking about the overlaid functions. I feel like there should be some sort of maximum slope theorem of something to allow the system to be restricted to these inputs. Ah- I think I have it- periodically reset the definition of "Zero" on the encoder. Actually, that would be every 3 minutes. Could it be that simple?

-Rich

Edited by Starhawk (05/05/13 03:25 AM)


Post Extras: Print Post   Remind Me!   Notify Moderator  
Starhawk
Space Ranger
*****

Reged: 09/16/08

Loc: Tucson, Arizona
Re: Encoder-based PE Correction on the cheap new [Re: Starhawk]
      #5841120 - 05/05/13 03:29 AM

One more thought, actually, the re-zeroing of the encoder should be much faster. This isn't PEC- all you need to know is if you are fast or slow at a single moment. Pick the drive update frequency and a nyquist criterion for measuring it, then just keep a running score.

-Rich


Post Extras: Print Post   Remind Me!   Notify Moderator  
orlyandico
Postmaster
*****

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: Starhawk]
      #5841131 - 05/05/13 04:06 AM

Rich,

Ah- I think I have it- periodically reset the definition of "Zero" on the encoder. Actually, that would be every 3 minutes. Could it be that simple?

I have done that - see my post 5837844 above.

Reason there's no supporting data is because the performance wasn't great. I was actually resetting the zero every 120 seconds.

If you check, 500" over 24 hours is 0.35" per minute. So resetting every 2-3 minutes should be enough. But you will still get drift (trust me, it's very obvious on the PHD graph).

Controlling the speed is actually just another way of doing the reset - because

speed = (new_tick - old_tick) / (new_time - old_time)

So long as "old_tick" and "old_time" aren't too far behind new_tick and new_time, you won't see any encoder drift.

I tried using old_time and new_time being exactly 17.233 seconds apart (so that you are reading ticks from adjacent encoder slots, and thus interpolation errors between slots would cancel out) but the problem with such a long (17.233 second) measuring interval is, the system responds very slowly to input.

Just think.. applying a 500ms guide pulse will not do very much to change the average speed taken over a 17.233-second period.

The result was my PID control algorithm slowly built up a bigger and bigger oscillation.

The current algorithm uses the instantaneous velocity (i.e. old_tick and new_tick are only 1 sampling interval apart which is 0.5 seconds). I think this is too low, because encoder jitter would screw up the instantaneous velocity.

But the algorithm seems to maintain an average velocity of 15.04" / second quite well! the graph above is for this.

Maybe I will use a 4-second running average or something to smooth out the encoder jitter.

Frankly... I think this is an optimization exercise at this point. I'm sure even with the existing algorithm one can do 5-minute unguided with a CGEM at modest pixel scales (e.g. 2"/pixel). An unassisted CGEM cannot hope to do that.

One other use case - some people need 10-second guide exposures because they're using OAG or narrowband filters. A stock CGEM cannot be used with 10-second guide exposures due to the PE. As it is, this box can turn a CGEM into something usable for these use cases.

I'd call this a qualified success.


Post Extras: Print Post   Remind Me!   Notify Moderator  
Pages: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | (show all)


Extra information
34 registered and 40 anonymous users are browsing this forum.

Moderator:  Dave M, richard7, bilgebay 

Print Thread

Forum Permissions
      You cannot start new topics
      You cannot reply to topics
      HTML is disabled
      UBBCode is enabled


Thread views: 14614

Jump to

CN Forums Home


Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics