Once again. Dual Cameras?


At the risk of sounding like a broken record… Would you please consider dual imaging support…



I don’t pretend to know SGP internals but as a long time software developer, I can tell you that adding code to coordinate the activities of multiple cameras with a single instance of SGP will almost certainly require a major amount of work.



+1 from me

Charlie, yes not trivial but I think doable. In the past the developers have indicated that it would be done with two instances of SGP, a master and a slave. Some of the work has already been carried out but my guess is that with the recent update and a general move to consolidate and stabilise the application this has been pushed back. Even a basic implementation would be great to start with which could be improved on over time. Here is hoping!


As Chris mentioned - ASCOM limits one connection to a driver ID AFAIK. There might be a workaround. I use the Optec ASCOM server - I use it as a hub for my own ASCOM drivers, since it does not block any non-standard commands (unlike POTH). In this utility, there is a feature in that which allows for multiple device connections. I don’t use this feature but it may be a temporary solution using multiple instances of SGP. I think there is a time-limited trial download.


i propose again my idea of 6 months ago… Currently i use a dual rig with main scope at 1600mm and secondary at 400mm

A second camera (slave) could be added in a second instance in “slave mode”

Then with options there could be defined some conditions to have dithering based on exposure time. Condition must be that slave camera exposure is the same or less then master camera…for example:
Main camera exposure time: 10 minutes
Slave camera: 3 minutes

While the main camera is taking the 10minutes exposure the slave camera takes 3 exposures, and wait a minute…
When the main camera completes the exposure, sgp does dither, and begin again the cycle, 1x10minutes on main, 3x3minutes and 1min wait on slave, dither and so on…

This approach could be very interesting if exposure duration ratio on main/slave is 1:1 or multiples… but could work even if there are strange ratios… for example 10 minutes on main, 6 minutes on slave (but slave have to wait 4minutes)

For main camera everything stays the same as now because it’s the only camera that pilot phd and dither requests… It could be a different approach that doesn’t need to rethink o recode the way SGP works together with PHD on main camera…

Hope it helps


I think all of this is well known and previously discussed multiple times on this forum.

As far as the complexity, I do seem to recall that at least some of the coding for dual camera had already been done.


Once again, please consider a new feature to control an additional camera. There are many requests for bug fixing in some very particular cases. But the ability to use the SGPro for a second camera seems as an essential feature request.I think it is so essential that some people, me included, would pay extra to have it.


Indeed. This feature request has been out there for quite some time, a few years at least. Would really like to see it.


Id pay extra for it. Im currently running two Nikons on BYN with Dithering!! I want this on SGP which I own but cant use due to this missing feature. Unfortunately BYN does not have autofocusing which is why I need SGP or BYN to have it all. Both are great programs.


Once again, I agree and support.


Once again, checking back on whether there has been any progress on this feature. Was working around it by using a dual imaging setup with a large difference in image scale so that when I ran a small dither it didn’t make much difference on the system with the wider FOV. But I’m imaging now with a dual system with very similar image scales so I can’t dither one scope without it showing up in the other. Every time I process my images now I have to cope with frustration at the walking noise that I know would be eliminated if I was dithering. There are many who would like this feature (probably more than use some of the recent features implemented in the beta versions) and we have been asking for years. Any chance of it being implemented, or is my only recourse in the foreseeable future to switch to a control program like APT which has coordinated dithering (I’ve invested so much in SGP that I would lament this being my only option)?


In the end I’ve decided to just use a low-tech approach. Since the second setup is a CMOS camera I use shorter exposures (3min vs 5min on the CCD). So I’ve set up the dither on my main rig and I’ll just throw out the CMOS frames that happen during the dither. I’m experimenting with whether I can dither every few frames, and therefore throw out fewer CMOS subs, and get comparable benefits. I tried dithering every 2 frames and every 3 frames last night and need to check my CCD and CMOS stacks to see how that worked to reduce the walking noise. It appears last night that I didn’t get a dither event during an autofocus on the CMOS camera, as I would imagine that would throw off the focus. If this works then throwing out every 4th or 6th CMOS sub is a small price to pay to have dithering enabled. Would be nice if this was automated though…


Yes, I have had to resort to that as well. I hate to toss frames but until this long discussed, long requested, feature actually appears, we will have no choice. In my case I have found that maybe 10-20 percent of a full night’s imaging with the “slave” (not controlling dither) instance have to be tossed. At this point I have just given up as this has been requested for years now and has never shown up in even the most basic form.


CCDMan, could I ask, are you dithering every frame, or every 2 or 3 frames? What do you find is the maximum interval you can use while adequately reducing the fixed pattern noise and hot pixels?


I always dither every frame.

Note that the systems are an FSQ 106 N and Moravian 16200 for the primary controlling system and then an SBIG STT 8300 for the secondary system - this has a Canon 200 mm lens with an F5 aperture mask. I typically need to set the primary system to dither for 2-4 seconds to give enough dither for the shorter focal length.

Since the whole system is on a permanently mounted Paramount ME and therefore a good alignment and large model for pro-track to use, I image unguided so am using “dither by mount”.


This is actively being worked on. We hope to have a fairly bare bones multi camera support out in the Beta soon.



Super! With summer and clear weather coming, I am looking forward to this!

My feeling has always been that although there are other softwares that can (sorta) do multiple cameras, none I have seen is even close to SGP in the many, many, more important and basic features.

I had long ago decided that if it were between moving to something else that does (sorta) dual camera and staying with SGP w/o dual camera, I would far rather stay with SGP.

But BOTH SGP and dual camera is clearly the best of both worlds!


Just to temper expectations, this is going to be added but lightly supported and considered a “pro user” feature. It will be up to the user to “not shoot yourself in the foot.” For instance attempting to slew the scope or center the scope in the slave instances is a bad idea but we’re not going to prevent it at this time. So it’s going to be up to you to make sure you’re not doing anything “dumb” in the slave instances.

There are a TON of things that we should be disabling in the slave instance and we may very well do that later, but that is a massive hindrance to getting this out. This initial attempt is primarily a “coordinated dither” and will give us a spot to tweak things more. The “master” will always dither when it needs to and the slaves can image and wait for a dither event from the master. When they receive the dither they can then continue on. So the slaves should always be capturing shorter exposures than the master.

These things are up for change and we may allow the imaging on the master to wait on the slaves as well…but for the initial beta we are not.



That sounds just fine to me. Got to start somewhere and what you describe should work fine with a bit a careful use.


Great news! Exactly what i was hoping for. Thanks!