Wow, I'm happy I was pointed to this topic and can add some info. I’ve experienced the issue of changing dark/bias frame ADU on my STF-8300M. I first noticed when bias subtraction failed: My master bias ADU (1060) was greater than the ADU of my 20’ Ha subs (920). No small difference!
I had a suspicion that ambient temperature was a possible factor. My bias frames are taken indoors, and it recently got pretty cold outside (about 3C during the Ha frames mentioned above); I'd never seen a problem previously, and did other "warmer ambient" Ha work in August and September without issue. I wonder if the temperature of the non-temperature-controlled analog circuits causes different read noise. This might explain the drifting pedestal level over the course of the night mentioned in the OP.
Having taken my bias library in August (midwest summer) when indoor ambient was about 24C, I reshot the library in November with an indoor ambient of about 20C. The bias master ADU went from 1060 in the August library to 960 in the recent run. (I maintain a -10C setpoint for all frames, calibration or otherwise.) Note that this is still a higher ADU than my 20' Ha frames.
I performed another test recently to bear this out further: 0.1s dark frames were taken using CCDOps over a short period of time while maintaining a sensor temperature close to room temp (at 20C):
- 12:46pm: Initial hookup, and CCDOps reports a sensor temp of 20.4C. With cooling disabled, an immediate 0.1s frame shows an ADU of 835.
- 12:47pm: Cooling enabled with a setpoint of 20C. I wait for temperature to stabilize.
- 12:51pm: 0.1s frame shows ADU of 903
- 12:56pm: 0.1s frame shows ADU of 912
- 12:59pm: 0.1s frame shows ADU of 915
- 1:19pm: 0.1s frame shows ADU of 923
It might also be worth noting that 0.1s dark frames have a higher ADU than longer dark frames (say 10s), even when taken back-to-back. I see this consistently. For example, my 10s frames are about 40 ADU counts higher than the 0.1s frames, always.
I completely agree that overscan correction should address all of this. The SBIG driver supports up to 200 rows/columns (added to the right and bottom of the frame), enabled through the "Driver Checker" program. Unfortunately, I use SGP and there is not "overscan awareness," so all centering functions are offset by the size of the overscan regions since these regions are included in the image download (... and that centering offset is in the opposite direction after a meridian flip). As you could imagine, this is pretty rough to deal with, so until this feature is supported (I've already submitted a request with Main Sequence), I'll need to wait on incorporating this into my field work.
I have access to an incubator, and am planning on running some tests across different ambient temps to nail down any possible correlation. I plan to run frames both with and without overscan enabled to witness the phenomenon and hopefully see it resolved with overscan correction.
The SBIG driver also has an "Auto Bias Level Correction" feature that Narrowbandwidth referred to. I likewise haven't found that this has any effect on any of the above behavior, and there is forum chatter elsewhere indicating this as well. However, I'll probably include this knob when I run against the incubator and prove any effect one way or another.
I had added to a topic in the SBIG forums on this several weeks ago, but never received any feedback. You'd hope the "Auto Bias Level Correction" would seamlessly address this phenomenon; maybe there's a driver issue to address on their part.
Glad to know others have seen this issue. I thought I was going nuts.
Edited by mrstaypuft, 02 December 2015 - 12:04 PM.
Followed the directions exactly and was given a "TX Timeout" error at which point the process aborted on its own. I knew it was bad news when it self destructed... Gah.
