2.5.0.10 and couple of issues

Sequence Generator
#1

Hi guys, I would like to point to couple of issues I had with 2.5.0.10.
I run Win7 x64 with Ascom 6.2 platform.
I see some guys report crash on download, mine don’t crash, but start to experience a hang for unreasonable amount of time while downloading. And this happens on very first frame, not always thou. If I just wait, (too long) the frame get downloaded eventually and all seems running smooth after. Not really sure what happens, just letting you know, in 2.4. that never happened.

I had sequence running with 5 events. First three were Ha, Green, Blue in that order. When first event almost finished I decided to switch places of event 3 and event 2, so instead of G it would start B. I left the pc and came back after half an hour and noticed that it continued to shoot G ignoring that I switched the order of events. Right clicked on setting of B event and clicked “Set as current event”. Waited that it finished the frame in hope it will switch to event B, but it didn’t.
Then I decided to abort the sequence and let current frame to finish, but after frame got downloaded, SGP didn’t stopped and Abort Sequence button stayed grayed out, couldn’t do anything and couldn’t stop the sequence. SGP continued to dither and shoot as if I never asked it to stop. To stop the sequence I disabled all next events and current one set to 1 repeat. Only then, when frame were finished, sequence stopped. I put back everything as planned again, run the sequence and it performed very well until morning.
My log files is here: https://www.dropbox.com/s/ve3z0gna2aw90g6/sg_logfile_20160212181115.txt?dl=0
maybe you can spot something unnusual that went wrong and why I couldn’t stop the sequence?
Thank you!
Sergio

#2

Ok, I had another issue the same night, there were sudden dither commands from SGP during the night even after settling is done and while exposing. At some point it was dither after dither, after dither…I wasn’t sure if it was SGP related and thought my mount had some mechanical problems, so spoke with Andy Galasso first, he confirmed that PHD did received three dither commands in a row in example of around 01 oclock:

01:03:02.536 00.100 840 evsrv: cli 007CCD18 request: {“method”:“dither”,“params”:[3,false,{“pixels”:0.5,“time”:3,“timeout”:300}],“id”:1002}

01:05:33.253 00.101 840 evsrv: cli 007CCD18 request: {“method”:“dither”,“params”:[3,false,{“pixels”:0.5,“time”:3,“timeout”:300}],“id”:1002}
01:11:18.261 00.101 840 evsrv: cli 007CCD18 request: {“method”:“dither”,“params”:[3,false,{“pixels”:0.5,“time”:3,“timeout”:300}],“id”:1002}

He also asked to mention that in my log files there are many errors of this type:
[13/02/2016 01:11:23] [DEBUG] [PHD2 Listener Thread] Error received from RPC: Cannot initiate guide while dither is in progress

Looks like SGP is not waiting for dither to settle before trying to start guiding.
I uploaded all logs here:

Thanks.

#3

Not sure. Your camera uses the same ASCOM code every other ASCOM uses and we don’t see this behavior elsewhere (that I am aware of). Camera logs might be helpful troubleshooting this.

Reordering of events is not supported while a sequence is in progress. There was a bug that appeared to allow this (it didn’t). This issue has been corrected and the re-ordering buttons are now properly disabled.

This was a (rare) bug. It has been fixed.

Well, that may not be entirely accurate, the dither commands were sent 2.5 minutes apart and then about 6 minutes apart. We will take care of most of this when we finish the “smart dithering” code. The second dither was sent because the first exposure failed and started over (guider precision error). The third dither should be expected since you were taking 5 minute exposures so I’m not sure why there is confusion there.

We do wait.

[13/02/2016 01:06:08] [DEBUG] [Sequence Thread] SGPro settle criteria have been met, but the guider reports it is not ready to resume, waiting…

The only thing odd here is that we send a guide command even when it is seemingly not needed (shared code issues). This should be fairly harmless.

#4

Ken, as I understand, when the exposure failed due to a guider error, it should simply restart the frame without dithering and I saw this happen during the night couple of times with wind gusts.

Looking at my PHD log again I can see dither command at 01:03, then at 01:05.
Then at 01:16 and 01:18 and 01:21. Those are in less than 5 minutes apart. I wonder why SGP sent all those dithers? What really happened?

#5

Every time, the dither occurred within a 5 minute period it was because your guider crossed a user defined error threshold and restarted the frame. Again, when we sit down and make dither smarter this won’t be an issue… right now it is how all light frames start. There is already another active thread about this somewhere…

[13/02/2016 01:18:11] [DEBUG] [Auto Guider Error Thread] Frame restart: distance was 1.3 pixels

#6

I completely forgot that you moved dithering to beginning of the frame in 2.5.0…that explains it all.
Thank you, Ken. Will wait for smart dither :slight_smile:

#7

Right… moving dither to a new location was just step 1. We will clean this up in 2.5, right now it’s a little annoying, but does not break sequences.

#8

Was a fix to this ever implemented? I have a lot of wind and whenever the guiding error passes the threshold, it does a dither - in my case tons of them. I know, I should just move my observatory instead but I can’t right now and I don’t want to accept crappy images.

Kent