I am trying to slave the dome to the scope using a simulator for the scope. I am using LesveDomeNet. It slaves perfectly in MaxIm DL. When I enter the same slaving parameters in SGP it is not even close. The dome module reports the correct azimuth, but it is nowhere close to the azimuth of the target. How do I find out why that is so that I can correct the problem?
Assuming you have a GEM, the azimuth of the target and the azimuth of the dome will rarely ever be the same. If you have parameters that were working in Maxim then you should be able to validate that your settings are correct in SGP by moving to the same general location with both applications and verifying the dome location is about the same.
Also I’m not sure what Maxim uses, but you may want to make sure that all the parameters are taken from the same location and that the dome is diameter and not radius.
Thanks,
Jared
Thanks, Jared. Please see my reply to Andrew J’s post today about Dome Setup with SGP.
No, I am not using a GEM. I am using an LX200 fork mount.
I have tried both radius and diameter. Neither works.
Manning
I’m replying here to keep the threads in sync. Please avoid cross posting issues as it makes things difficult to follow.
As for your issue with an alt/az mount. I can’t seem to duplicate things. Using the telescope simulator and Dome simulator the azimuths are always very much in sync as you would expect them to be in that case. Maybe you can take a shot of your dome slaving parameters and we can go from there:
Thanks,
Jared
Hi Jared,
Thank you for replying to my post. I appreciate your help in getting me operational with SGP.
I am sorry if I posted my problem in an incorrect manner. I was not trying to make it confusing but rather to consolidate information with Andrew’s similar problem in the hope that having the information collected in one thread it might shed light on the problem’s cause.
I am sorry that I was unclear about my mount. It is an LX200 fork, but it is NOT mounted Alt/Az. It is mounted on a wedge. Obviously that is going to lead to a different result from an Alt/Az mounted scope.
The ASCOM driver for the LX200 Classic, unlike the Simulator driver, only contains a checkbox for a GEM mount. In my case this is unchecked because I am using a fork, not a GEM mount. However, my scope is mounted equatorially. Unlike the simulator setup, the LX200 Classic setup does not contain a checkbox for “Equatorial”.
Does SGP then assume the mounting is Alt/Az? Is there an option somewhere in SGP to explicitly set the mount type to Equatorial (not GEM)?
I can send you the logfile if that would be helpful and if you tell me how to do so.
I am not at the observatory now, but I can try to get screen captures of the Observatory Settings and slaving parameters tomorrow.
Thanks again for your help.
Manning
Hi Jared,
I am not sure if these are the screen captures you need. Hopefully they are.
Tonight I performed some additional tests.
I used ASCOM Dome Control to connect to the scope and dome and then slaved the dome to the scope. Neither the initial slave to the scope’s park position, nor a slave after moving the scope 5 * N and 15* E were aligned.
I then used POTH to connect the scope and dome and repeated the above test. The results were the same. SGP was not involved in either test.
These tests indicate the problem is not simply with SGP. And, they do not explain why in MaxIm DL the dome slaving works correctly.
At this point, the results suggest, I think, that I may have no choice but to change the slaving parameters. Since they derive from measurements, I am unsure how to change them except by trial and error. The only other alternative I can see is to use scripts and try to command MaxIm DL to move the telescope and slave the dome. I do not know how to do that or even if it is possible.
From my test results it would appear that perhaps SGP, ASCOM Dome Control, and POTH all use the same algorithm to compute the required dome azimuth. Since I do not know the internals of any of those programs, I don’t know if that conclusion is significant or not. It does concern me that a previous test showed a dome azimuth result that, were it correct, would have aligned the dome with the scope. In fact, tonight’s tests were similar in that the reported scope azimuth and the dome’s reported azimuth were with a few degrees yet the dome was not looking through the slit.
I welcome any ideas how to proceed.
Thank you,
Manning
I can confirm that POTH and ASCOMDome use the same algorithm to calculate the dome zimuth, in fact the same source code. I wrote it so I can be certain of that. I’m not sure about SGP but have a recollection that Ken or Jared may have consulted me about this and I would have pointed them to the open source ASCOM code for this.
I’m confident that the algorithim is correct. I went to a considerable amount of trouble to get it right. Also many users are using it without problems.
What could be happening?
The first thing to check is that the dome is actually pointing in the direction it says it is and that it does so consistently.
Then is the mount type being reported correctly? LX200 fork mounts can be mounted Alt Azimuth or polar, on a wedge. This will make a difference and I’m not sure if the LX200 driver handles this.
Otherwise the best option is to look at what results you get and think about how changing things will affect it. There are directions where it should be clear what parameter affects things most, for example if the scope is looking at the Southern horizon the dome azimuth should be 180 and for a fork mount the only thing that affects this will be the mount offset in the East/West direction.
Looking at the East or West horizon the direction is mostly affected by the North/South offset.
The GEM offset must be zero of course.
There’s really nothing more that we can do remotely, after all you haven’t told us much, just that it doesn’t work. I’m sure that if you work it out methodically you will get it sorted.
Thank you so much for replying, Chris. It is very helpful to know that the algorithms are the same.
You make a good point that the LX200 fork mount can be mounted either in Alt/Az or polar mode. When you ask is the mount type being reported correctly, how do I find out? A search of the SGP log file does find the word “Equatorial” as in “Telescope equatorial system is JNOW…”. But, that is the only mention.
The calculations for dome position must assume one way of mounting or the other. In the ASCOM Meade Driver Setup there is a checkbox for GEM mounting but not Equatorial. So, does the ASCOM Meade driver assume Equatorial? I have always used the software with the scope mounted on a wedge, and it has always just worked. So, I never really thought about what the software assumes until now. I know the Simulator does have a checkbox for Equatorial and a checkbox for GEM.
I don’t know if it matters, but the LesveDomeNet Dome Setup window has fields for dome dimensions and I entered those as metric measures (cm.) because that was how it was done in the LesveDomeNet Help file. I entered the dome dimensions in POTH etc. in inches just as I did in MaxIm DL. The SGP Help file says the units don’t matter as long as they are consistent. Again, that has always worked so I never thought any more about it.
As this point I think I will try to experiment with the slaving parameters just as you describe – adjusting the mount offsets in POTH etc. and see if I can get the dome to align with the scope in different positions. I understand the effects of East/West and North/South offsets. What is the effect of Up/Down offsets?
If I can get the dome to slave, then I will move on to testing other parts of my setup in SGP.
Thank you for your help.
Manning
Manning,
Can you post the values from Maxim as well?
Chris, yes, the slaving code in SGP is based on the ASCOM math. Because I’m
not that good at trig.
Thanks,
Jared Wellman
– Co-Founder and Developer
– www.mainsequencesoftware.com
There’s an ASCOM property AlignmentMode which can be AltAz, Equatorial or GEM. Your system is Equatorial.
I have had nothing to do with any of the Meade drivers and don’t know which one you are using but it’s possible that setting it to GEM might help because this is definitely an equatorial mount. The difference between Equatorial and GEM is that GEM also has to manage the pointing state, AKA PierSide. You don’t want that.
Are there any contact details for the driver author?
Jared, yes, I got screen captures of the MaxIm DL slaving parameters. I’ll send those to you tomorrow.
I spent a couple of hours this afternoon trying to adjust the slaving parameters to get a better result. I began in MaxIm DL so that I had a baseline for how changes in the slaving parameters would affect the slaving result. Based on those tests, I then switched to ASCOM Dome Control and applied the same slaving parameters which are: Radius 47.6"; E 0"; N 10", H 14".
These are the results of the first test:
Test 1:
Connect Scope and Dome in ADC. (Dome is slaved.)
a) Scope reports at 181*. Dome reports at 182*. Dome OK.
b) Move Scope 5* N; 15* E.
Dome moves; then moves again. Dome OK.
Scope reports 166* Az; Dome reports 165*
c) Move Scope 5* N; 15* E
Dome moves; then moves again. Dome OK. (10 second update time?)
Scope reports 150*; Dome reports 146*.
d) Move Scope 15* N; 15* E. Dome OK.
Scope reports 143dome reports 137.
[Note: perhaps increasing N offset a bit may be beneficial.]
e) Move Scope 15* N; 15* E. Dome OK.
f) Move Scope 15* N. Dome OK.
Scope reports 106* Az; 43* El.; Dome reports 93* Az.
When I say “Dome OK”, I mean the telescope is nicely looking through the dome slit. As you can imagine, I was quite encouraged at this point. Unfortunately things went downhill from there. I also tried POTH and results continued to worsen.
I will try again tomorrow and hopefully be able to make further progress.
Chris, I noticed that in POTH all the slaving parameters are in millimeters except radius which is in meters. Is that really true? (Recall I am using LesveDomeNet for the Dome automation software.) I used inches for all slaving parameters in ASCOM Dome Control and, at least initially, it seemed to work fine. From remarks you have made previously the code should be the same between them both, but I was worried about what units of measure I should use in POTH. (Again, SGP says the slaving units of measure don’t matter as long as they are consistent.)
Regarding which Meade driver I am using: I am using the ASCOM Meade LX200 Classic and Autostar I driver which I have used without problems for several years.
Thank you both for your help.
Manning
I’ve had a look at the source for that driver and it implements AlignmentMode by reading it from the mount using the “GW” command. That should mean that it’s correct.
One thing to bear in mind is that this driver is very old, it was originally written in 2000 and was last touched in 2008, 10 years ago. It’s written using VB6 and is not multitasking.
Yes, POTH uses metres for the dome radius and mm for the other measures. Internally the dome radius is multiplied by 1000.
Thank you, Chris, for looking at the driver code. That is reassuring to hear that the ASCOM Meade Classic telescope driver is reading the AlignmentMode from the mount, and, I presume passing it on to SGP, ASCOM Dome Control, and POTH. That is one less thing for me to worry about.
You mention that the driver is not multitasking. I am sorry, but I don’t really know the significance of that. Is that important in the context of SGP? What does it mean for SGP operation? Does it mean it will sometimes work and sometimes not?
Thank you for your help.
Manning
This afternoon I spent another couple of hours using ASCOM Dome Control, adjusting slaving parameters, and running tests by moving the scope to various pointing positions and noting how the dome aligned. The parameters I used were E = -1.5; N = 12; H = 14; and R = 47.6.
I moved the scope to about 17 different positions and ASCOM Dome Control slaved the Dome satisfactorily to all of them.
Based on those results, I spent about 3 hours this evening attempting to use SGP with the same parameters. The results were often unpredictable and wrong. At first I selected my actual camera and filter wheel, but later I just used simulators for everything except the telescope and the dome.
I noticed that SGP did not allow me to use a decimal offset for E so I tried both -1 and -2.
For most of my tests I used the Moon by manually entering the RA & Dec.
It appears that even though I have the option selected to slew upon sequence start, the telescope would not slew when I ran the sequence. If I clicked resume the sequence, then the scope would move. Also, when the scope was going to the Moon, the dome did not move. To avoid running into shutter cables I aborted the slew. When the dome did move, it moved too far. I resumed the scope move and the dome moved about 90* too far CCW. The Dome reported 73*, but the actual position was closer to 0*.
When I parked the scope, the dome waited until the scope was parked, then the dome aligned to the scope. When I parked the Dome, It did not park. It ended up about 45* short in the CW direction. The Dome reported the target as 176* and Dome azimuth as 228*, but that was not correct.
I attempted another sequence run to the Moon, but this time the Dome rotated about 90* too far CCW.
I defined a new target and entered the coordinates manually. The dome rotated with the scope and initially seemed ok. Then the dome backed up (CCW). Then, the dome rotated forward again but overshot the scope by about 15*. When I parked the scope, the Dome which was still slaved moved to a point about 15* CW of the scope.
Thus, even though I thought I had a set of slaving parameters that would work in SGP, clearly there are other unresolved problems.
I don’t know how to proceed. Any help is most welcome.
Thanks,
Manning
Jared and Chris,
I have found a thread from June-2017 that seems to fit very well with the dome behavior I experienced last night. The thread category is Sequence Generator and the thread title is “Erratic Behavior between Scope and Dome”.
The thread seems to end with no resolution, but on the LesveDomeNet forum there is additional information that versions up to 2.6.0.20 seem to work more consistently. Later versions including 2.6.0.25, the one I am using, do not.
Chris stated in one post on the SGP Forum, “Looks like timing issues in SGP. There seems to be a place where SGP is reporting that the dome is synced before the move command has been sent.”
Has this been fixed?
Specifically, do any of the 3.0 beta versions fix this problem?
The earliest version I found on the Downloads page is 2.6.0.21, which from the LesveDomeNet thread, appears to be one of the problematic versions. Is 2.6.0.20 available?
Thanks,
Manning
Hi Manning, the post you referred to was mine.
Once I got past 2.6.0.20 my system began losing coordination between the scope and dome.
It’s a bit difficult to remember each behavior problem, but I believe the following were prevalent.
a) The automation did not always verify the dome had completed its slew to target before imaging began.
b) Pier flip often resulted in the dome hunting for the correct “flipped” location, with the same results as in example “a”.
Before and thru 2.6.0.20, I do not recall those issues being a problem. And SGPro was setup with the Observatory Slaving and Slave Settings.
Since my OBS is readily accessible I got more conservative and reverted back to using ASCOM Dome Control.
- In ASCOM Dome Control I use LesvedomeNet for the dome driver and POTH for the Scope. POTH then points to the Celestron driver.
- In SGPro Equipment (v2.6.0.24) I select POTH for the scope and nothing for the dome.
- I now slew the scope to target and allow the dome to follow and arrive, before starting the sequence.
Since doing the above, the dome has not hunted for position after the pier flip, nor been late for imaging.
A bit cobby, but it works.
Mark
Hi Mark,
Thank you for replying. Yes, the imaging didn’t seem to be happening when it should for me either, but I haven’t worried about that just yet because unless and until I can get the dome to slave correctly the imaging problem hardly matters.
If I understand your current arrangement, you use SGP to connect to POTH for the telescope and connect POTH to your telescope driver. Then, you use ASCOM Dome Control to connect to LesveDomeNet and the telescope via POTH, and you don’t tell SGP anything about the dome. Is that right? Before running the SGP sequence, you start ASCOM Dome Control, check the Slave Dome to Scope box, and then just leave ASCOM Dome Control running. Have I understood your approach?
Like you, my observatory is not far from my house, so I don’t have to completely automate everything. I like your approach if I have understood it, because it completely avoids the dome slaving issue in SGP. I don’t know what other problems yet lie ahead, but at least this seems to move me forward in the process of understanding how to use SGP.
I am using MaxPoint to connect to the telescope driver, but like POTH, MaxPoint is a hub so both ASCOM Dome Control and SGP can connect to the telescope through it.
I have tried my understanding of your arrangement in simulators just now, and it seems to work. Maybe tomorrow I can try it with real equipment in the observatory and see how that goes.
Thank you!!
Manning
Hi Manning,
Yes, that appears to be a fair summary.
I wandered over to the Lesvedome forum this morning and saw your comments there also. Pierre had advised me early on to use POTH as it seems to do a better job of taming communications.
It would be nice to get back to “full automation” with SGPro, but for now my work-around serves the purpose.
Good luck with yours and let us know if you find a better path…
Mark
I thought we had most of these odd slaving issues resolved but apparently not. I’ll take a look and see what is happening.
Does the dome eventually go to the right position after a slew (may take a minute or more depending on your slaving period)?
Thanks,
Jared