I too am still experiencing the timeout issue using TheSkyX, I have not tried CCDSoftor MaxIMDL. 2 of the last 3 imaging sessions have failed since updating the driver. Not that it is SBIG's fault but when the driver fails so does CCDAP...and when it does my logic to park the scope (or meridian flip) and as a result I have had several pier crashes...I have an STXL-11002 camera. I am currently using an external guider. Driver 4.81 Build 1. I've been battling this driver error all year and its frustrating I understand but we really need a fix. Thanks!
Chris, we will probably have to update firmware and/or driver to finally get rid of this random bug. Regards, Jan
Jan - as you know I have been seeing this receive and/or transmission timeout for sometime now. I do have an important observation to share. I switched to regular guiding through the FW8G and have been imaging with that without any errors now for several days. This was largely due to the unavailability of suitable guidestars for AO use. Two nights ago, I returned to AOX use and the transmission timeout occurred within a couple of hours of imaging. Not concrete evidence of course, but again, I have used traditional guiding using the FW8G for several days without error. regards Martin Pugh
Martin, thank you for this valuable information, I will check today, if there is something specific in communication with AO unit. Regards, Jan
FYI, if it matters, I am also not currently using the internal filterwheel guide camera. I have a camera lens on the front of my STXL, and in this configuration you have to remove the filterwheel front plate (with the guide camera), and use a thinner plate (without the guide camera)...I am using the SBIG STXL remote guide head. I don't recall having this issue with the internal guider.
Martin, if I understand you well, you used two setups without Rx/Tx timeout errors: 1a) Regular guiding through the FW8G with the following cables: STXL HDMI <--> FW8G which controls tracking CCD chip and STXL I2C <--> AOX <-->FW8G, ie. AOX was connected, but didn't use or did you use: 1b) STXL HDMI <--> FW8G and STXL I2C <--> FW8G Q: Was your AOX electrically connected - case 1a) or disconnected - case 1b) during this regular guiding ? 2) I suppose that in your second setup, you used: STXL HDMI <--> RGH and STXL I2C <--> FW8 (no tracking ccd chip) There shouldn't be difference between an internal tracking ccd inside the FW8G and RGH, because both cameras are controlled independently on FW8, ie. have their own I/O bus and do not use I2C bus, whci is dedicated to FW & AO. I have found only one possible issue in CC_AO_DELAY function which hangs computer while waiting for its milliseconds delay to expire, but right now I can't say this is really the source of TX/RX random errors. I have to check this possible issue and let you know. Thank you for your help. Jan
Jan - configuration 1a is the one I have been using i.e the AOX is electrically connected, but I simply choose the non-AO SBIG camera configuration in the Sky X or CCDSOFT. So yes, while I was performing regular guiding with the FW8G the AOX was not operational. To confirm - I am not using an RGH and the AOX remains electrically connected but not in use throughout That CC_AO_Delay sounds like it might be related. cheers Martin
Still the same and still waiting on a fix. I was under the impression that Jan Soldan was working this from his posts above dated 28 Oct 14. Jan has all the details.
Hi, unfortunately, I do not see this TX/RX timeouts on my camera setup, although a bit different to your one: STT, FW8G and AO8. What should realy help is some log file generated by SBIGDriverChecker64 as shown on attachment. Jan
Jan you are forgetting that we have done this a couple of times already. I have sent you driver logs that capture the error and again, in order to reproduce the problem, you have to have identical kit. Please review your posts above also, perhaps that will shed some light. Martin
Martin, I have two log files from you, which show problem when the readout temperature status request (A5, 30) is send to the camera. Sometimes, quite randomly, the driver is not able to write this request to the STXL camera and I am not able to catch or repeat this problem, especially because this is quite random and pops after, say, thousands of good I/O temperature status communications . At t = 763.915: data : A5, 30, 02, 04, DC, 01, 01, 00, 00, 00, 00, 00, 00, 00, 00 At t = 763.916: MicroCommand : SendMicroBlock, cameraID = 17, error = 7 - TX Timeout I know, you do not care about type of the error and you all need reliably working imaging system. Colleagues check the firmware of the camera too. Jan
Martin, I have checked the CC_AO_DELAY function, it simply adds a requested delay, something like OS sleep, but delay is in milliseconds. I am not even sure, any application uses this function. I have checked all logs related to AO problems I have here from users, but there were only CC_AO_CENTER and CC_AO_TIP_TILT functions called, so I think, this function is not used at all by MDL. Jan
For the record, we are also waiting on development kits to arrive on site so we can begin debugging the firmware in earnest.
Perhaps that delay needs to be adjusted - My AO exposures are typically in the millisecond range. I amnot sure of the relevance as to whether this is used by MDL, this is an 'SBIG' driver function, possibly and most probably required by an SBIG device that may depend upon it for correct use. Martin
Martin, I understand what you mean, but the CC_AO_DELAY is just one of the public driver's AO functions offered to developers. It just suspends the current running thread for number of milliseconds passed to it as parameter. This function is never called internally by the driver. Jan
This error is killing me....please let me know what I can do to help...two nights in a row and a total loss....