New STT-8300 horizontal bands

My new STT-8300 is showing significant horizontal banding in some images. I mostly see the problem in images that are binned 3x3, which haven't been a problem as I only use that for syncing.

But last night it showed up in a 2x2 image.

Both examples are attached.

 

The serial number is T16040822.

 

This is a new STT-8300, and the problem has been there since I received it. It was only showing up on 3x3 images, so I had been ignoring it, since I only use those for syncing. But it showed up for the first time in a 2x2 image, which is why I reported it. So far that has been the only 2x2 image, and it has not occurred in 1x1 images.

CCDOps does not work for me, which I have also been ignoring, but I will report that in a separate thread.

 

I get the same results with Maxim DL. I also tried all of the camera download priority settings, which don't seem to affect anything.

And I have tried replacing the power supply with the one from my old STT-8300, but that didn't help.

The bands appear to be aligned with bright stars in the image, as you can see in the attached image 'Multiple bands.fit'. The stars are bright, but not saturated.

You can also see how the alignment of the bands moves with the position of the bright stars in the two images labeled 'Offset test'.

 

I did that test last night, but I only did near-saturated as I was trying to match the brightness level. Those images are attached.

I can try to do the same test with a saturated star possibly tonight.

 

I am not having any luck tonight getting a reproducible error with 1x1 binning, but I did try the barely saturated idea with 3x3 binning and found something interesting.

Assuming that the raster is reading out L to R, it looks like it starts writing out corrupt data after it hits a saturated pixel. You can see that in the first attached image, 'Saturated pixel', where it hits a single saturated pixel and writes garbage for the rest of the image.

The same thing also happens in the second image, 'Saturated scanline', except that on the next line it hits another saturated pixel, at which point it resets itself and starts writing correct data again.

If I expose the image to the point where there are several contiguous saturated pixels within the star, I can't get the lines to appear.

I don't know if that makes sense, but it would explain why the tops and bottoms of these bands always appear to align with bright stars in the image.

Cheers,
Joe

 

Auto background adjustment as in auto darks? Or pedestal offset? I don't think I had auto darks enabled for these tests. And I can't disable the pedestal offset. In Maxim DL, the minimum allowable offset is 10.

 

Yes, but I am only seeing the bands at 1x1 binning through the SII filter. They have that same pattern of aligning with saturated pixels.

In fact, every image taken through the SII filter shows the bands, but I don't see them with any other filters taken at 1x1.

 

I just downloaded and ran the latest SBIG Driver Checker again (for I think the 3rd time this month), and it looks the same as the last version I installed. I have attached the driver list and version number to verify that they are the latest. (By the way, both before and after the new install, the About dialog has the version as 4.03 Build 4, but in the Windows Control Panel it has the version as 4.0.3.5. )

In your test image, do you know if you are seeing any single pixels at 65535? In the test images that I sent you, what I saw happening is that a single 65535 pixel would initiate a a bad raster encoding, up until it encountered another 65535 pixel, at which point it would reset. The images I sent you also had saturated stars that were not producing the bad scan lines, but upon inspection it looks like all of those were coming in pairs, which would immediately negate the bad run.

In other words, you would see something like this if there was separation between the saturated pixels:

65536|xxxxx|xxxxx|xxxxx|65535

The bad encoding would even extend across scan lines until it encountered another 65535 pixel, or flood the rest of the raster with bad data if it didn't.

I am attaching an image that I sent earlier, 'Saturated pixel.Light.L.3x3.03sec.fit', because it shows this pretty well. You can see it in the screenshot from Maxim called 'Saturated scanline crop.PNG'.

In the same image, you can see saturated pixels that don't produce the bands. But it appears that those come in pairs like 65535|65535. So if there is any bad encoding, it would start/stop on the next pixel.

From the same image, you can see an example of that in the crop called 'Saturated pixel pair.PNG'.

I don't know if you can derive from only these examples that all 65535 pixels initiate bad encoding, but it is happening often enough and clearly enough that something is going on.

Cheers,
Joe