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)
petemumbower
Carpal Tunnel


Reged: 07/12/09

Loc: West Michigan
Re: Encoder-based PE Correction on the cheap new [Re: Raginar]
      #5764069 - 03/29/13 09:52 AM

Great work so far Orly! This is perfect timing too: I just got another Arduino UNO board for my birthday, have a CGEM, and been waiting for the Celestron fix. But I think your project here is a much better solution than I seen over on the Celestron Beta forum.

So now I am wondering the best route for acquiring a plate and plug to attached the encoder too. Sure wish I still worked at a machine shop!

Do you have a current list of the "parts"?

Keep up the good work, I will be for sure implementing this ASAP.


Post Extras: Print Post   Remind Me!   Notify Moderator  
galaxy_jason
Vendor


Reged: 05/22/07

Loc: Texas
Re: Encoder-based PE Correction on the cheap new [Re: petemumbower]
      #5764234 - 03/29/13 11:02 AM

Pretty cool!
I love the Arduino.


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: petemumbower]
      #5764249 - 03/29/13 11:07 AM

Yes I do have a list. As-is, the system is not very robust to massive changes in direction (i.e. if there is a GoTo slew).

What it does now is, if it sees a huge change in angle, it gives up and recalibrates. I had this idea to add gross quadrature decoding (using the TLC3702 comparator). But it works fine now without the gross decoding.

One ugly hack that can be done now is, reset the Arduino after each GoTo slew. It will then wait for 5 seconds for everything to settle, before trying to correct.

Parts list..

1) Arduino Uno
2) MCP3304 ADC ($4)
3) LM385 voltage reference ($1) - this isn't really needed, even with the 5V reference the ADC was getting enough counts that interpolation works. But with the 1.24V reference, I get full counts in the +/- 2500 range instead of +/- 500. In theory that would allow finer interpolation

4) ACPL 847 opto-coupler

and of course the big ticket item is the encoder...

I want to make the schematic pretty before posting it here, but the code link is the current working prototype (albeit with 0.5 second correction interval - it's easy to find the #define to change that)

As for the plug... Josh Balsam machined it for me (jbalsam on this forum). The thread of the CGEM polar scope shaft is M28 x 1mm. My existing plug is 60mm long. But you'd need a different one for different encoders. Note that the Heidenhain ERN-480-5000 has a 12mm blind shaft.


Post Extras: Print Post   Remind Me!   Notify Moderator  
petemumbower
Carpal Tunnel


Reged: 07/12/09

Loc: West Michigan
Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5764308 - 03/29/13 11:23 AM

Are you currently using the ERN-480-5000? Thought I read you had the Baumer with 1" hole. Maybe I missed something later in the thread. I do notice how little there is out on the net about this encoder and ordering it in general. I will contact the Heidenhain here too to see. But I agree that the more everyone uses the same encoder/hardware, the better the project. Removes many of the variables when other encoders come into play.

Did I read earlier that you were going to work on allowing autoguider inputs into this system? I do image at longer focal lengths and will need to autoguide still.

Correct me if I am wrong, but currently after a slew the Arduino has to be reset. Does that mean powered down/up?

Lastly, how are you getting the data points from the encoder? Is there an external app you are getting a dump from the Arduino? I do not remember if the program to edit and upload code had a terminal console to get this info.


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: Raginar]
      #5764415 - 03/29/13 11:46 AM

Current Schematic Diagram:



Component Placement on Breadboard:



Other end of 6P6C RJ12 Cable:



Basically the optocoupler and RJ12 cable "close the loop" and allow the Arduino to do something about the periodic error it is seeing.


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]
      #5764434 - 03/29/13 11:50 AM

The Arduino just outputs all its intermediate data to the serial port.

I am using "putty" to capture the serial port output and dump it to a file. But the Arduino works fine without a PC.

To reset the Arduino - press the reset button. I said it may be necessary to reset the Arduino after a slew; but the code right now tries to do the right thing. For example if you whack the mount and there is a large excursion, it will not try to correct that, but will settle down on the new value and try to correct around that.

The thing is, you can't have a correction pulse that's longer than the sampling interval, so if there is a truly huge error, it will take many, many cycles to correct, which will oblongate the stars anyway.

So my philosophy is, try to correct small errors, but if there's a very big one, don't try to correct it. This behavior is easily changed in the code (look for the calibrate variable). The definition of a "big" error is if it takes more than 10,000 ms (10 seconds) to correct. Hard-coded.

Right now it does not handle autoguider input at all. I need a 6P6C RJ-12 port that the external AG (e.g. GPUSB) can plug into. Once I have that it will be trivial to add autoguider support in the code.

And yes, I'm using the Baumer. But I found out those cost $700 new. So not a good idea to follow my example.


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]
      #5766073 - 03/30/13 02:30 AM

After some more thought, I realized that the Arduino Uno doesn't have enough pins to implement the remaining functionality.

A few more digital input pins are needed to:

1) read the switch to determine EQ North / EQ South operation

2) read the switch for sidereal vs king rate tracking

3) read the switch to reverse RA guiding (in case of an ST-4 port that is wired in reverse)

4) read the Encoder A and Encoder B digital inputs (via comparator) for fast (hardware) gross movement detection

There are probably more features/requirements that I haven't thought of.

So I should move the design to an ATMega2560.

The problem is both the UNO and Mega use ceramic resonators for their clock, which only has a 100ppm resolution. It is a complete pain to replace the resonator with a real crystal (requires modding the board).

The ceramic resonator @ 100ppm would drift by about 130" in a sidereal day, or about 2" in 20 minutes.

A normal crystal oscillator @ 20ppm would drift by 1" in 60 minutes.

A TCXO @ 2.5ppm would drift by 1" in 7 hours, plenty accurate enough (iOptron makes much of the fact that the iEQ45 with Renishaw encoder has a TCXO).

The ultimate in timing - short of an atomic clock! - is an oven-controlled crystal oscillator (1ppm) but those cost $250 just for the crystal.

PICMX-based Max32 boards have a TCXO. So I will probably move the design to this board, which costs about $80 - $90 (compared to $50 for a MEGA and $30 for an UNO), since the price needs to be paid for the extra pins anyway.

The PICMX also is much more powerful (80MHz, 512K RAM, has real floating-point math) and can run things like a touchscreen, color TFT LCD.....


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]
      #5766124 - 03/30/13 03:58 AM

This is a great idea to experiment and you deserve a lot of credit for starting this project.
Just a word of caution , there are some internal error sources that are inherent in such a design.
Some that could be introduced by the encoder itself due to its mechanical mounting .
Also due to electronics . The encoder sine and cosine outputs have some deviations in amplitude, phase and shape froma perfect sin/cos.
No encoder has infinite accuracy and if you want 20 mil cpr the encoder needs to be specified for that. Not just any sine/cosine analog encoder has its outputs accurate enough for this level of accuracy. No matter how much you interpolate, you are limited by the encoder sine/cosine hardware accuracy .
Then you're using a fast SAR A/D , which has its own error sources. Most notably a power supply rejection ratio of only 74dB and offset of up to 6LSB, plus a couple of LSB here and there for smaller errors but they add up . If you take a look at the A/D LSBs, I'm sure the lowest 2-3 bits are bouncing up and down buried in noise . In order to have 12 "good" bits it'd need a signal to noise ratio of 72dB . I doubt the breadboard you have is silent enough to not introduce supply noise .
Then there's the reference voltage noise and drift . All the little offsets, power supply and reference induced noise, drift , etc add up and you need really good pcb design techniques and really good precision components to have true 12 bits , or you need to compensate a lot thru firmware , average a large number of A/D samples, filter, track temperature to compensate for drifts etc.
The problem is not that you want 20 mil cpr but when you calculate the arctan , the error of this calculation has an error that increases in inverse proportion with the cosine value. The cosine value is affected by the A/D error, especially for low cosine values so you get a deviation from the real angle just due to division by small numbers . Then your feedback loop just happily tracks these errors as much as it does track the mount errors.
So all being said , it's great that the device works as it does right now but you need to test real tracking to make sure you're not seeing and tracking your encoder and electronics errors .


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]
      #5766157 - 03/30/13 04:44 AM

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


Post Extras: Print Post   Remind Me!   Notify Moderator  
cn register 5
scholastic sledgehammer


Reged: 12/26/12

Re: Encoder-based PE Correction on the cheap new [Re: mattflastro]
      #5766164 - 03/30/13 05:03 AM

The EQ North or EQ South question can be resolved by looking at the direction the Ra axis is rotating rather than relying on the user to set it correctly. You should be in a good position to try this!

I'd be tempted to put most of the other setup data that requires switches into a setup program on a PC that sends commands to the Arduino through the USB connector. That will remove the need for a lot of configuration switches. The Arduino can remember the setup for next time.

I'd also avoid lots of additional features, that can easily cause this project to be never ending.

Chris


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]
      #5766179 - 03/30/13 05:38 AM

Hi Orlando,

Quote:

1) read the switch to determine EQ North / EQ South operation


At start-up a quick "training" could be performed just to determine N/S hemisphere location.

Quote:

3) read the switch to reverse RA guiding (in case of an ST-4 port that is wired in reverse)


You can add an hardware manual switch to revert RA outputs.
Anyway you can still revert the outputs by software according to start-up training results (when required)...

Quote:

The ceramic resonator @ 100ppm would drift by about 130" in a sidereal day, or about 2" in 20 minutes.

A normal crystal oscillator @ 20ppm would drift by 1" in 60 minutes.


I think guiding is still essential.
Even if adding ST4 inputs will involve firmware complications, I think it's the cheapest mode to ignore these oscillator issues: guiding software will take care of them and "reset" the consequent drift.

CS
Armando Beneduce


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: Armando]
      #5766331 - 03/30/13 09:10 AM

Hi all,
Thanks for the updates. Particularly around the limits of interpolation.

The ERN480 is only rated to 1/20 grating period so high interpolation is going to be more wishful thinking than reality.

And yes thanks for pointing out that at low cosine terms the error will increase. I am currently doing 16 fold averaging.

But one way to sidestep the cosine term issue is to NOT believe the encoder when the cosine term is small. That would mean at worst 5 seconds when we are blind. The encoder has a slot period of 17 seconds.

I agree that tight guiding will address all these issues. I want something dead simple for unguided imaging. And frankly it sounds like a cool thing to do.


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

Reged: 07/03/04

Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5766360 - 03/30/13 09:29 AM

Found a set of pictures: http://www.mda-telescoop.com/index.php?option=com_content&task=view&i...
I don't think it uses interpolation.

Clear Skies!

ccs_hello


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: ccs_hello]
      #5766365 - 03/30/13 09:33 AM

It uses an ERN480.

So I don't see how they can get the required accuracy without interpolation.


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

Reged: 07/03/04

Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5766372 - 03/30/13 09:39 AM

Yeah. I think the use case is quite different (most likely "push to" DSC system.)

I somehow feel using worm-shaft side encoder with "zero" position index (to count number of worm shaft rotations) is an easier task to tackle from positioning accuracy point of view.

Clear Skies!

ccs_hello


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: ccs_hello]
      #5766395 - 03/30/13 09:59 AM

The link to the MDA Teleskoop site is for a TDM. Which does periodic error correction using an encoder.

As for having an encoder on the worm... The Temma uses a worm side encoder. So the only issue is worm periodic error.

But most mounts put the encoder on the motor, where it can't compensate for errors in the gearbox.


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

Reged: 07/03/04

Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5766401 - 03/30/13 10:03 AM

(DC perm mag) motor shaft encoder is only used to form the servo loop, with so high the gearbox reduction, will not be useful for any form of PEC.

Clear Skies!

ccs_hello


Post Extras: Print Post   Remind Me!   Notify Moderator  
cn register 5
scholastic sledgehammer


Reged: 12/26/12

Re: Encoder-based PE Correction on the cheap new [Re: orlyandico]
      #5766456 - 03/30/13 10:33 AM

Quote:

But one way to sidestep the cosine term issue is to NOT believe the encoder when the cosine term is small. That would mean at worst 5 seconds when we are blind. The encoder has a slot period of 17 seconds.



What I did for dome azimuth determination using a magnetic sensor was use Atan(Sin/Cos) when Cos was greater than Sin and 90 - Atan(Cos/Sin) when Sin was greater.

Chris


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: cn register 5]
      #5766505 - 03/30/13 10:56 AM

Chris, great idea!!! Thanks!!!

Will do that.


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: cn register 5]
      #5766654 - 03/30/13 11:51 AM

Quote:

Quote:

But one way to sidestep the cosine term issue is to NOT believe the encoder when the cosine term is small. That would mean at worst 5 seconds when we are blind. The encoder has a slot period of 17 seconds.



What I did for dome azimuth determination using a magnetic sensor was use Atan(Sin/Cos) when Cos was greater than Sin and 90 - Atan(Cos/Sin) when Sin was greater.

Chris



That's a good method and is used with success, but keep in mind there will be a jump in the calculated value at the crossover point between sin being greater and cos being greater when you flip the division from arctan to arccot . I've seen much more sophisticated methods being employed such as Kalman filtering .
Also another thought, if you consider the switch from Atmega to PIC, take a look at the Raspberry Pi, cheaper than the PIC thingy and much more powerful .


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
25 registered and 35 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: 14717

Jump to

CN Forums Home


Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics