Resolved STF-8300M / 2.57 firmware shows extremely high offset/bias levels

Hello all -

I recently updated to 2.57 on my STF-8300M during a stretch of poor weather. I was one of those affected by the drifting offset level with ambient temperature in my remote field setup, so was eager to test this update's resolution to the problem and report the results.

Well... my initial results are not good. In pulling down calibration frames, I've discovered that the data returned from the camera is unusable -- The bias (0.1s) frames have an ADU over 17000! Longer dark cal frames climb from here. This makes long light frame exposures totally impractical as so much of the available range is consumed by this offset.

I have tested and verified this issue on 3 different computers (one of which is the one I've used in the field all along). All are running the latest drivers per the current driver checker release. The camera was cooled to -15C during these tests.

EDIT: I will add that I tested acquisition with both CCDOps and Sequence Generator Pro. Results are indifferent.

Have I missed a driver configuration option somewhere? Misunderstood something? Any other thoughts?

I finally have some clear skies forecast soon, so I'm hoping this is something easy that I've missed

Best,
-Rick

 

Of course - attached.

 

Hi Colin - Thank you for your message and suggestion!

I did try CCDOps before posting, and unfortunately had received the same results. As you see, I am using SGP 2.5.1.17, which worked fine before updating the camera firmware and drivers. (I appreciate the notice that 2.6 is now a stable release! I will certainly update since it's now out of beta.)

The bias frame exposure time is 0.1s because this is the shortest exposure time available on the STF-8300M. (CCDOps and SGP both claim to be able to do 0.09s with it, though the technical datasheet shows 0.1s.) This offset was also present on all dark frames I took, which included 1 minute through 30 minutes with some intervals in between.

I have tried frames both with and without "Auto Bias Level Correction" enabled in the driver. No difference here.

As further troubleshooting, I have enabled the overscan regions (200 vertical, 200 horizontal) and am attaching a 0.09s frame result from CCDOps here. (Note that the sensor is at ambient here.) The overscan regions also exhibit the ~17400 shift. The relative differentiation in these regions to the main sensor area is similar to what I have seen prior to the updates, possibly indicating a frame-wide offset may be present.

 

Hello all -

I'm curious if this is being actively investigated, if there is something else I can try to resolve this issue, or some other action I should take?

I tried a variety of different USB cables over the weekend with no discernible differences. I think I'm clean out of ideas at this point.

Thanks very much for your attention on it. I'm flummoxed.

Best,
-Rick

 

Thanks Tim! I wondered about the need to re-evaluate the USB offset. I will give this a shot in a few hours and give the results when I have them.

Do I need to actively cool the sensor when I run this?

 

I've performed the USB Offset analysis at -10C and have written EEPROM.

The results are as follows:

Img. CCD Offset = 130 in EE for 996 ADU​

I have taken a -10C 0.09s bias with SGP and have attached it here. I'm quite relieved to say things look much more normal now. It appears the ADU is now around 1040 or so -- falling near the range I have seen in the past. I appreciate any review to see that this file looks as expected.

Before reprogramming the EEPROM with the new offset, I read the current value from CCDOps -- it reported "131". I'm struggling to see how a single incremental change in this offset setting accounts for such a wild change in the offset level... but maybe there's more going on behind the scenes here than I understand.

For my peace of mind, can anyone comment on why this error may have occurred? To recap, things were fine until I updated the firmware to 2.57 and updated the drivers to the latest. I will note that the firmware update failed, and Bill in repairs restored the unit for me.

I will be generating some masters tonight, and will report back one more time to confirm things are truly as they seem -- fixed!

Thanks for the guidance on this issue.
-Rick

 

Well, I declared victory too early unfortunately. But I have more information.

The "Set USB Offset" function clearly worked with my last post. However, when I got everything set up again to run my dark libraries tonight, I have found that the 17400 offset has returned!

I re-ran the "Set USB Offset" function, and as before, the issue was corrected. On a hunch, I powered down the camera, powered it back up and hooked it up. The 17400 offset returned.

It does not appear the USB offset is being properly initialized or used at power-up.

I've checked the Offset value in EEPROM through the advanced configuration menu before re-running the "Set USB Offset" function, and it is 130 as expected and as saved earlier. The EEPROM values look to be correct.

So, I'm back to unstable camera functionality. Any thoughts?

 

Hi Doug - thank you for your reply!

I suspected the board as well, until I saw that the EEPROM setting is retained through power up. Everything is operating normally except for this offset. I'm personally suspicious of the new firmware on here, as the changelog specifically notes a change to management of the offset to handle drift -- which is why I updated to begin with

Would it make sense to attempt a downgrade? I will do this with instructions you can provide, if this seems reasonable.

(You might recall that I'm the one that's had trouble bricking my camera with the firmware process on 2 occasions, but I have a different machine that is ready to use. If we're talking about sending it to Bill anyway, what's the harm in trying I guess?)

I will add that how this would be processed regarding warranty service is extremely important to me. This will be the third time in just over a year that I'm shipping the camera in -- and the second in a month. I'm sure you can understand my frustration. Is this something I discuss with Bill? I'm happy to discuss with anyone else offline as well.

Thanks again for your message!

Best,
-Rick

 

Hello again -

I've thought about this further this morning. Hopefully you don't mind fielding my troubleshooting thoughts.

Is it not curious that the difference in expected ADU (17400 ADU with error, to about 1040 ADU without error) is possibly an exact error of 16384... or 0x3FFF hex? The proximity doesn't seem coincidental.

Thoughts?

(Also, still curious what anyone thinks on downgrading the firmware.)

Best,
-Rick

 

Thank you again for your message, Doug! I appreciate you sticking with this.

At the suggestion of another SBIG user, I tried running CCDOps in "admin" mode and resetting the USB offset. Now, I've been able to power cycle several times and get expected bias ADU levels of around 1040 when running my acquisition programs normally.

I don't know if it's coincidence or not, as your suggestion of a bad solder joint could exhibit randomized behavior. I will give it several field runs and see if the problem ever resurfaces, and will report back here and contact Bill if it does.

However, I'm hopeful again that we've solved this. What a puzzling situation... but I'm glad I can get back to imaging

Best,
-Rick

 

Hello all -

Thank you again for everyone's suggestions here.

After 2 consecutive nights in the field, I'm happy to report that the error appears to be permanently fixed. As a recap, the "Set USB Offset" function needed to be performed in CCDOps to eliminate the high bias ADU, and CCDOps had to be executed in Windows admin mode, as doing so in standard user mode resulted in a state where the camera did not use the calculated offset between power cycles.

As further background, this is a Windows 10 laptop.

Happy to be up and running again, and am very happy it wasn't the board.

Many thanks!
-Rick