Username:

Password:

Altair AstroDIO DehumidifiersAtik CamerasModern AstronomyDavid HindsNe3 Filters

Author Topic: Dome Motorisation  (Read 3327 times)

0 Members and 1 Guest are viewing this topic.

Offline tomhow

  • Tom How
  • Galactic Poster
  • ******
  • Posts: 3112
  • Making equipment is far more fun than buying it.
    • The Curdridge Observatory
Re: Dome Motorisation
« Reply #75 on: 20:47:07, 28 June, 2017 »
Does anyone know for sure that the coordinate transforms in the ASCOM dome driver are actually correct ?  I couldn't find any explanation as to how to set up the geometry parameters (the link was broken), so I tried several different ways.


I'm pretty sure they are about right. I also wrote my own implementation of the geometry - this is how I uncovered the bug above - and it agreed 100% with POTH once I inverted the E/W figure.

My notes on the geometry are here http://astro.neutral.org/arduino/telescope-dome-synchronise.shtml
From talking to the chap who wrote POTH, I understand it works along the same lines.
But I'm well aware there are various ways of skinning that particular cat, so there may be more than one right answer.

The parameters are (assuming a perfectly hemispherical dome)
1)The XYZ of the mount ra/dec intersection relative to the centre of the dome. i.e. where they cross, which is a point usually "inside" the dec axis somewhere. The dome is a hemisphere, and the centre is the centre of the "sphere".
e.g. if the mount is 100mm north of the centre then the +N/-S figure is +100mm
2)The COG-optical, which is the distance from the ra/dec intersection above and the optical axis of the scope. Usually in the order of about 200-400mm
3)The radius of the dome. Be sure not to put in the diameter, which I've done more times than I can count!

There are also the precision and frequency terms. POTH makes no attempt to move the dome continuously. As you say, it can't go infinitely fast! :) So it merely nudges the dome into the correct place at a "frequency" when the actual/required error is greater than precision.

Another lesson  learned on POTH - if you put a precision of <1 degree, it ignores the frequency and tries to correct the dome every second... which whilst still correct means the motor runs a lot more than it needs to.
Tak Sky 90, Atik 490, Homemade Mount, OAG, Lodestar

The Curdridge Observatory

Offline tomhow

  • Tom How
  • Galactic Poster
  • ******
  • Posts: 3112
  • Making equipment is far more fun than buying it.
    • The Curdridge Observatory
Re: Dome Motorisation
« Reply #76 on: 20:56:14, 28 June, 2017 »
Hi, Tom, thanks for the tips.

Good idea to try my mount with a simulated Observatory.  The I'll know what can and can't be accomplished.  Just got back from holiday, so I'll try that before ordering components.  Because my (Gemini G41) mount will GOTO the 'wrong' side, I often can extend my imaging session.   But when setting up it is necessary to tell the mount which side the telescope is on.  So hopefully it will have the necessary SideOfPier property in it's communications to POTH.  We shall see!

Cheers,

Peter.

Yes, this is how I discovered the destination sideofpier property.  I can also GOTO my mount to the "wrong" side to extend the imaging run, and this resulted in quite a bit of dome travel until I found the destinationsideofpier thing and programmed my way out of that particular mess.

If your supplied driver doesn't handle it properly, it isn't insurmountable, you can write an extra telescope driver than wraps around the supplied one but features a big button to manually set the side property. Albeit a rather tedious piece to write.
Tak Sky 90, Atik 490, Homemade Mount, OAG, Lodestar

The Curdridge Observatory

 

ukbuysellRemote Imaging from AustraliaSharpSkyblank APTUKAI on Facebook
Powered by SMF 2.0.13 | SMF © 2006, Simple Machines LLC
DarkBreak by DzinerStudio. Theme modified by The UKAI Team

Page created in 0.397 seconds with 36 queries.
TinyPortal © 2005-2012