My French (I think???) is not that great…but I wonder if the “number of steps per turn” and/or the dome diameter is not right in the dome driver and.
This is more just “trying to figure out what is wrong”…so feel free to disregard. But if you change your dome diameter in your dome software and then move things around with your dome software does the outcome change? How does the “number of steps per turn” get used? It would seem that your dome software wouldn’t really care about the diameter unless it was slaving your telescope.
I never felt great about changing it to radius … I will likely change it back.
Yes - French (a foreign language to me too). I can, via the dome ASCOM driver move the dome to any particular angle - so I guess the steps per turn is connected to the drive motor and the sensor that will then convert that to an angle. As things are - this will work fine because some nights I just send the shutter opening to maybe 001° so that I can check polar alignment on the mount (if I have been adjusting anything). I have not checked if having the correct diameter in that driver has any effect outside of SGP - I f I get around to doing that I will let you know. As it stands - I have no idea where the diameter (or radius) input in the ASCOM driver then comes into it - maybe it is available to SGP some way or other but it sure did have an effect when originally this was set (in my case) to the coorect 2m dome diameter. (This was when using SGP - and I could not keep dome and scope aligned).
I am guessing there is some connection between this input and the same input in SGP - as I said, others changed to diameter to radius as the input in SGP - whereas I did it in the ASCOM driver…with apparantly the same end result…it just worked! I have no idea though if they were using the same dome driver as I am…so cannot point to it definitely being an error in the dome driver input.
I suspect that people complained because they got confused.
I suspect they had working settings in ASCOM or similar, using Radius, then just copied the same numbers in to SGP and then saw weird behaviour.
If the algorithm that you use requires Diameter, then label it that way (or as I suggested, leave it labelled that way for consistency with others and double it internally). You wrote/implemented the code, you guys know how it’s supposed to work.
If random people either did not sufficiently pay attention, or just simply have weird setups that require something else to work, then that really becomes an issue for them.
It took me 3 goes at getting the right measurements in to the ASCOM driver (there is very little in the way of describing the geometry visually - exactly what is the GEM AXIS? I had to find a post on Cloudy Nights to work it out). I was reluctant to change this once it was working. I can see why people may fall in to the trap.
ps. for the first time, I woke up with everything parked, closed up, and an image directory full. Very happy! I have confidence moving forward and not babysitting it all night!
I’m probably one of the folks Brendan (Kinch) referred to with similar dome issues.
Here’s an attached image showing my setup with both the Ascom Dome Control (center left) and the SGPro Observatory Settings (center right).
Note the Ascom application calls for the dome radius (i.e. 46 in). This has always been the case and has worked as intended.
The SGPro Observatory Settings had originally called for the dome diameter. Likely when I first set up SGPro was when the problem (as discussed above) showed up. Brendan suggested for me to change the diameter value to the radius, and all worked as intended.
Well I wrote it but the math was from a white paper on the subject so I’m certainly not an expert in it and probably lack the knowledge to completely reverse engineer it…and sadly no longer have a dome to test it…that level of trig is hard.
Hi Jared,
Unfortunately, tonight I’ve run in to an alignment issue getting the dome in the right place - it is about 5-10 degrees out in azimuth. If I turn off the slaving in SGP, and use the ascom device hub driver directly to slave from the scope, it moves exactly to the right place.
I really need to be able to have SGP open/close/control the dome precisely throughout the night, otherwise it’s all a bit pointless.
I know this is exceedingly frustrating, especially since everyone is reporting different information, but I’m more than happy to assist in whatever capacity I can to debug this in order to get a solution. I don’t really know how I can help, but happy to help with any testing scenario you can think of.
@Jared, I’ve purchased a full licence to SGP now as my trial has ended, even though the dome alignment issue is still a major problem for me, I’m hoping it can be resolved.
I’d be happy to try and debug the issue.
I have viewed the source in the ASCOM Device Hub, which I know points correctly as I use it instead of the SGP implementation at the moment.
I’d be happy to try and sanity check your source, or provide any testing you’d like to try to get this working natively in SGP. Frankly, it’s the only thing stopping me from confidently letting the scope run all night on it’s own knowing the dome functions properly if this is fixed.
Please let me know if I can assist in any way (as for most people at the moment, I’ve got some time on my hands!)
Hi Turbo…if you have not done it …and since you have nothing to lose with a trial & error…try things the way I have mine set…with the Ascom driver set at Radius and SGP set to Diameter.
It works for me and as such I have just left things as are without spending any time trying to figure it out. I don’t think this works for everyone…but like I said…no harm in trying it to see if that way around will work for you too.
Thanks Kinch. I have tried this.
It did improve things a fair bit, and for some parts of the sky it seems to work, but not enough to make me confident. The last 2-3 weeks, everything I’m shooting fails alignment (just because of the general areas of the sky I’m shooting)
My main problem is that with the misalignment, I run in to a number of problems which cause the sequence to fail and shut down the dome for the night.
I have a side-by-side setup - sometimes the dome slit is OK for the main scope, but not the guide scope - guiding fails, everything shuts down
dome alignment off during a plate solve (ie I’m photographing the inside of the dome) then it shuts down (particularly a major problem after the meridian flip!)
because I can’t trust the SGP control, I use the ASCOM driver to manage the dome position. That solves all my alignment issues, but means that:
3a) the dome doesn’t close at the end of the session
3b) if there’s an observing event issue (rain detected, wind too high etc), the dome won’t close, and then reopen when the situation is resolved.
it also acts DIFFERENTLY when doing the plate-solving/focusing, compared to the normal sequence times. It’s like there are different routines used depending on what task is running.
I can only hope it will be resolved in future - I’m more than happy to do a bunch of testing.
If you contact me at BrenKinch - at - Gmail - dot - com I hope I can point to something that MAY just be of help until this particular issue gets sorted for you in SGP.
What version of SGP are you using? The most current release (3.1.0.457) should have addressed this. If you’re still seeing this behavior we’ll need logs to see if maybe your telescope doesn’t support one of the needed functions.
SGP and Device Hub actually use the same underlying math for calculating the dome position, so it’s interesting that given the same values that you’re seeing different behavior.
Hey Jared.
Re: position difference during plate solve
Last time I tested that was on a previous version. I’ll reserve judgement on that one until I can retest that particular issue.
Re: same algorithm
I currently have the dome radius set to be the diameter as per previous discussions. Did this revert back again?
Is there any test you’d like me to try to compare the two methods?
Unfortunately, I tried with both the radius and diameter - both produced similar positions, both of which were wrong compared to the dome being slaved via ASCOM. The difference in az is about 25 degrees on the target I was testing on.
Sample video (about 28Mb) showing what happens to my guider image when controlling the dome via SGP vs the ASCOM driver control. ignore the fact that it’s super cloudy. Makes it slightly less obvious how dramatic a difference it makes.
One thing that I’ve found useful when debugging dome synchronising software is to be methodical about what directions you use for testing and record things carefully.
First check that the dome will actually move to the azimuth you specify reliably and that the azimuth is correct, for example when you slew to an azimuth of 180 is the dome shutter really looking South?
Then set the mount to a declination of close to 90 and an hour angle of +6 or -6 hours so the dec counterweight shaft is pointed down and the scope is above the mount looking North. Are the scopes looking out through the shutter? They seem to be sufficiently far apart that it will need to be pretty accurate for both to be able to see out in this position. In this position the only thing that makes a big difference is the EW offset. You may need to avoid exactly 90 dec because things get difficult there but 85 deg should be OK.
Try with the scopes looking towards the Southern horizon, with the mount on both sides of the pier. Check the position the dome slews to and if the scopes can’t see out where the dome should be. There should be some symmetry in the two positions and adjusting the dex axis offset may help although this will interact with the dome radius/diameter.
Try with the scope looking horizontal in varying directions, N, NE, E, SE, S, SW, W NW, N. Use both pier sides where you can and record where the dome synchronising puts the dome and where it needs to be to be able to see out.
One thing to remember is that you will almost certainly need to use the same units for all dome parameters, all inches, or all cm, even all miles. It doesn’t matter because what comes out of the dome position calculator is an angle and angles don’t have units, they are ratios.
Another thing with this is that the mount must report pier side correctly. Not all do and if it doesn’t, or doesn’t everywhere, then the dome synchronising doesn’t have a chance.
Thanks Chris. I very much appreciate the feedback and pointers.
I guess my concern is that I have used 2 different alternative products (the ASCOM Device Hub, and Voyager) and they act “correctly” and I have no alignment issues. SGP does have the problem.
In terms of the side-by-side setup, the video is a bit misleading. The slit width is something like 750mm and the distance between the two scopes would be no more than 45cm. They are both only 80mm refractors, so there is plenty of wiggle room in slit alignment.
The parameters I’ve entered work off the fact that there is a “virtual” scope at the centre of the shaft, so I’m not entering any offset for the side-by-side setup at all, I’m just pretending there’s a scope in the middle.
I have ensured all my measurements are the same units. I’m fairly certain the slews are correct for the dome. I will check these again in daylight however to make sure. I have some tape on the dome circumference that shows it is “about right” (at the start of the video, the AZ reads 97, and there is bright reflective tape at (roughly) 90, and some slightly darker tape at the widths of the slit). So with a bit of error, it’s in the ballpark. I did this so it’s a bit easier to work out the cardinal points when I’m in the dome and lose my bearings a bit. Not that I spend much time physically in there!
I appreciate this is pretty tough to diagnose, but I’d like to see for a given set of parameters and pointing locations, what the “correct” value should be, and see if SGP is producing it. Whatever is happening, it is producing a different number to multiple other bits of software, that, at least from a functional standpoint, give me the result I’m expecting.
450mm between the scopes and 2 * 80mm for the scopes comes to 610mm leaving a total of 140mm spare, 70mm each side. That’s pretty close, about 3.5 degrees.
We can’t tell you that because we don’t know the properties of your system. If we could we wouldn’t need all the setup stuff. I gave you a way to find out for yourself by setting the mount to some well chosen positions and recording where the dome was positioned and where it should be. It requires more work than posting a few messages but is likely to be more effective.
Incidentally the ASCOM dome sync stuff is mine. I saw the massively complex algorithm that I guess Jared is using and decided that there must be a simpler way. I get the 3D position of the mount by applying a few rotations to the mount - by latitude, hour angle and declination IIRC - and then using Paul Bourke’s intersection of a line and a sphere to get the azimuth and elevation. That boils down to solving a quadratic equation and for a line that starts inside and ends outside there’s only one solution.
I’ll go measure it properly - but I understand - it does need a degree of precision applied regardless of the wiggle room!
I’ll go and run a set of figures for SGP using the same parameters as I have in ASCOM, and also a variant using diameter instead (as has been suggested), and compare with ASCOM version.
I could use the position the dome reports back asfter the slew, but that is probably a bit error prone.
I can get the “requested” position by analysing the SGP logs to be a bit more accurate.
I’m assuming there will be a log somewhere in ASCOM that will be similar, so I’ll dig around later to see what I can find in order to give it some further accuracy.
I read the code - I love the simplification - it is very elegant.
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!
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 ???
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.
