Good old reliable ST7. Occasionally now fails to connect, or fails to take a picture, or calls out a filter wheel error. Attached is a short but complete SBIG log file which captures a failure at t = 96.771. The numbers in the "data" field are inscrutable to me, but perhaps you can learn something from them, and give me a clue about what's going on and whether there is something I can fix if possible. All the Command Status queries prior to 96.771 are okay; all that follow fail for a "WriteComPipe write error". Thanks, Dick
Hi Adam, Thanks for trying to help out here. I had another, different failure last night. I was going along just fine for about 45 minutes, when the camera locked up and didn't provide ACP with the Camera.ImageReady signal when requested. ----- from the ACP log (there were 31 previous successful exposures) 00:46:12 (taking 48 sec. exposure, Clear filter, binning = 1) 00:46:12 (using Raw readout mode) 00:46:12 (starting exposure) The remote server machine does not exist or is unavailable: 'Camera.ImageReady' **Script Error** ACP script error 0x80040402 from ASCOM Helper Serial Port Object: Timed out waiting for received data.. ----- I've provided an abridged SBIGDriverLog file that starts with the previous successful exposure, and follows on with the unsuccessful exposure. I've deleted all the early successful log entries, plus some of the intermediate entries for the successful next-to-last exposure, since they all appeared to be showing proper operation. From this driver log, the camera just stops and doesn't appear to have even started the exposure. Using MaxIm 6.26 and SBIGUDRV.dll 4.9.9.7. I've also included a spreadsheet where I've posted side-by-side the driver log entries for the start of the successful prior exposure and the start of the unsuccessful last exposure, making it hopefully easier to get your head around what might have happened. This OS 32 error is different tonight from the OS 32 error the other night that I posted in my previous message. At least, the error codes and data are different. I don't know if these are camera hardware, software or USB COM errors. I hope you can discover something meaningful that can help me. Thanks, Dick
Dick, can you upload the MaxIm and ACP logs? My suspicion is that ASCOM Help Serial Port Object timeout is not camera related - it's the scope, focuser, or some other COM port device.
Hi Colin, Here are the two files you asked for. I should note that the ACP log file (named "(Sch)--V0526 Cyg-...) simply stopped at 00:46:12 (UT). There should have been another 70 or so images collected, with other Plans in the queue to follow for Scheduler. I didn't discover this problem until the next morning (well, I woke up early, 4 am). and the last lines in my log posted above were scraped from the ACP Console window in the morning and do not appear in the V0526 log file. I also don't have the full SBIG Driver log from that day anymore. It would have been about 100MB, and they pile up fast if I let them. Let me know if there's anything else I can help you with. I hope all is well by you. Fall has arrived here, along with generally better skies and lower temperatures. Thanks for your help. Dick
Hi Colin, Adam, Disappointed not to hear a peep after 30 days. I was only looking for an interpretation of the error messages and not necessarily the definitive treatise as to what went wrong. But, that being said, the easiest thing to suspect was a USB problem anyway and not a camera hardware one. The camera is connected 8 meters or so to the computer. Problem was, I guessed, the pair of passive (not powered) USB to Ethernet adapters, one on each end, claiming to be good for at least that distance. But who knows what goes on outdoors in the always dark and occasional damp over a period of years. So a few weeks ago I replaced those extenders with a pair of powered USB 2.0 to Ethernet extenders claiming to be 50 meters capable. I haven't had any errors or stops since, though there haven't been many good nights yet to declare total victory. I hope that this solves the problem described here. You can close this "ticket." If the problem persists, I'll submit a new post.
Hi Dick, apologies for this falling through the cracks. Digging into that error, it's a catch-all for something is wrong low-level in the OS or hardware, and we really don't have a way on our end to diagnose. We should have gotten back to you though - again, my apologies for us dropping the ball.
Don't worry about it, Colin. I know you have a big business with a relatively small staff, so every minute is precious. Thanks for your reply. I think I'm okay for now with the new USB connection.
Dick, I've started getting the OS 32 error as well. My camera is an STT-1603, also a discontinued product. Anyway, I was wondering if you have the following behavior. When the error 32 happens, it when an image is started. Once I get this error, every attempt to try and taking another image generates the same error. However, if I go to Setup and disconnect the camera, wait a bit then re-connect. The camera works again, until some time later, an hour maybe more, then the error 32 returns. Is this what you are experiencing?
Hi Whit, I didn't read Colin's note, because I'm deeply familiar with THAT problem. Perhaps that will help you out of your pickle. Further regarding Error 32, I think you've described what generallly happens in my situation, too. Probably not just the same, but as a result I would also have to shut down the camera, or sometimes reboot the computer, to restart imaging. My advice, beyond what Colin suggests, is to look hard at the USB connection. Dirty? Loose? In my case, the camera was about 25 feet from the PC, and I was using a passive USB-to-Ethernet adapter on each end to go beyond the usual 15 foot "limit" for regular USB connections. That seemed to work for a while (a few years?) but recently as I reported I've seen the Error 32 again. So a month ago I bought and installed a pair of active, powered USB-to-Ethernet adapters (https://www.amazon.com/gp/product/B08CZ925XB/). I haven't had a problem yet, but without a lot of telescope time in the past month, I'm crossing my fingers.
USB is the #1 source of problems with astro. It’s tempting to blame software, firmware, design, weaknesses, but it’s usually USB. Low power supplies (is it colder now and thus your voltage from the cheap wall wart might be low, below the voltage margin which protects from noise), crappy cables with scum in the contacts, too long cheap “charging and sync” cables which are being run like hell carrying huge blocks of image data, whatever. Always the place to start. And “cheap” being he key word. Staples USB hubs, bletch in the observatory.
In cold weather you need an industrial quality USB hub. The reason is simple - the inexpensive hubs all use cheap ceramic resonators instead of crystal oscillators. It saves them at most 50 cents! Unfortunately ceramic resonators are not very temperature stable, and at winter temperatures the hubs are operating waaaay off frequency, resulting in tons of lost messages. It can easily get bad enough that you can't get any messages through. Needless to say the first device impacted will be the camera, since it has much higher data throughput than any other device you are using. A proper industrial temperature rated hub will merrily work at -40C with no problems.
I just wanted to chime in to report that in the month or so that I've been operating with the new powered USB-to-Ethernet adapters I haven't had a single reoccurrence of the Operating System error 32. It hasn't been really all that cold here yet, but maybe a few degrees below zero (C). We'll see what happens when winter really comes along and the temperatures get down around -15C.
Just FYI, that device is rated for -5℃ to +70℃. If you are located in the Northern states it will not work in winter conditions unless it's heated somehow.
