Wandering Dome Sync

Sequence Generator
61

Hi @Chris,

Although it was raining, I did a bunch of test with the dome shutter closed.
Therefore, I can’t really tell you if the scopes were actually both pointing out of the slit or not, but just by looking at the security camera video, it looked like the ASCOM driven parameters lined up, and the SGP ones did not.

So, things I did:

Tested the dome position - went in there with a compass on my phone (set to work off true not magnetic).
I marked out the cardinal points, and they are very close to what I had already marked (within a few degrees). I slewed the dome to the various points, and they were very close to exact.

All the parameters were recorded in the same units, and I used the same parameters in SGP and ASCOM (ie specifically I used RADIUS - I ignored the advice to use diameter)

I had to adjust my process to be southern hemisphere centric.

I would point somewhere (with no slaving)
I would then slave to the ASCOM driver, and record the position reported after the slew.
I would unslave the ASCOM driver, then slave the SGP dome controller, and record the position.
I had the polling interval at 5 seconds, to minimise the waiting times.

The first run, I took the 8 points that the telescope was reporting for it’s AZ (roughly).

The second run, I found targets in CdC that roughly correlated (typically within 1 degree) of the cardinal points, and slewed to that target. The DEC had to change to try and find targets, but I kept the targets typically between 10 to 30 degrees if I could.

I’ve drawn the dome layout, and I’ve collated all the data in Excel.
I’m hoping I’ve covered off all the things you asked me to do, but short of being able to verify with the imaging cameras that I can see out of the slit (will have to wait until it’s not raining/clouded out), I think I’ve been as comprehensive as I can.

Not really sure what to make of this, other than confirming that the SGP figures are very different from the ASCOM figures for the same dome parameters.

Thanks again for the detailed methodology to follow!

62

Just wondering how close it worked? Only reason I am asking is that I notice a slight difference in the RA & DEC reported on your Sky Watcher window and the SGP window…(just froze one of the frames in your video to have a look)
That may not be enough to make the difference you are seeing…and I guess we might be clutching at straws here…but ???

63

Thanks, that’s exactly the sort of data I was thinking would be useful. It’s going to take some time to go through this in detail but a couple of things strike me:

First, you are in the Southern Hemisphere. It’s very easy for the dome calculations to be wrong in the Southern hemisphere, some things are rotated and some are mirrored.

The second thing is the first data point, with an azimuth of exactly 180. That’s looking South towards the South pole.
Assuming that the Ra puts the mount with the counterweight down then the scopes are positioned over the mount. In that case the pier side and dec offset have no effect and what’s left to affect the position is the mount EW offset.

ASCOM gives a dome position that’s 3.5 degrees East of the scope and SGP a position that’s 5.27 degrees West. Could the sign of the EW correction be wrong? Try reversing the correction direction in SGP and see what happens. It’s the sort of thing that could be a effect of being in the Southern hemisphere, you dome is upside down.

This reversal might also apply to the NS direction but it isn’t so obvious.

It will need calculation, maybe setting up a mount indoors, at least converting your time and location to sidereal time then the Ra to hour angle. if you do some more and can get the hour angle it might help.

Hope this helps.

64

Hi Chris,
you’re correct in that the first record is polar home for me.

I tried the same home position this morning (because it’s easy!), and tried the same parameters as last night (as a baseline), as I’m measuring the output dome position which will have some mechanical error.

Last Night:
ASCOM AZ = 176.5 (3.5 E)
SGP AZ = 185.27 (5.27W)

Today:
ASCOM AZ = 172.1 (7.9 E)
SGP AZ = 186.1 (6.1 W)
SGP AZ (with E/W sign Flipped) = 174.7 (5.3E)

This is of course way closer (and within 2 degrees of the ASCOM calculation)

I’ll make an attempt at running the positions through a formula to calculate the Hour Angle. For this first position (polar home) it is precisely -6:00:00.

65

I’ve updated the spreadsheet by calculating the Sidereal time (via a web tool) and then calculating the hour angle.

66

I think the difference you’re talking about is the fact that SGP reports everything back in J2000 and other things like ASCOM and the SkyWatcher Driver I am using report in Jnow (my driver refers to it’s system as “Local Topocentric”)

This stuff is a huge learning curve, and I’m drowing in it a bit right now, especially because all I ever want to do is point at a target and image it. This stuff is over the top!

I’ve taken a screenshot with the driver set to J2000 (SGP still doesn’t match what the driver reports though - it’s about 15 minutes off in RA and about 7 minutes off in DEC which is weird) and a screenshot of it set as normal “Local Topocentric”

J2000

Local Topocentric

It’s worth mentioning though, that I’ve never had SGP not be able to find targets fed to it by me pasting from CdC or it being taken from Astrobin or Telescopium etc. It clearly knows where it is pointing.

67

Thanks, saved me the trouble.
We seem to have found an explanation for the EW difference, a 2 degree difference is within experimental error.
Looking at the values for hour angles close to -6 or +6, these are also with the dec counterweight pointing down, the SGP values are consistently North of the ASCOM values which suggests that the mount needs to be moved South in SGP, maybe reversing the NS values.

This comes up with a way to set things up:

  1. Set a more or less sensible dome diameter or radius. Don’t change it.
  2. Make sure that your mount is aligned, at least a quick align.
  3. Point the telescope at the pole, with the counterweight shaft down, Ha +6h or -6h, dec 90 or -90.
  4. Adjust the mount EW position until the scope can see out.
  5. Rotate the telescope in Dec until it is pointing at the East or West horizon. This should correspond to Ha +6h or -6h and a dec of 0.
  6. Adjust the mount NS position until the scopes can see out.
  7. That should have the NS and EW mount position sorted. Now point the mount to an HA of +0h or -0h, looking at the Northern or Southern horizon. The dome should move East when the mount is on the East and West when the mount is on the west.
  8. If the dome is moving too far then reduce the dec offset, if not enough then increase it.
  9. If the dome is moving west when the mount is on the east and vice versa the use a negative dome offset.

That should at least get you close. The positions are chosen so that one parameter dominates the dome position calculation and just that parameter is changed. The order matters, at least do the gem axis ffset after the mount position has been set.

68

Astronomy is a technical science and it really needs some understanding of the basics, in particular, for telescope pointing, the different coordinate systems.

This is because we are living at various places on a ball of rock that’s rotating, whirling round the sun and being pulling all sorts of ways by other objects, particularly the moon. It’s wobbling around every which way.

J2000 is a standard set of coordinates that define where everything was at midnight at the start of the year 2000.
Local Topocentric (LT) is where objects are for you and your telescope now. This varies mainly because of precession, where the direction of the axis of rotation of the Earth changes - mostly because of the influence of the Moon. The change is roughly one arc minute a year so by now J2000 and LT are 20 arc minutes different and this affects the position of an object by enough to notice. This can all be managed, it’s just arithmetic, especially at the precision we need, but doing so requires that everything that uses a coordinate system reports what they use correctly and that the system does the corrections correctly. Most of the time recently the difference between J2000 and LT has been small so it hasn’t mattered much.

There are online resources, for example some universities publish lecture notes for a basic astronomy course, search for astronomy 101 may come up with somethign useful. I suggest finding one and going through it, studying the parts that are relevant, such as astronomical coordinate systems in some detail.

69

Thanks Chris.

I’ll see if I can manage any of this tonight. It seems clear for the moment, but around here, it can change really quickly!

I’m going to stick with the radius as it was - it seems to make sense to leave that alone.
The dome is pretty well polar aligned, and it’s permanently mounted, so it really should have moved much. The drift over an entire night is pretty minimal for me, so I’m pretty confident I’ve got that in the ballpark.

I’ll report back on my findings.

Thanks.

70

Yes, leave the dome radius alone. All the other measures are scaled by this so if you change it you change everything in proportion.

Thinking about it a bit more, once the EW mount offset is set it may be better doing the GEM axis offset, with the mount pointing at the North horizon before checking the NS offset while looking East and West. This is because the EW position depends on both the GEM offset and the mount position while the correction when looking North or South mainly depends on the GEM offset and EW offset.

Going round the cycle of setting EW, Setting GEM offset and Setting NS a couple of times may help.

71

We have something to report!

The only thing I changed from the ASCOM setting was reversing the sign on the E/W.

So far, for all the points I have tested on the E/N/W horizon, the dome is pointing in the right place.
I also had a go at stuff near the zenith, and that worked too. As tested this morning, at the home position pointing south, it was within 2 degrees of the ASCOM position (and well within the mechanical tolerances).

I do have a limit of not going below about 30 degrees, simply because my side-by-side setup means that either the guide scope or the imaging scope will be shooting in to the dome walls below the dome equator, but I can’t solve that without getting a pier extension. That’s not worth it anyway, as my horizon and the light pollution below about 30 degrees means I won’t image near there anyway.

I’ll do some more random pointing around the sky and see if there’s consistency or any outlying issues, but I think the solution is we need to look at the algorithm in SGP and see if it is handling the Southern Hemisphere correctly for the E/W calculation.

Thanks again Chris - your methodical approach to this has (potentially!) solved this.

ps. I am running the radius as radius - not playing around with putting diameter in there anymore!

Fingers crossed :crossed_fingers: I don’t find any other targets that are a problem.

72

I spoke too soon. I went to pickup on a project I was running last week, and although both guide and imaging cameras are looking through the slit, the guide camera is right on the edge and is showing a bit of washout.

Date: Friday, 17 April 2020 Time: 12:06:51 AM
RA: 16h 41:13.76 Dec: -48° 38:40.99
Sidereal 13:28:46 HA: -3:12:16
Alt: 53° 52:10.21 Az: 123° 19:51.06
Pier:West
Ascom dome pos:85.2
SGP dome pos: 118.5

I’m just going to leave it be tonight - it’s after midnight and I’ve got a meeting in the morning.
I’m hoping the next steps are trying to look at this from a source code perspective on SGP’s part, rather than doing this reverse engineering exercise to prove that the ASCOM implementation works and the SGP one doesn’t.

Thanks again for your help Chris.

73

Good to hear it helped.

If the positioning is OK round the horizon but not at higher altitudes then it could be that what matters is the vertical offset. I don’t have a good handle on that and I’m not convinced it would help.

What I did to help debug this was develop dome and scope 3D models using WPF and run them up with simulators. Then your values could be plugged in and we see where things end up. It gave me a very nice 3D observatory mimic display; it’s nice to be able to peer through the shutters and see the mount looking back…
image
This never came to anything, there was too much for a free application and I didn’t fancy the support committments of doing it commercially. but it does illustrate how I think observatory control and management and image acquisition applications should be separated. This would have exposed a number of ASCOM interfaces to the imager, mainly scope and safety, and handled the observatory management independently.

All the imaging application needs is to know it’s safe and to be able to point the telescope.

74

@Chris I’ve been looking for EXACTLY that…for our testing…would you be willing to share the source or an EXE. I won’t bug you for support :slight_smile:

Thank you,
Jared

75

I should have seen that coming :slight_smile: Well, I did, wouldn’t have been so forthcoming if I hadn’t.

No objection in principle, let’s take this off line. I haven’t touched it since late 2015 when life (actually my wife’s death) got in the way. I’ll probably need to check it out before inflicting it on you.

76

Chris,

I literally asked the developer of my scope driver (GSS) to model a dome around his 3d model of the scope he already has in his driver. It’s way outside the scope of what is necessary for a telescope driver to function but it would be nice to see it.

That’s pretty awesome.

Indeed - that’s what I was doing last night in the cold! Would be much nicer to do it from my desk!

77

Hi @Jared, was wondering if any progress has been made on this, or if you require any input to assist in testing?

78

I just received my notification to resubscribe, and was wondering if any work is planned on resolving this issue any time soon? Is it even on the roadmap?

Thanks.
Rob