Discussion in 'STT Series' started by Phil Evans, Jun 28, 2017.
What is the meaning of Camera error (8) - STT1603-3 ?
Er ... what does that mean? My STT1603-3 has this error randomly and it screws up my night's photometry.
Is there a physical problem with the cam electronics? Is there software problem that Maxim can't keep up with the cam electronics or what (Maxim v6 - even 6.14 beta)? This has been ongoing for six months. It's not USB related as it occurs both with USB and Ethernet connection. I've also replaced the power supply but still the problem occurs - randomly. Tonight once after five hours, last night not at all over ten hours.
I'm just another customer, thought I might jump in. Can you provide a bit more detail of your setup? e.g. Are you running Windows 10 Creators Edition 1703 or which operating system? If Windows, have you disabled all the power management? (e.g. USB Selective Suspend off, disable power management on USB root hubs, USB hub, camera, Ethernet controller). What kind of PC are you running? eg. Dell XXXX with i7-6700Q 16GB RAM ?
I have not disabled any power management features (never knew I had to).
The problem occurs with all the versions of Maxim 6 that I have tried - 6.09 to 6.14
It occurs with both USB and Ethernet connection to the Cam
It occurs with the AO8 in the optical train and also after removing it.
I've replaced the power supply but that made no difference.
Once the error occurs I can restart by disconnecting and reconnecting the CCD (but only if I'm using ethernet).
However since the system is in a remote observatory in Chile and I'm 8000 km away this is proving difficult.
Here's the details:
PC = Shuttle DS61 V1.1 8GB RAM 500GB SSD i5-3470T CPU
Scope = Planewave CDK 14
Planewave IRF90 focuser/rotator
SBIG STT1603-3 CCD
SBIG AO8T tip/tilt
GARMIN 18X LVC GPS with PPS output
OS = Win 7 Home Premium v6.1 build 7601 SP1
Maxim DL V6.14 Beta 1 & V6.13
Planewave SiTech 1.4.0 ASCOM scope driver
Planewave PWI3.3.0 rotator/focuser controller
NMEATime2 GPS controller
Doug says it is a receive timeout so if it is a timing issue I will try turning off the NMEATime2 controller - this is a feedback controller that maintains PC time to within a few millisec of GPS.
If you need more info just let me know.
Typically Error 8 / Receive Timeout on the USB interface indicates a problem with the USB hardware. It could be caused by a bad USB hub, bad cable, or even root hub on the PC.
We don't typically get reports of it happening on Ethernet. That suggests there may be another cause.
Check that you have good power to the camera. If you are using through-the-mount cabling make sure it is of sufficient gauge (if it's provided by the mount manufacturer it's typically not good enough).
Make sure your firmware and drivers are both up-to-date. Download the latest SBIG Driver Checker instead of using the Update button; that will update the driver checker itself.
My drivers and driver checker were up to date - I've just checked. I am not using through-the-mount cabling. I initially suspected the power connection so I bought a new one from you (SBIG) but it made no difference.
Is it likely that my GPS timing software is causing the problem. It continuously updates the PC clock through a feedback process using the PPS signal from the GPS unit?
It's possible. If there is anything plugged into the same root hub on the PC (they usually come in pairs) that would be a suspect as well.
I disconnected the GPS and the software but the problem continues. What do I try next?
Try plugging it into a different port on the PC. If using a desktop PC, avoid using a front panel plug because they are degraded by the internal wiring.
Try a different USB cable.
Also make sure the camera is getting good power.
I have already pointed out that I am using Ethernet. I switched to Ethernet because I had the problem with USB and Ethernet made it easier to reconnect.
So let me repeat:
1) It occurs on download of a main camera image (I do photometry so I download hundreds of images per session) but is random as far as I can tell.
2) I can reconnect by disconnecting in Maxim (6.14) and reconnecting though sometimes this causes Maxim to crash.
3) It occurs with the camera connected to either USB or Ethernet.
4) It occurs regardless of whether the AO-8 is in the train or not.
5) It occurs regardless of whether my GPS (which has both USB and serial connections) is plugged in or not.
6) I have replaced the power supply with a brand new SBIG sourced one (at high cost)
7) It occurs with all versions of Maxim that I have tried from 6.09 though to 6.14.
8) My drivers and checker are all up-to-date
9) full list of hardware and software is above in my reply to Colin
10) One further point that I have not already made in this thread but have in another thread (posted on 8 Feb 17) is that when using Ethernet the AO-8 is limited to a max speed of 3.3 Hz whereas when it was connected by USB then 10 MHz was easily obtainable
I have searched the forum and found several other instances of the same problem but never a solution.
So I have several questions:
1) What should I try next?
2) Is it a problem with the SBIG driver?
3) Is it a problem with Maxim itself.
I'd appreciate your help.
You had *EXACTLY THE SAME* problem with USB?
Have you actually tried a different computer to eliminate the PC as the cause?
Yes - same problem, just as random.
As for changing the PC it is a little difficult as it is 8000 km away from me on a Chilean mountain. But I will look into it.
From a retired engineers's perspective I would also recommend opening the rear of the camera and remove - inspect - and re-insert the internal micro-fuse.
We had lots of problems with these fuses when they first began appearing in portable defibrillators around the turn of the millennium, especially where the fuse caps were silver plated, over time they become tarnished and high resistance leading to a drop of power to the equipment.
I have no idea what the fuse rating is, it is not mentioned in the manual otherwise I would recommend replacing it as a standard part of a fault finding procedure, it is just stated that you can replace the fuse and there is a section of the user manual dedicated to replacing the fuse (picture below).
Perhaps Tim will be able to give the specification of the fuse so that you can simply replace it, if possible a replacement fuse using gold or tin plated end caps is going to be more reliable to one using silver plate.
Whether you have a replacement fuse or not it is worth removing the existing fuse, wipe and polish the fuse end caps with plain printer paper (it is sufficiently abrasive to remove any tarnishing) and refit the fuse.
Thanks for the suggestion William and I'll see if I can get my engineer to check it next time he visits the observatory (on a Chilean hilltop). I'm hoping he can get there in the next week or so.
One other thought Phil, when/if the tech checks the camera make sure both cooling fans are running, the camera may overheat and become unstable if the fans fail. You might see an indication of this remotely if the TEC power creeps up to a constantly high level after a lengthy period of operation.
Last night while preparing for a session I was running the AO8 and FW8G-STT on a bright guide star but not using the main camera. After about 15 mins I got the "Camera error (8)" message but this time it included the words "RX timeout". Every other time (perhaps bar one or two) the error has occurred on downloading an image from the main camera and it never has those extra words, though always the AO8 was working at the same time. Does this help with a diagnosis?
I have a SBIG STT-8300M camera and experience the exact same behaviour!
Did you ever figure out the cause of the problem and even a solution?
My camera is also located on a remote mountaintop (Tenerife) and I am going there in two weeks.
I hope to have some things to check or even fix when going.
I am using the Ethernet connection and the timeout occurs at random and every time at image download.
Could it be some kind of grounding problem? How should the CCD be grounded?
I hope a solution was found back in 2014
One suggestion for you:
Check for updated device drivers for your computer's network interface card (or on-the-motherboard network device).
I found Realtek devices particularly unreliable and would give intermittent packet loss that could account for this.
Go to the website of the device manufacturer and download their latest; don't trust that Windows has installed the latest.
Thanks for your input.
Phil originally wrote that he also had the same problem using USB.
I have not tried USB but might do since the error occurs too often.
I am using Linux servers and using the HTTPCameraAPI commands.
Separate names with a comma.