Changing background values on STi images. Causing guiding problems and star fades.

GuiderTracking120.fit in the Full Size Guide Images No Calibration Bin 1x1 clearly shows an issue with downloading the STi image.
I'll take a look at some of the others and see if I have any insights.

 

Sorry Joshua, I've been completely swamped, and forgot to update you when I got sidetracked. I am looking through the logs, and trying to piece together what's going on. I'll get back to you tomorrow morning with a more detailed update.

 

Actually, all of them in that file are really bad.
Joshua, have you got a Powered USB 2.0 hub you could try putting between the PC and STi ? Am wondering if there is a voltage drop on the USB bus or something like that.

 

Only 119 looks normal, yet there are no stars.

 

Josh - the thing I find weird is that the problem comes on as you go across the rows, and continues in bands down the chip. Very weird.
Any chance the USB cable runs near a power cable or motor control wiring? Is the camera near any RF source?
Do you have ferrites on the cable?

 

Alright. So I've dug into your logs, and it looks like you were taking continuous 2-second exposures with your camera. Most images had their exposures ended within 50 ms of the requested exposure duration, but I've noticed a few frames where there are large gaps in our status polling command, immediately preceding the call to end the exposure — sometimes in excess of a second or so. That's really the only indication that something isn't quite right (from the log files). Worse yet, I can't directly correlate images to log-calls, because it looks like logging hit the cyclical limit while collecting data — so I have no way of knowing whether those frames are the ones exhibiting higher than average pixel values. I took the liberty of plugging in an ST-i here, to see if I could reproduce the log results with bad frames — and while I did see some frames with moderately higher background ADU counts, I didn't see anything in the logs hinting a delay in status polling to the camera, or even a background jump as large as the ones you saw.

I've spoken with our hardware team, and the ST-i (being an interline sensor) is designed to immediately transfer the image to the frame buffer as soon as the camera's internal exposure counter hits zero, and is read out while the shutter is closing (the benefits of interline sensors) without delay. My operating theory was that the camera was getting into a state where the shutter was closed, but the frame hadn't transferred to the frame buffer, and it was sitting there accumulating dark current — however, nothing in the design of the camera seems to support that hypothesis on inspection.

Long story short: the logs and firmware weren't as illuminating as we'd hoped. While this could be a digital problem, I'm not yet convinced the error doesn't have a root in exposure control logic, or possibly that it's just a power supply issue. ST-i cameras draw very close to full power from USB, and it's possible that (with a third-party cable that uses a low-gauge power wire) there could be enough of a voltage drop that the camera isn't drawing full power. It could also be that some notebooks don't have USB ports that meet USB 2.0 spec, and can't offer full power either. Doug suggested (if you haven't already) plugging the ST-i directly into the controlling computer via the USB cable we provided (which was chosen specifically to meet our power draw needs), and failing that, plug it in with a powered hub (to guarantee the hub can meet the power draw).

If neither of those solutions work, it's possible there's something wrong with the board, but Bill is on vacation this week, so we'd have to chat with him when he gets back.

 

If you're certain the ST-i is getting full power draw, then we're quickly running out of rational explanations for irrational camera behavior.

Re: the logging file size limit: it's hard coded. I advise doing short bursts of imaging and clearing out the log files between those bursts (keeping copies of course). If you can get a bad frame within 5 or so images with a fresh log file, I can see if the two phenomena are linked.

Re: my operating theory: it does normally stay open during guiding operations; but even with that, it can sit in the frame buffer, undigitized, accumulating dark current, and amp glow. We've addressed issues with some cameras that have had exposure control logic producing weird image artifacts in the past, and until yesterday I didn't want to rule out that possibility. Basically, I was hoping this was a firmware bug, and that doesn't appear to be the case — at least, not obviously so.

Let's start by trying to get the log-to-frame correlation sorted out. If there's some correlation between those two phenomena, it will broaden our search a bit. Failing that, try the other PC for good measure. It wouldn't be the first time a bad USB port has been to blame for odd camera behavior...

 

I am developing a logging system that can create multiple log files, but they get so big, so quickly, that it can be dangerous to forget you have it on — it's also taken a back-seat to some more pressing development/tech support matters. Go ahead and plug the ST-i back into the pier, and I'll keep an eye out for those new logs.

 

Thanks Joshua, I'm looking at them now.

 

Am I correct in assuming that GuiderTracking042.fit is the first image in "Logs 10 14.txt"?

 

It *should* be OK. I'll be counting CC_START_EXPOSURE2 calls, so as long as you weren't exposing images with the 8300, we should be in business.

 

Unfortunately, I don't see any correlation between logged exposure durations and bad images. There were three images (GuiderTracking053.fits, GuiderTracking054.fits, and GuiderTracking055.fits) that would have shown up back-to-back in the logs if that was the case, but I never saw so much as a pair of sequential exposures hinting that — and none of those frames lined up with problematic logged exposure durations in the log files. I'm going to call the odd durations a red herring for now, and talk things over with our hardware team. I'll get back to you shortly with more thoughts.