SX camera problem, super dangerous loop

I can also do some tests - but note that I did test both my h9 and h9c for the sx-ascom version five years ago to help support the project - though I never intended to use it because the apps I had purchased and the code I had written used the drivers directly. I recently had a night with good seeing and I wanted to take advantage of the high frame rate of the small and shutterless h9 camera vs. my much slower atik. Everything seemed fine in all the preparation until I actually started the sequence - at which point it kept failing.

The next day I replaced the h9 with the atik so I can’t do testing without some effort - but I can if need be. But given the value of interline sx cameras for high frame rate work with low latency, which is important in many applications, I would prefer to have the imaging app work directly with the driver.

So I will watch for updates on this issue and may be able to provide more info - but it seems like others will be able to contribute logs.

Frank

If possible, try to test with two different versions of SX direct drivers:

Latest version: 1.3.2.1
Previous version: 1.2.0.1

I own Lodestar and Superstar and I found version 1.2.0.1 to be more stable because it has not cause any disconnects like it did with version 1.3.2.1.

It’s my understanding that SX direct drivers must work with ASCOM driver.

Peter

I did this test with the HX35 and was unable to replicate. I used 1x1 binning, 2x2 binning, 1,2,3,5sec exposures, stopped during exposure, and stopped during downloading but was unable to replicate this problem. Do you still want to see the logs?

Okay, I finally got the error to happen again. The logs are here:

https://dl.dropboxusercontent.com/u/58468743/Logs%202015-06-28.zip

The error happens at 10:27:12. This time I didn’t press any buttons that I know of, I just went away for a few seconds while it was in frame and focus mode in SGP. When I checked again, SGP was reporting “Error capturing during frame and focus.” And the frame showed as still downloading. I had to restart SGP to clear it. Thanks for looking at this.

Kevin

Excellent. Thanks. I’ll forward these to Bret and we’ll see what we can find.

I just had this same error last night around 2:50AM. I’ve had it happen before as well. The SGP logs have the error: StartExposure called while in state cameraExposing. Below are my SGP and SX ASCOM Camera logs.

https://drive.google.com/file/d/0B1xqjOhpkEy3UHVPLVZrRExOUzg/view?usp=sharing

I posted this to the SX ASCOM Yahoo Groups and the developer Bret just responded that he reviewed the logs and understands what the issue is and he would be reaching out to the SGP folks. Hopefully a fix can be implemented soon whether it is in the SX ACOM driver or SGP. I will follow up with any updates I get.

I wonder if this is the same issue I had reported on the main SX yahoo group a little while ago. To me it appeared as though there was a communication problem when using two SX products (main camera and guide camera). Terry advised me to connect and start the Lodestar before connecting to the main camera. This seems to have worked around the hanging issue, but I’m very glad that Bret is looking into a real solution.

Interested Joel. I am using a QHY5II-L as my guide camera but I am using a SX filter wheel if that matters. I seem to run into the issue if I keep my laptop on and also don’t close SGP after my previous session and starting another session. If I close SGP and restart it I don’t recall having the issue but I haven’t done enough testing to say for sure. I do disconnect all my gear and bring the laptop inside but keep SGP open. The problem I usuaully have is the next session I conect everything and send SGP on it’s way. It will have no issue centering and getting things going but the first actual frame the timer in the status bar of SGP doesn’t start it will just stay at 1200sec on a 20 minute sub for instance. Usually I just stop and restart SGP and everything is good.

I have reviewed the logs and spoken with @bretm. This is my response to Bret:

I have finished analysis of the log you sent. It actually revealed one new bug where PHD2 reports star lost, but self recovers during the settling process. In this case SGPro would still try and recover the sequence. The source of this particular issue was indeed a timing issue. The camera, a shared resource, was not properly protected during asynchronous event handling. A lost guide star was detected… recovery, due to that state was set, the sequence thread sends the message to capture and then aborts before the image is started. This allowed the image to start despite being “aborted”, then the next exposure start is in error because the camera was left integrating in error.

So… a couple things:

  • These logs are from an unsupported (older) version of SGPro. SGPro 2.5 now uses a last call wins pattern. If any thread in SGPro asks for an exposure, there is an assumption that it is for a reason. Instead of finding every part of the code that could have a camera contention, the camera’s first action is to, if the state is not idle, abort the exposure and then take the new one. This particular issue should not show itself in SGPro 2.5.
  • This evening, I fixed a bug that could allow unnecessary recovery from a lost guide star that is no longer lost. I accomplished this by clearing the recovery state once a successful guider “settling” message is received.