That's a cool idea, I hadn't thought of that for the "dome" camera (that's living in a dome) - I would only ask that I be able to keep the images/recordings as archives - I can imagine going back in the morning and seeing a knot of cables!

On a similar note, I am guessing that I would able to integrate sensors for things like "mount exceeded slew" ie: camera hits a contact switch on the base of the mount causing an "Abort" command to be sent, shut down session etc.

So many possibilities with this amazing platform, I don't understand why ASCOM is even a thing still, astro should be platform independent!

Thanks Jasem! I've seen those little buttons in the control panel but always been afraid to press "go" on observing nights just in case i blow something up and then promptly forget about them during the daylight! I'll try it out, although I don't have much luck with the ASI183MC Pro and streaming from the Capture module, it never seems to give me anything but black screens during the night - again something I've been meaning to play with when the clouds eventually (falls to knees and adopts whatever religion that guarantees weather wishes) move on (they do eventually move on right?).

Some many possibilities with this platform it's just incredible. Now that I've got my RPi 4, looking forward to trying to hack siril into the workflow and doing a "average last 4 captured frames" EAA hack so that my partner can finally understand what all the fiddling is about while I am doing it - I am sure she's convinced I just download a good looking image from the internet and the telescope is just an excuse to get away from her for a few hours (it's not, really, I swear

I had a quick test with a simple webcam and while Ekos picked up teh camera itself easily it wasn't so happy streaming for more than about 30 seconds before the system started to behave erratically and I gave up until I have more time to experiment.

If windowing management in kStars and Ekos was able to manage tiles tied to particular windows/portals we could put whatever data we wanted in there eg: cameras for situations awareness, weather radars, etc

I might have to dig out my compiler and stop talking and start coding!

I want to take this dual imaging route too. Doubling my imaging time has no price


My 2 grains of salt:

I think KISS principle should be applied here. One camera+ekos instance is the master with responsibility for slewing, aligning, guiding and dithering.
All other cameras+ekos instances should be slaves and have only responsibility of focusing and imaging.
Maybe a "readonly" connection to guiding, that way it can stop imaging if guiding is paused or dithering and then restart slave sequences. Perhaps a simple deviation threshold would suffice. Anyways even if the slaves are not stopped it is only a matter of loosing a few frames and having to sort them in post.

For multiple targets I would consider using alignment module on the slaves, using the slave camera itself with a simulator telescope. That would delay next slave sequence startup. Hopefully this can be achieved only by tweaking settings and alignment retries.


I think this approach is not perfect, it is tedious, requires scheduling targets at given time on all instances, probably PHD2 would be required for guiding as it already provides a server API.
But I believe is doable with current codebase. Also it is perfectible with some small developments not requiring a major architecture revamp.


I'll be looking into this in the following months, still a lot to figure out, hopefully with some success I can then share here.

K.I.S.S! Keep it Simple s. I have successfully connected camera 3 in AUX using the rename driver method and can at will select master or slave camera to do a sequence of SUBS. But what I really want is to fire the master and slave in true parallell. My example: The master is a Sony a7 on the main scope. The slave is a Sony a5000 on a 500mm mirror tele (f4 with focal reducer). I want the slave to shoot a supplement of subs in RED -> NEAR IR.

To keep it simple you may make it to be a true slave relation and to fire at same time.
A SIMPLE SLAVE! This will make twice the integration time or half the session time compared to do one and then the other sequence!

Just command expose! to master and slave1, slave2,..., and then receive the extra subs, possibly with same prefix and store in a sub directory under "Light" named Slave1, Slave2... waiting for last to finish.

That might be doable?
PLEASE!