GoTo, plate solve, start Live Stack issue

[ChrisR Oz]

Hi Robin,

After a long detour into observatory building and setting up a new telescope (more on that shortly ...), I am using my EdgeHD8 on a new mount and pier getting back into it all.

Not really sure whether to call this a bug, feature request or user error. But when I use the Goto Object feature (launched from mount panel "GoTo ...") it can often acquire many unnecessary long frames, perhaps 2 frames for the plate-solve and then a missed frame before the first Live Stack frame. With long exposures, this can mean many minutes lost.

The first issue for me is that the feature to "reduce exposure and increase gain" for the plate-solve step can disappear, which means full long exposures for the plate solve, often with a skipped frame first. I expect it's how/when I start the "Goto" that is the problem. I tend to just "Goto" when I want to move and let the auto saves just happen for the previous stack. What is the best way to flag that I have finished a stack (sometimes closing the Live Stack window can crash SharpCap)? Is this why it vetoes the high-gain/fast-exposure option?

I would suggest that the high-gain/fast-exposure option is still valid in any case, as the user has started a goto and plate-solve, etc. Why not change gain/exposure? There is probably some finesse needed in the order of events to return gain after the plate-solve, but leave fast exposure to start the stack (so that first frame skipped is short) and then set the new exposure immediately afterwards (while skipped frame is acquiring), so the first saved stacked frame is the correct exposure.

I expect that in Live mode and with recentring enabled, one skipped frame (to permit settling) prior to the first saved/stacked frame in the Live stack is unavoidable. But keeping the plate-solve fast, and having the first skipped frame short, would help greatly.

The automated Goto is a brilliant feature and the internal plate-solve, even at shorter exposure/higher gain, never fails for my 1.1 degree FOV. It makes locating targets and getting everything going a snap. But perhaps some details could be refined.

I have provided the log here: https://drive.google.com/file/d/1o__BQK ... drive_link. An example goto happened at 22:13. Using SC v 4.1.14091, a ZWO 2400MC Pro on a Win11 laptop. ZWO drivers updated last month.

Any tips if this is simply user error would be appreciated too.
Cheers, Chris.

[admin]

Hi Chris,

there are some conditions that control whether the 'reduce exposure' option appears, but they effectively come down to 'is it possible and is it worth doing?'. To be more precise, you see that option when all of the following are satisfied

* the current camera exposure is above 5s and
* the camera has a gain control that can be used to offset the loss of brightness from reducing exposure and
* the gain control is a numeric one, not a list of distinct options (the latter can apply to some ASCOM cameras) and
* the gain and exposure controls can both be set manually (this last is true for pretty much all cameras except some webcams)

In practice, using your ZWO cameras, the only condition likely to come into play is the first, so you will see the 'reduce exposure' option if the current exposure is above 5s and not see it if it is 5s or below. Since the 'reduced' exposure is 4s anyway, there should be no big difference in the lost exposure time if the camera exposure is less than 5s when performing the GOTO sequence.

That's how the code is supposed to work anyway, so really you shouldn't see any sort of case like the one you seem to encounter where it doesn't offer that option when currently capturing long exposure frames. It would be worth keeping an eye on things now that you know 'the rules' and do let me know if you catch it not behaving by the rules above. Another possibility I guess is that the exposure has been set below 5s at the start of the GOTO , so the option doesn't show as expected, but the camera is misbehaving somehow. If the ZWO camera does not send a frame at all when expected and is overdue by more than about 60s, SharpCap will try to reset the camera in the background and this could be happening I suppose.

I think it's probably a good idea to get to the bottom of what is going on in this situation before moving on to the other cases - the whole troubleshooting path basically diverges once we know if the problem is due to the camera dropping frames or something in SharpCap not doing what it should.

cheers,

Robin

[ChrisR Oz]

Hi Robin,

The exposure was 120s, which is why waiting for 3 frames before a stacked one becomes an issue. So, it seems to satisfy all requirements and yet the fast exposure/higher gain option was still missing.

Sometimes I also see an option to "Start a new live stack". But only sometimes. I would want this always present and true.

Given that the option to reduce exposure is active, and plate-solve/centre has completed, why not 'hold off' setting the exposure back until after the new Live Stack is enabled. Then, while the Live Stack is skipping the first (short) frame, it can immediately set the correct exposure, so that the next frame (first to stack) will be the correct exposure. This avoids the pain of watching the first frame at full exposure (which may have been underway when live stack was enabled) complete and not stack.

Cheers, Chris.

[Jean-Francois]

Hello Chris,

Do you have the camera in Still mode or in Live View ?
I know it could be a pain to wait a long exposure time and then remark that the image was not "full" captured.
And sometimes my QHY camera needs an additional frame.

In Still mode, SharpCap start a capture when it needs a new frame.
I switch in Still mode with exposure above 10 or 20 seconds (depending on my patience at that night )

Regards,
Jean-Francois

[admin]

Hi,

the option to start a new stack is another option that appears based on the current state of the application when you do the GOTO. That one should appear if live stacking is active when you run the GOTO movement, but not otherwise. Basically the idea is that it is seeing if you are working with live stacking and giving you the option to automate the change of target if you are. I feel that showing that if you are not already live stacking would be a bit weird...

I think we need to work out if/why you are not seeing the reduce exposure option if the exposure is over 5s - it's supposed to basically work as you suggest - not having long exposures during the goto operation and to go back to them once the live stacking restarts.

In the situation where you have been seeing the long exposure first frame lost, I'm wondering why - if the stack has been reset then the first frame is accepted into the stack no matter what - no filtering, no star detection, etc. This leaves me still wondering if the frames are being dropped at the camera rather than ignored by SharpCap at the live stacking stage.

cheers,

Robin

[ChrisR Oz]

Hi Robin,

I have not seen the lack of the fast exposure/high gain option the past few nights. I am wondering if I had a short exposure active (e.g. focus on bright star). I aim to set the normal long exposure back before the goto object. But perhaps I slipped up.

I understand that in Live Stack mode, a frame may be already acquiring when the sequence gets to "start a new stack". Hence, it will reject that first frame (e.g. may have started when recentre goto was still happening). Fair enough. But it would be nice to make it a shorter exposure that gets skipped. You switch exposure in many places (e.g. during dither and with the goto high gain/short exposure option). So why not just keep the short exposure active after the plate-solve, until immediately after the initiation of a new live stack (if it is selected)? Then the short frame gets skipped and the next one will be the longer exposure. Does that make sense?

Cheers, Chris.

[admin]

Hi Chris,

in my mind, the risk with doing that is that the last short frame will get completed when the live stack is active, and will therefore get used as the first frame in the stack, and that will cause problems for the rest of the lifetime of the stack since all the other frames will be long ones.

The way it is supposed to work now is that the exposure gets put back to full length first, which should then start a new long exposure frame. Then live stack is started, and the first long frame will arrive after live stack starts, and will get used as the first frame in the stack.

So, the current code is supposed to have this all sorted, but obviously something is going wrong if you have cases where that first long frame is being discarded. We need to catch it happening again so I can look at the log to see if I can work out why, because something is not behaving as it should, but I don't know what.

cheers,

Robin

[ChrisR Oz]

Hi Robin,

Yes, I can see that risk. But if the “short” exposure is still something like 8s, it is unlikely to be included before the exposure gets increased back to long exposure in the live stack. It would need to finish a fraction remaining, then a full fast exposure, all before the adjustment back to long exposure to be included.

I guess it depends on the behaviour of the ZWO driver in live stack mode. What happens when you tell it to switch from, say, 8s to 120s exposure? Does it queue that request until after it finishes its current 8s exposure, which could be a problem, or does it switch immediately and start the long exposure, which should work reliably?

Cheers, Chris.

[admin]

Hi Chris,

the exposure is reduced down to 4s, which is still in 'long exposure' territory as far as SharpCap is concerned. It depends a bit on the make of camera, but generally more than 2s counts as long exposure, and in that range, SharpCap tries to make sure that the existing frame is cancelled and a new one started if you change the exposure (at least if SharpCap is in 'Live Video' mode as opposed to 'Still Camera' mode).

How quickly the existing frame gets cancelled is variable, but I would say that typically it will be significantly less than 1s after the change of exposure that the old frame will be finished (some brands of camera finish the frame early and return the image, others just throw it away). At that point, the new full length frame should start.

I still am not seeing a reason why a first full length frame would be discarded given the current ordering of

* Movement steps finish
* Exposure increased
* Live stack started

The first long frame may start just before the live stack is re-activated, or maybe just after, but it's when it finishes that is important and that will be well after live stacking is set up and ready. It should then get added to the stack. I'm hoping that seeing a log of this actually happening will point out something that I have overlooked or a possibility that we have ignored - for instance if the first long frame is being lost by the camera driver/SDK sometimes, the sympoms would look very much like the first frame not being added to the stack, except that there would be no first long frame...

cheers,

Robin