Dome Sync Button's function

Hi Ken and Jared,

I have looked in the help file for help on the Observatory Sync button in the control panel, and it says

‘Sync the dome azimuth to a specific angle.’

I wonder could you elaborate a little on what this button does and what properties/ methods (if any) it uses in the ASCOM dome driver?

many thanks,
Paul

it directly calls the SyncToAzimuth implementation in ASCOM:
https://ascom-standards.org/Help/Developer/html/M_ASCOM_DeviceInterface_IDomeV2_SyncToAzimuth.htm

Thanks,
Jared

I have the SyncToAzimuth methd implememted in my dome driver. Sometimes, my dome is not quite aligned with the scope and to fix this I can use the Sync command from SGP. However, SGP asks for an azimuth to sync to. Because of the dome geometry math, the dome azimuth is not the same as the scope Az, so my question is how do I know what number to enter into the SGP Sync dialog?

At present, I ‘cheat’ because the MCU code I wrote to implement slew to azimuth prints the requested dome azimuth to an LCD screen. So I can see the requested dome az and type it into the SGP Sync dialog.

However, I am in process of moving my observatory to a remote location and won’t be physically in it when a sync might be neccessary.

In an ideal world the scope and dome aperture should be perfectly aligned, but despite carefully measuring all the offsets and entering them into sgp, I do get occasional misalignments.

I have watched the system go from a location of ‘perfect’ dome and scope alignment to a misaligned state when a sequence moves from one target to another. The dome does goto the requested azimuth, but is not poperly aligned.

Currently my Observatory is in the garden about 10 feet away from the house and I run it remotely by using a remote desktop connection.

Any thoughts or help on this greatly appreciated.
Paul

I considered doing my own dome automation, but in the end chickened out and went for the Pulsar dome automation system. I’ve never had a problem with misalignment, and I think that it is to do with the implementation of th

Oops … of the Pulsar system which tracks the dome position using a jockey wheel and an encoder, but also has a sensor that is triggered when the dome passes a magnet which recalibrates its position I guess. So it could go out of alignment if the tracking wheel slips against the dome, but that shouldn’t happen often, and it will reset itself when it passes its home position (I.e., when the sensor is triggered by the magnet).

Thanks for reply Terry, I’m currently purchasing a 2.2m half dome from Pulsar. I have the automation features you mention implemented in my dome driver and control electronics. Including the jockey wheel encoder.
I’ve systematically tested it, including ensuring that the Azimuth encoder does not create any cumulative error. The way I set my dome home position up (which may be in error ) was to point the scope due west 270 Az and then look to see what Az request SGP (or any ascom s/w) sends to the dome controller via the dome driver. It actually requests 261 degrees (to correspond with the Scope Az of 270), so that’s my sync’d starting point. Generally it seems to work well, but I get these occasional glitches where the dome aperture half covers the scope aperture. Really annoyingly (hyper annoyingly if you want to go there…) the dome azimuth request sent from SGP corresponds with the Dome Azimuth encoder, so the dome control has done it’s stuff. So at that point, I just give in (for the sake of imaging time in a session) and move the dome whilst physically holding the dome Azimuth encoder stationary.

I will have the new dome from Pulsar in about four weeks and will then be installing my dome drive into it. So I’ll work on the problem a bit between now and then.

So when I used the SGP sync command I was a bit perplexed … how do you know the right number to enter into the sync box?

Paul

Paul, I’ve never needed to use this so I may be wrong about it, but I assume that it works a bit like the offset model in EQMOD, namely if the dome is actually pointing to 270 degrees where the ASCOM driver has asked for 261, then you would enter the actual done position (270) and the driver would calculate the offset at 9 degrees and use that until told to do otherwise. But that will only work if it is implemented in the ASCOM driver I guess - did you write your own? I never got as far as writing an ASCOM driver - i’d sorted out all the maths to figure out dome position from the scope RA and DEC and written a windows program to communicate with the arduino, but my problem was the mechanics of driving the dome. Of course SGpro takes care of those calculations for me now anyway.[quote=“Paulkirk, post:6, topic:12958, full:true”]
Thanks for reply Terry, I’m currently purchasing a 2.2m half dome from Pulsar. I have the automation features you mention implemented in my dome driver and control electronics. Including the jockey wheel encoder.
I’ve systematically tested it, including ensuring that the Azimuth encoder does not create any cumulative error. The way I set my dome home position up (which may be in error ) was to point the scope due west 270 Az and then look to see what Az request SGP (or any ascom s/w) sends to the dome controller via the dome driver. It actually requests 261 degrees (to correspond with the Scope Az of 270), so that’s my sync’d starting point. Generally it seems to work well, but I get these occasional glitches where the dome aperture half covers the scope aperture. Really annoyingly (hyper annoyingly if you want to go there…) the dome azimuth request sent from SGP corresponds with the Dome Azimuth encoder, so the dome control has done it’s stuff. So at that point, I just give in (for the sake of imaging time in a session) and move the dome whilst physically holding the dome Azimuth encoder stationary.

I will have the new dome from Pulsar in about four weeks and will then be installing my dome drive into it. So I’ll work on the problem a bit between now and then.

So when I used the SGP sync command I was a bit perplexed … how do you know the right number to enter into the sync box?

Paul
[/quote]

Thanks Terry. I’ll give that a go and see what happens re offset.

Yes I wrote my own driver with initial help from Tom How and his ASCOM driver videos. I have never looked at the maths as it’s provided by Tom for the ASCOM Dome/ Telescope hub, which I used for a while - with that you can choose to have the old POTH type calculations or the new ones. I found writing the driver ok, steep learning curve to start, but once you’re into the mindset its easy enough. The interesting thing is there’s not much to go wrong if you use the ASCOM templates - they really are a fantastic aid to driver construction. So for instance the Slew to Azimuth method just sends the requested azimuth to my arduino and it drives the stepper until the arduino controlling the dome azimuth encoder reports that the dome azimuth is the same as the target azimuth (within a few degrees to allow for steppers to decelerate) - not much to go wrong.

It’s helpful that you mentioned the Pulsar system works well, which confirms that it’s receiving the correct Azimuth requests. Is your mount at the centre of the dome or do you have to use offsets? I have a MESU 200 and it’s a GEM with about 40cm offset from the RA?DEC pivot to the optical axis of the scope. I’ve plugged all that in to SGP.

I used toothed timing belt around the inside periphery of my dome as the drive mechanism. A toothed wheel on the stepper drives a another loop of timing belt (with an idler wheel) which meshes with the belt on the dome periphery. That way Ive got about 30 teeth in mesh to overome the starting friction. It works really well.

Anyway, I’ll try a few things with some daytime slews and see if I can narrow down where the error occurs.

Nice touch writing your own Windows stuff based on the dome Maths btw.

Paul