Resolved SBIGUDrv Tx Timeouts - Call for Beta Testers

Here is another TX Timeout captured.

Karen Collins (for Mark Manner)

 

Mark I agree with your assessment that it's much harder to duplicate the issue with this log version of software. I tried by collecting bias frames i set exposure time = 100ms (0.010) and exposure delay = 0 at 250 times and it never hung. I'm also using TSX Pro 10.5.0 Build 10229 on windows 10. Normally doing this it would hang after about the first 5 or 10 frames. I was shocked to see it complete 250 frames and not hang.

 

Oddly enough, my camera has not hung since I turned on logging, and I can get 1-3 hangs per night.

Regards
Martin

 

If you are not using a subframe, readout is probably so long, it will take forever to see the problem. I'd set a small subframe when the debug logs are active to better simulate normal operation.

 

Thank you. I'll try anything newly available on Tuesday evening.

 

So last night I turned logging off and the damn camera hung twice whereas the previous two nights with logging on, the camera did not hang but of course ran slowly, especially the AO.

Mark suggested using a sub-frame but from what I have read, and experienced, the camera hangs during focus runs for a lot of folk, so the sub-frame idea is not playing a part here while the camera is focussing.

cheers
Martin

 

Yes Adam, that would certainly explain why it is not occuring with logging turned on. Sounds like you are homing in on the issue. Cant wait to see this go away, especially as I am very keen to purchase the 16200 but very hesitant right now.

keep at it mate.

cheers
Martin

 

If I don't have something to test Thursday evening, I will probably loose my ability to reproduce the problem for a while. I have a critical observation Friday night, so I have to do something to get rid of this problem Thursday evening (not sure what yet). Once this problem goes away, I'm not sure how to make it start happening again on demand, but it will be back sooner or later. I hope I can test something Thursday evening.

 

The problem was even more difficult to reproduce using the above new version of the driver (v4.96 build 1), but I did capture two events. Also, with this version of the driver, the error given is not "TX Timeout", but is "unknown OS Error". I don't recall an error message presented to me by TSX for the first instance of the error near the top of the log file (but it apparently happened right when I started TSX), but for the one near the bottom of the file, TSX produced an error message "SBIG Driver: Operating system error. Error = 30032". To find the corresponding errors in the attached log file, search for "OS Error". The setup here is similar to what I described above for my last test session, except in this case when I set TSX to run continuous focus exposures, I had the exposure time set to 1.0 sec, no delay between exposures (as before), and used a subframe size of 8x8 pixels (to speed up the readout part of the cycle). I have again cut out a huge part of the file between the first occurrence and the second occurrence, which occurred ~50 minutes later. I still have the full ~44 MB file, if the attached short version is not all that you need.

With the above driver and setup, if the logs are NOT enabled, the "unknown OS Error" occurs right away (within the first minute).

If you have a version of an attempted fix that I can try tomorrow evening, it would be greatly appreciated since I haven't yet found a way to stop the problem from happening too many times within one full night of continuous exposures. When an error occurs, the TSX exposure sequence is aborted, and I get no more data until I notice the error message and restart the sequence. Even then, I still loose an exposure which is sometimes 3 minutes of data.

Karen (for Mark Manner)

 

Here is a log with two TX Errors captured (the different error seen in the last build is gone now). This is from version 4.96 build 2. This version seems to have much less impact on the driver performance, so the error happens more readily.

Karen

 

Adam

Some additional info for you. Without exception, in the past, I have always had a Tx or RX timeout error with the camera hanging and requiring a power cycle to recover. My automation software also hung (CCDAP). Now, no TX or Rx errors are generated, but CCDAP generates (most of the time) a 'Take image failed' SMS. When I terminate CCDAP through Taskmgr, it also kills The SKyX. Consequently, when I restart TSX, I can reconnect to the camera without a power cycle. From my end, what has changed is the install of the initial driver you provided plus My TSX was about 3 'daily builds' out of date. The end result remains the same, but it appears the TX or RX timeout errors are not being generated before CCDAP/TSX crashes.

Cheers
Martin

 

Hi Adam,
I tested the build 3 driver tonight. I will first say that the primary problem went away Sunday evening as mysteriously as it showed up a week or two ago. That said, I ran two tests before observing this evening using the new build 3 driver. First, I disabled all logging and hammered the interface with exposure requests using the focus module of TSX. I used 8x8 binning and 0.1 sec exposures. After running for a few minutes, TSX displayed the usual TX timeout error, but the camera and TSX were lock-up hard. I had to kill TSX and and cycle power on the camera to regain control. I have seen this problem in the past too, as mentioned above by Martin, but it is less frequent than the version where I can close the error message and restart exposures with no problem. Next, I turned on logging and ran the same test above for 30 minutes, but had no failure. At that time, I had to start an observation, so I turned logging back off and started up my observations as usual. The observations executed without error tonight throughout the 6 hour time-series of ~2 minutes exposures.

I'll turn logging back on and run more testing tomorrow for a longer period of time to try to cause (and capture) either the lock-up or non-lockup version of the TX timeout error.

Thanks for your work on this problem,

Karen

 

Hi Adam,

It took a while with the logs enabled, but here is a TX Timeout error using build 3. I used the same process: 0.1 sec focus exposures with an 8x8 subframe.

Karen