Dual rig and dither

I am just considering putting a dual rig together, is support for dithering two cameras likely to happen? Many thanks, Matt.

I understand this is on the list for 2.5 but I have not seen any reference to it in the betas as yet. I already have a multi-scope, multi-camera setup so it is high on my list as well.

We have made fairly good progress on this feature. Right now, we are just battling the code trying to find the best way to handle sequence recovery with multiple SGPro instances… the basic stuff like dither was pretty easy and was done a while ago.

At least the first implementation of this feature will likely only allow the “master” instance of SGPro to invoke sequence recovery mode. We are trying to wire everything up so that one instance can tell the others to abort their exposures, or, in some cases, wait for their exposures to finish and then proceed with recovery. It is trickier than we thought…

We also have other considerations to think about before release. What do we do about guider pausing events? How could they affect the other cameras? How do we handle the user feedback associated with opening sequences in SGPro “slaves” when that sequence contains unsupported features (like control of auto guider, plate solvers, connections to mounts, etc)

2 Likes

Many thanks for the reply, it’s one of life’s cruelties that one thing invariably leads to another.

Yes, a saying I apply often: “I’ve never seen a complex problem, that when analyzed in great detail, did not become even more complex”. Seems to apply here :smile:

Indeed, reminds me of my favorite quote:

“For every complex problem there is an answer that is clear, simple, and wrong.”

H.L. Menken

1 Like

It’s all true… I didn’t even mention everything we are looking at to try and pull this off. One of the more difficult parts is / will be target synchronization. When the master is on a particular target, how do we:

  1. Force the slaved instance(s) to also have that target
  2. Force the slaves onto the new target
  3. Allow for proper rotation of slaved cameras during a “synchronized” target switch.

Furthermore, we need to consider how these “slave sequences” will be saved. Are they stand alone? Are they permanently attached to the master sequence so we can properly enforce target synchronization… When you open a master sequence with slave data, does it automatically open the other SGPro instances with their sequences? Probably… All this and more.

The point being, this is a complex feature… it will take time to get out. When it comes out, it will have some issues. We can get it working and get it stabilized, but with general support issues, we cannot give an ETA right now.

Ken and Jared,

At one point it was discussed whether the slave control might be via a separate module, like the Mosaic wizard. In some ways that seems easier since the slave control would be a stripped down SGP where target acquisition and sequencing is controlled by the master. Was that idea unworkable? Seems like most of your list is about how to prevent SGP from accessing features while in slave mode. Just wondered if the other approach would be less complicated? Again, I expect folks like me who want this feature would be willing to pay for it as an add-on module.
…Keith

This is true. It will likely be presented this way…

Not quite sure I follow. I see the “addon” functionality just as complex. I have a fear that presenting an addon with less functionality (dither only?) will be equivalent to “use at your own risk”. This, unfortunately, we do not have time to support (but if we charge for it we must). It is rife with pitfalls and other ways in which to ruin sequences. Or maybe I am misunderstanding you completely…

I see your point. My own lack of understanding of the programming complexity no doubt.
…Keith

Dunno if I had mentioned this but there is a piece of SW that you can buy that allows two instances of MaxIm to run two cameras on the same mount. I tried it and was not all that happy with it - mainly because it requires you to use MaxIm :wink:

I am sure that having it done by the same people that do the main imaging program will be much better as they have control of all the variables.

Worth waiting for, hopefully ready to try by summer when my good weather starts…

May be it could be an idea for future versions…

A second camera (slave) could be added directly in main SGP interface

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…

Hope it helps

Andrea

Great idea. This
would almost double the exposure time.

Hello,

any progress about dual rig? as Andrea_Tosatto suggested, it should be less complicate to make as a first version to implement it to try.

Excellent question. I am still on 2.X and it is working fine for me. Right now 3.X has nothing I need so I do not plan to upgrade until it does. The biggest thing on the “really need that” list for me has been and continues to be dual camera support.

If you look at the feature requests poll from a few years back, this was ranked as number 3.

Number 1 and 2 have already been implemented.

Significant?