STXL11002+Self Guide Filter wheel + AOX: Camera error 30007 & AOX no movement on 1st power up

STXL11002+Self Guide Filter wheel + AOX: Camera error 30007 & AOX no movement on 1st power up

Hello,

This is a early STXL11002 with self guide filter wheel and AOX. I have two issues to discuss.

Issue 1. Camera Stops Responding - "SBIG driver: Transmission timeout. Error=30007"
Over the years the camera has suffered from a error 30007, driver unresponsive? At first, the issue would occur perhaps once every 5 or so sessions, but has steadily become more regular.

I have just built a new fanless low powered PC for remote observatory deployment. Newly installed Windows 7 Pro, TheSkyX using ASCOM SBIG driver [from latest update], Samsung SSD, 8GB ram. The executive program is CCDAP5, sub programs being Focusmax4, Optec rotator, Astrophysics mount driver with APCC, Planewave focuser controller via ASCOM. RAM usage is about 1.6 to 2.1GB under full automation. The camera is connected by USB via a Mount Hub Pro [only the USB connection, not power], with power being supplied directly from a 12v source [110amp AGM, 50amp cable, and fused @15amps]. I have also tried running the camera with a direct USB connection, but still experienced the same issue. On the cameras first return to SBIG, I did not received back the original HDMI cable, so I have purchased a good quality 50cm replacement. I have not tried another cable.

More recently on this new computer, the camera has failed every session [that is 3 session so far - will try tonight again], all at random times, in the same sequence, I'm guessing about 1-3 hours into the nights session. The laptop I normally use is a Windows 7 Pro i7 gaming system, and that is the system I have historically used and first seeing the issue. Same problem being reported. When I cycle the camera OFF/ON, and disconnect and reconnect it in TheSkyX, it then works again.

The circumstance is first noticed when the guider is reacquiring a guide star following the download of the main CCD image, and the process stops at the downloading stage of the guiders first star acquisition image. Prior to this, the last action of the camera was the successful download of its image. From what I can see from the last results, this image from the main CCD is a bad image with tracking lost [badly elongated stars typically]. So I am wondering if communication is lost already in the previous images acquisition, with the guider already becoming unresponsive then. Unfortunately, there is no regularity for when this fault occurs, so spotting happen is very difficult.

Testing is very weather dependant, and we have few clear nights to test, but tonight I will try again.

Issue 2. AOX doesn't always work on first power up
I have also notice now the AOX is not always starting correctly on first power up. If I exercise the AOX from the setup screen of TheSkyX autoguider page, the AOX reports movement, however no noise comes from the AOX [meaning no movement]. If I try to calibrate, the AOX doesnt move the star and fails the movement tests of the calibration routine. The way to fix this is to disconnect the camera from TheSkyX and re-cycle the power to the camera. For a manual user, this may not be such a problem, and re-cycle of the cameras power to wake up the AOX, but, in a remote circumstance, and under a automated session, this will see the session's data being lost as the auto-guiding routine continues with only bumps to the mount. No error gets reported.

Conclusion
What should be done for these two cases? I will try the system again tonight, and will monitor is the same happens again for issue 1 above. About the AOX, this issue is extremely random.

Regards

Steve

 

One thing to be aware of is that TSX is very hard on the camera driver. I've recorded it sending 10,000 calls a second to the CameraState ASCOM property to check for the end of an exposure. This has all sorts of consequences:

• If there's any sort of problem in the ASCOM driver, or any low level components it uses, this is very likely to find it.
• This uses a full core of the PC, doing nothing but this - and as a consequence getting hot.
• If this involves the low level drivers, the USB interface, or the camera hardware then there could be problems. For example queues may be filling up with requests, having some discarded and so not being serviced.

SB say this is "by design".

I'm going to be adding throttling in the camera drivers I'm involved in so that calls to the low level drivers and hardware are only done at a frequency of my choosing, in between these calls the last result will be returned.

Chris

 

Thank you Doug and Chris for your replies, sorry I did not answer earlier as I thought I had email notifications on [but I did not].

Doug, I am wondering about updating the firmware as you suggested? Does this mean updating the SBIG drivers [through the checker]? I will look to the SBIG support area to see...

About TSX, and the STXL, I do not get a processor overload with this camera [or I havent noticed it]. However, I did notice everything slow down on the main chip loading for the STL. Otherwise, I have not noticed this interrogation by TSX so far - thanks for letting us know though Chris.

I will look tonight for this firmware update, I have never done one specificially before, only the SBIG driver checker,

Cheers,

Steve