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)
orlyandico
Post Laureate
*****

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: Armando]
      #5768111 - 03/31/13 05:48 AM

Am already doing 16x oversampling for each channel (take 16 readings and average). If my sampling interval decreases due to the necessity of needing more time to accumulate errors, I can increase the oversampling some more.

I always prefer doing things in software than hardware

Besides even with the transient noise I'm getting some improvement. So I think the approach is valid and just needs some more iteration.


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


Reged: 12/26/05

Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5768126 - 03/31/13 06:07 AM

Hi Orlando,

I already gave a look at your code and suggested to discard some samples when required.
But I think it's worth adding 4 resistors and 4 caps.


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

Reged: 10/19/10

Loc: Rapid CIty, SD
Re: Encoder-based PE Correction on the cheap new [Re: mattflastro]
      #5768380 - 03/31/13 09:51 AM

Matt,

I love hearing someone talk about Kalman filters . It's what keeps our INSs running!

Chris


Post Extras: Print Post   Remind Me!   Notify Moderator  
mattflastro
Vendor - Astrovideo Systems


Reged: 07/31/09

Loc: Brevard County , FL
Re: Encoder-based PE Correction on the cheap new [Re: Armando]
      #5768959 - 03/31/13 02:49 PM

Quote:

I think that subsequent electronics should include terminating resistor.
The use of RC filters (one for each ADC input) should be of help to reduce noise and also because of the need of constant voltage on the - input during the ADC sampling.



Signal conditioning IS a requirement for such a high level of accuracy as this project is trying to achieve.
I would have thought a low pass anti aliasing together with noise filter were already in place.
Proper bypassing of supply, no ground loops, no mixing analog sensor and AD ground with the digital ground, bypassing of voltage reference.
Also some software things:
- oversampling x16 gives a 4 fold signal to noise improvement which cleans up 2 bits of the AD conversion . If you had 4 bit buried in noise, after using x16 oversampling, you will have only 2 bits under the noise floor.I am a little puzzled by the small oversampling ratio. You need to sample the motion with let's say 0.1 arcsec period. That's 150 samples per (time) second . Your AD has a sampling rate of 100ksps max. You are oversampling x16, that means you're running at a 2.5ksps , which is very low . You could get a higher sampling rate and further improve the accuracy by 2 more bits.

- the offset error can be easily calibrated without complex software.
- for each channel you'd have to keep track of the maximum and minimum values read from the AD, over a period of time that's longer than the sin and cos period . This would give the peak to peak value .
- max-min=pk to pk. Do this for the sin and the cos.
- calculate pk to pk for sin and divide by pk to pk for cos .
Multiply the cos channel with this value in order to bring it to the same scale as the sin channel. This takes care of the ellipse and turns it back into a circle.

- (max +min)/2=center value for each channel.
- calculate center sin -center cos =offset. Calculate this value to take care of the offsets.
Then every time you need to calculate the arctan or arccot , first normalize the cos by adding the offset (brings cos to the same level as the sin) and multiplying the result with the value you calculated and stored above (brings the cos to the same "gain" as the sin).
This calibration should be ongoing, because it's not hard to calculate and store these max and mix variables for sin and cos.

You may also consider placing an origin sensor on the shaft together with your main sin/cos encoder . Your system actually has 2 sources of periodic error, one is in the drive mechanism, and the other is in your feedback loop being the error of your gazzilion ticks interpolated encoder. You need to treat the encoder error the same way you would treat any periodic error, by doing PEC , so you need an origin sensor on the encoder. But once you calibrated the PEC of your encoder, the beauty of it is that it's much smoother and more stable than the worm drive periodic error. So in essence, if you do the filtering, offset removal, value normalization and encoder PEC, you'll be able to achieve the goal.


Post Extras: Print Post   Remind Me!   Notify Moderator  
mattflastro
Vendor - Astrovideo Systems


Reged: 07/31/09

Loc: Brevard County , FL
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5768973 - 03/31/13 02:52 PM

Quote:

Not sure Armando. My understanding of the data sheet is that the encoder has a source impedance of 120 ohms...



Given that the signals are slow changing there's no need for impedance matching . But there's a need for low pass filtering because you don't want wideband noise to be picked up, aliased and downconverted by the AD sampling .


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

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: mattflastro]
      #5769041 - 03/31/13 03:19 PM

Matt, taking 32 readings (16x A and B) is already taking about 9-10ms. So that's only 3.2 ksps. The reason being.. I am bit-banging the SPI protocol instead of using the built-in SPI hardware.

I did some more measuring and it seems the ceramic resonator on the Arduino Uno is off (86482 seconds/day effective, when it should be 86400). That's a tolerance of 1000ppm, and over one worm period (479 seconds) it causes a deviation of 7". This is significant.

Also I don't think I'm reading the encoder properly. Or there are aliasing artifacts. I can't verify my readings because I don't have a super-precise rotational source, and the polar bore on the Mach1 doesn't rotate (I could have used it as a reference).


Post Extras: Print Post   Remind Me!   Notify Moderator  
mattflastro
Vendor - Astrovideo Systems


Reged: 07/31/09

Loc: Brevard County , FL
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5769371 - 03/31/13 05:56 PM

Quote:

Matt, taking 32 readings (16x A and B) is already taking about 9-10ms. So that's only 3.2 ksps. The reason being.. I am bit-banging the SPI protocol instead of using the built-in SPI hardware.

I did some more measuring and it seems the ceramic resonator on the Arduino Uno is off (86482 seconds/day effective, when it should be 86400). That's a tolerance of 1000ppm, and over one worm period (479 seconds) it causes a deviation of 7". This is significant.

Also I don't think I'm reading the encoder properly. Or there are aliasing artifacts. I can't verify my readings because I don't have a super-precise rotational source, and the polar bore on the Mach1 doesn't rotate (I could have used it as a reference).



So now's the time to write the real software and develop the real hardware, where you have real signal conditioning and real hardware SPI , higher sample rate, a $5 TCXO , and all sorts of other goodies that will actually make all the difference. What you did up to this point was great because it shows the potential. From now on it depends if you want to turn this into a finished product or it was done just to satisfy the desire to tinker.


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

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: mattflastro]
      #5770479 - 04/01/13 10:52 AM

Progress has come almost to a standstill.

I did manage to convert the ADC routine to use hardware SPI, which means I can now get 32ksps @ 2MHz SPI clock. This lets me do 256X oversampling. I think it's overkill though.

However.. with regards to the signal conditioning, etc. Check this out:



Top graph is a screenshot from PEMPro (I could not import the PEMPro text data easily) and bottom is an Excel graph of the data from the encoder. This is with my super-decimation algorithm (which does 16X oversampling and throws away the rightmost 5 bits).

The interpolation algorithm is measuring the PE accurately, it wasn't just my imagination

So even with the complete lack of signal conditioning and the 32X decimation and 16X oversampling, the encoder is still returning accurate (ish) data.

Of course the absolute terms aren't exactly the same, as the encoder isn't aware of RA drift due to imprecise polar alignment, but PEMPro is.

I also tried capturing encoder data while PHD was actively guiding the mount. This resulted in a peak-to-peak error (according to the encoder) of 1.5" and an RMS of 0.8". The RMS figure is about 1/2 of what PHD was reporting though..


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

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5770496 - 04/01/13 10:59 AM

Also, Matt - I understand about the encoder having an induced PE due to the interpolation - and the Gurley has this, so SiTech uses the motor encoder to correct for it.

But I am not sure how i can measure the PE of the encoder itself, given that I don't have an air table and super-precision master encoder to provide the reference.

I would assume though that the periodic error in the encoder is sub-17 second in period (it would only happen when interpolating between grating slits). This encoder actually has an index channel that I'm currently not using - because the voltage on it doesn't look good (slowly varying).

I will put a couple of comparators on A and B though, so I can get square-wave quadrature signals for 0, pi/2, pi, and 3pi/2. These can (probably) serve as indexing marks for the periodic error correction.


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]
      #5770530 - 04/01/13 11:20 AM

IMHO Orlando, the PE of the encoder would be insignificant
over 1 worm period.
With this I try to express that for normal imaging purposes
that drift would not affect soo much.
Myself I'm using an EQ6 with EQMOD and sometimes I get drift
when using PEC, other times that drift isn't there!!

Inside the Microcode of the Arduino, do you compare the
ticks read out with the theoretical number of ticks that
should be read out when the mount would be perfect?
( I didn't have time to dig into it and see what's going
on and I'm no Arduino programmer!).

All in all I believe you are very close to your goal now!

Regards and


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

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: Mert]
      #5771646 - 04/01/13 08:26 PM

Hi Mert, yes I do keep track of theoretical ticks vs measured. And the difference is the error (this is what is graphed above).

Measuring PE and correcting it are different. I used to believe "if you can measure it, you can correct it." The problem is, measuring PE is much, much easier - because PE is large.

But.. if we are correcting the PE actively, at any given time the error is small. So it's harder to measure. And if there are cyclical effects in the interpolator, they will be insignificant compared to the raw PE, but will be very significant if the PE is being corrected.

I suppose this explains the +/- 4" cycle I was seeing when actively correcting... I don't have a secondary source of ticks (like the SiTech motor encoder) but I'll try to use the 4 quadrature signals as sanity checks at 0* 90* 180* and 270* - a long way from the 64-slot SiTech solution..


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

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5771715 - 04/01/13 09:19 PM

This Avago white paper has a very good discussion of interpolation, the Lissajous circle, etc.

http://www.avagotech.com/docs/AV02-0865EN

and this article talks about jump and interpolation errors - http://www.nanowave.com/jumperror.pdf

Quote:

The popular Sin/Cos interpolation method commonly resolves the scale pitch into as many as 2^11 parts, while the SPPE method has been shown to resolve the scale pitch accurately into 2^19 parts.




and...

Quote:

Interpolation Error is cyclic, with the period being the grating pitch or a harmonic.





On the other hand this article says that SDE (sub-divisional error) cannot be mapped, but averaging works in some applications - http://resources.renishaw.com/en/download/white-paper-the-accuracy-of-angle-e...

Quote:

Using a Renishaw readhead for illustrative purposes, the scale and readhead index grating produce optical fringes which move laterally across the readhead photo-detector with movement of the scale. These fringes are sinusoidal in intensity and are decoded by the readhead into 2 sinusoidal voltages 90° out of phase to each other. If these two voltages are plotted against each other on an oscilloscope, a circular Lissajous is generated which rotates once per scale pitch of movement. If this Lissajous is perfectly circular and centred on the origin, rotates at a velocity truly uniform to scale motion and the means of interpolation has truly uniform angular discrimination, then the readhead interpolation will be perfect; if not, SDE will occur...

Because of its high frequency, mapping does little to eliminate the effects of SDE, but averaging over small distances can be effective for certain applications.




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


Reged: 05/14/12

Re: Encoder-based PE Correction on the cheap new [Re: freestar8n]
      #5771930 - 04/01/13 11:05 PM

Quote:

Hi orlyandico-

This is an interesting project and I see you are making good progress on it. I am curious to see what kind of results you ultimately get in unguided images - but if you are aiming for better *guided* images then I'm not sure there will be a big difference.

In this thread people talked about what is needed to remove a frequency that is not commensurate with the fundamental period - and that can be done easily with software if you are guiding. The ability to lock in to a specified frequency and correct for it preemptively is something I implemented in MetaGuide many years ago, and I'm somewhat surprised no one else has done it.

The reason I don't promote or recommend such an approach is that I find such terms can be removed just by tight guiding and low latency corrections with an accurate centroid - particularly with OAG.

So although you may be reducing the measured PE with this device - if you are aiming for smaller fwhm, then the real goal is to get very small fwhm stars in the end.

Anyway - I'll be interested in results you get - particularly with regard to the final fwhm you achieve in guided or unguided shots.

Frank



Frank, I'm just a beginner but once you slew to a new location wouldn't software have to gather enough samples to figure out the phase and frequency before corrections could be made? It seems Orly's hardware approach would provide instant corrections.

However in Orly's approach I wonder if there may be some unexpected issues. For instance I learned from a couple forums that telescopes don't always track the stars perfectly. So, I wonder if the autoguider, which is trying to center a guide star, is going to fight his encoder setup, which is trying to create perfect tracking?


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

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: KietTran]
      #5772021 - 04/02/13 12:23 AM

Kiet, most imagers would only slew to 1 target per session, so the limitation you point out in Frank's approach is not really an issue.

Also you are correct in that the encoder box can't compensate for varying sidereal rate in different parts of the sky, so getting the AG and encoder not to fight each other is another challenge.

Finally - unlike a guide system - the encoder can "instantly" measure periodic error and is immune to seeing. But.. It cannot correct instantly due to the imperfect drive mechanism that doesn't respond either instantly or linearly to control input.


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

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5772127 - 04/02/13 03:23 AM

This looks like a very interesting approach:

"Probabilistic Learning Technique for Improved Accuracy of Sinusoidal Encoders," Kavanagh, R. C. IEEE TRANSACTIONS ON INDUSTRIAL ELECTRONICS, VOL. 48, NO. 3, JUNE 2001

Again, had to pay to get access

But it looks pretty easy to do and automagically compensates for non-linearities in the computed output (e.g. differing Sin and Cos amplitude, offsets, phase angle errors, rounding errors in the Arduino AVR arctangent library, ADC jitter, etc. etc.)


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

Reged: 10/12/07

Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5772137 - 04/02/13 03:42 AM

My points are irrelevant once Orly made it clear he is aiming for optimal unguided performance. As long as the goal is unguided then there is a clear benefit in reducing the amplitude of the overall PE curve by any means, and hardware encoders have advantages. I'm interested to see how well it can do while keeping the cost down - so I find this work interesting. Even if the PE can only be kept below 5" or so, it has application for things like planetary video where PE can cause the planet to move out of the field. Anything that beats what can be achieved with PEC is interesting in that regard.

But for autoguiding, Orly's math on how big the error is in each guide exposure is telling - because the long period terms produce little error, and need little correction, after each guide exposure. This points to the faster gearbox terms as most problematic for autoguiding - and those are the ones that can't be reduced by PEC.

But the fact that they tend to be fast is a bonus for methods such as MetaGuide's that lock onto the phase and amplitude - since a 2 minute term can have 3 cycles appear in 6 minutes and get a good estimate of the phase and amplitude quickly. Over time the measurement accuracy improves and the preemptive corrections become more accurate. There is no Fourier Transform involved - so there is no need for a ton of cycles for analysis, but in MG's implementation you do need to enter the frequency you seek - which for things like the 8/3 term are usually known.

Meade used an approach of looking at 3 full periods as a single period and correcting for that - and that would involve a very long overall period to correct. But in the MG implementation, the fundamental correction can be handled by PEC (or not) and the dominant non-integer term can be corrected by MetaGuiding. But as I say - in my own work I just guide tightly with low latency video and an accurate centroid, with corrections every second or so. I originally intended to add handling for other frequency terms and even discover them during guiding - but my goal was always small, round stars - and I found I could achieve that just by tight guiding.

Frank


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

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: freestar8n]
      #5772158 - 04/02/13 04:41 AM

Hi Frank,

What I've seen from the CGEM is that there are small, very fast terms. And by very fast I mean with <5 second period. That must be some lousy gearbox... I think even the encoder can't correct them fast enough (but it can detect them...)


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

Reged: 10/12/07

Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5772171 - 04/02/13 05:09 AM

Hi-

Yes, I can believe there are very fast terms in there - and even if the amplitude of the terms is small, the short period would produce a high rate of change - and that would dominate the guide corrections. Furthermore, if you use a long guide exposure, you would never see it even though it would be happening in the stars in the image.

On the other hand - unless your guided images in fairly short 30s exposures show clear oblong appearance in RA, I doubt that it is the limiting problem to good exposures. If you use a small guidescope it may be blind to errors on this scale and the stars end up equally blurred in RA and dec. So fixing this term might have little benefit.

I always want to see the actual stars in the image to determine what is limiting how small they are - and where effort should be directed. In your case, for unguided imaging it sounds like you have a ways to go before the 5s term becomes a limiting factor.

For Metaguiding on a 5s term it is still within reach, if you use 0.5s exposures and corrections - you would get 10 samples in a period. I was mainly focused on gearbox terms faster than about 20 seconds - which people tend to ignore completely because they are "small."

Frank


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

Reged: 08/10/09

Loc: Singapore
Re: Encoder-based PE Correction on the cheap new [Re: freestar8n]
      #5772196 - 04/02/13 06:18 AM

Frank, I knew those small terms were there due to the spiky guiding graph of the CGEM. But I never actually saw them till I started out on this encoder exercise..

Regardless, seeing the error and correcting it are two very different things. I noticed on my encoder logs that the encoder box would command a correction, and it would not be obeyed. So it would command another correction on the next sampling interval, etc. etc. I thought this was a bug on my encoder algorithm until I noticed PHD doing the same thing.

So at the end of the day mechanical hysteresis is going to limit the value of any high-speed correction mechanism.


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

Reged: 10/12/07

Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5772212 - 04/02/13 06:40 AM

Well - I recommend taking guide logs with MetaGuide, using a well-focused, bright star at long focal length just above the equator. It will record an accurate centroid at 0.5s intervals, each with a good timestamp - and things like a 5s term should show well, though it helps to have good seeing. If you take such a log I would be happy to help analyze it. Please contact me by PM if you want to follow up - so you use a recent beta version of MG. Most any video camera will work ok with a bright star at long focal length, but best is a good digital planetary monochrome camera.

It's fine if you don't want to do this - but my main point is that MG is specifically targeted at such fast terms - and you should be able to see them in a log if they are there. You may also see them visually just with an eyepiece and a reticle.

Small corrections may not get acted upon, but if you do have a term that has a high rate on the 5-20 second time scale, then there should be corrections in there that are not small. And if a correction is "missed" in one guide period, the error will still be there - and will add to the next one if it is in the same direction. That's with autoguiding on a star anyway - not sure how that works with your system.

I have found cge and cge-pro to be very responsive in RA. Dec is a different matter and has its own challenges - but I find that although dec. errors are harder to chase, they tend to be slower - so I just chase after them constantly in both directions.

Frank


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
2 registered and 27 anonymous users are browsing this forum.

Moderator:  Dave M, richard7, bilgebay, iceblaze 

Print Thread

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


Thread views: 13769

Jump to

CN Forums Home


Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics