SGP Conflict with LesveDome dome control

HI Group,

I did my maiden flight with SGP last night and ran into a bit of trouble. My dome control is handled by the Lesvedome software, and it communicates with my 12" Classic Meade through COM port 5, with a Keystone Serial to USB adapter.

I made a point to not communicate with the scope through SGP, since there was no need and I wanted to keep things simple.

However, within minutes of starting the sequence, my dome control became sluggish and quick working. I forced the software off and when I tried to reconnect, it said that COM5 was not available.

I saw this occur twice and can’t say the dome worked at all through the one hour session.

Any ideas on why SGP would take over the com port to the scope, and how I might correct it?

Thanks,

Mark

Hi,

I do also use Lesvedome but with NexRemote. I also let SGP handle the dome positioning. What are you using for dome control asides Lesvedome; ASCOM dome control or something?
Why not use SGP to take over control of your dome, it really works like a charm, just fill in your mount/dome measurements and let the magic happen :wink:

Best

Lex

Thanks Lex,

I just spent an hour playing with the system trying to duplicate its behavior from last night. All worked well, although I did not run PHD2 (daylight). I’ll try the entire group tonight and see what happens.

I know that PHD should not have any effect, just like (I believe) SGP should not.

It did occur to me that the RS232 connection at the scope panel may have been making intermittent contact, so we’ll watch that too.

If I go with SGP, I probably will eventually let it do the dome control. My Lesvedome software works hand-in-hand with ASCOM. It’s been operational for five years with no problems. But I can change if SGP shows to be superior.

Things I did like about SGP during last night’s run:

  1. Custom naming of image file.
  2. Frame and focus. This is the handiest of any that I’ve used.

Things that were a concern:

  1. Sequencer. But I hope to get smarter.
  2. Dither – I’ve not caught it red handed, but the Dither check mark seems to drop out regularly. The six images shot last night did not dither. I’ll watch this more closely tonight.
    Mark

Hi Mark,

SGP is really worth the step! Especially that you can automate your exposures as far as plate solving and recentering automatically the FOV to the desired position. This is why it is crucial for SGP to take over dome control IMO.
For sure, as for all Software, there is a learning curve that one has to overcome…

Best

Hi Lex,
Thanks for the encouragement. I was able to run SGP and Lesvedome concurrently last night without a hitch on the dome control side. So I believe at this point there is no conflict with the two softwares fighting over the com port.

I did have other problems, but I’ll start a new post on them.

I would appreciate more of your thoughts on using SGP as a dome control.
Currently, the Lesvedome software communicates with a Velleman card that sends signals to relays that tell the dome motor to stop, go forward or reverse. The system also gets feedback from a “home” switch telling it where the dome’s home position is. And there is a commutator wheel (mounted to the gear drive) that tells the system where the dome is at any given time.
If I were to use SGP I believe it would have to work through this same system. No?

Mark

AFAIK you have to connect through some sort of ASCOM driver, this provides the fundamental position and move control.

And also AFAIK SGP does not handle synchronising the dome position to the telescope position. This is handled by the ASCOM driver.

Most ASCOM dome drivers don’t provide synchronising mount and dome, they rely on a Hub such as POTH to do this. It’s provided as part of the ASCOM platform.

What this means is that in SGP you select POTH as the ASCOM driver for both the telescope and the dome. Then in the POTH setup you select and configure a telescope driver and a dome driver - in this case a Meade telescope and Lesve Dome.

SGP sends telescope commands as normal and they are passed through. It also sends dome commands but when it wants the dome to follow the telescope it sends the Sync command to the POTH dome driver and this handles checking where the telescope is and moving to dome to follow it.

Setting this up can be a bit challenging but if you already have this working it shopuld be the same for SGP.

Chris

Hi guys,
i am using the above mentioned setup with the Velleman VM110n board. Before SGP I used ASCOM dome control in combination with LesveDome Driver. SGP now combines all and works flawlessly! A positive side effect is that I now use Skysafari 4 pro and Wifiscope to handle scope control via WIFI, AWESOME stuff!!!

Lex,
You don’t need to use WiFi Scope if you’re running SGP…it’s built in. Just check the “Allow External Control of Telescope” on the Telescope Tab of the control panel to enable it. Do NOT run WiFi Scope when using this option…you will run into troubles.

SGP does in fact handle the synchronization between the dome and scope position. I personally have a dome and naturally I control it through SGP. You can set the parameters in the Slave Settings area under the Dome in the Other area of the Control Panel:
http://www.mainsequencesoftware.com/Content/SGPHelp/SlaveSettings.html

You can do this with POTH as well but you lose some functionality in SGG. This makes the assumption that you’re using the Dome without slaving it to your scope in SGP. Essentially if that “Slave to Telescope” option isn’t checked then SGP won’t close down your dome when the sequence ends or if it aborts before hand. If you prefer to use a 3rd party synchronization program (like POTH) you can get around this in SGP by telling it that your observatory is a RoR and it won’t attempt to rotate it to match your scope (it will rely on POTH for that). However since SGP is still “slaving” your dome to your mount it will attempt to close your dome when the mount parks if you select that option.

Hope that helps,
Jared

Just to add my two cents …
I did select Lesvedome for the observatory and then added two slave settings (dome diameter and allowable error in degrees). I checked slave to scope, and SGP took over control of the dome and appeared to respond properly to the scope movements. There are a lot of dome features that I am not presently using, however when I do, this looks like it will be interesting.

Mark

Jared,

Thanks; I saw that SGP listens on port but I did not think that this was Wifi Scope :wink:
Thanks for the info, I’ll try it ASAP…

Best