Staff Assigned: Adam Robichaud Problem With CCD Temps In FITS Headers

Hi all:
We've noticed that the CCD temps recorded in MaxIm DL FITS headers on SBIG cameras have a problem. Here is some data:

DSO-17 STL-11000 -10.2030 and -9.7878 Set Temp -10

Yerkes STL-1001 -10.2030 and -9.7878 Set Temp -10

RCOP STL-3200 -24.9687 and -25.0000 Set Temp -25

AURT STL-6303 -23.5570 and -24.0144 Set Temp -24

The problem is that for a given setpoint, only two values are ever recorded in the FITS header. Examples are above. With our Apogee cameras, we get random temps around the setpoint, as one would expect. For example, if the setpoint for an STL-11000 is -10, the two values above are the ONLY ones ever recorded in the FITS headers. This has been going on for many years (perhaps forever). I've also seen this problem on our ST-7 in archival data (which is why I know the problem has been going on for a while). The versions of MaxIm used are 4 through 6.

Looks to me like you've got a data type problem for the CCD temp field in the headers.

 

Any progress on this issue?

 

Hi Lee,

I would be really impressed if the camera thermometer really were accurate to 4 decimal places in the 6 digit readback. It might speak volumes for the temperature chip's A/D converter. Or, SBIG just wanted bragging rights on the product's precision - (just joking).

I think that the camera just reported the maximum and minimum temperature over some time period, of perhaps many subs - not necessarily the current exposure. That would allow you to use such a range to apply to your image processing and temperature compensation in later post processing.

Of course, that's only my conjecture, and myself, I would simply ignore the range as displayed in each case. After all, if you round off the two temperatures in the range reported, to integers - in each of your four different camera model examples, they are then bang on the user's set point ... which has nowhere near that 4 decimal "set point precision". Perhaps the software shouldn't be reporting more than ONE decimal place of significance, since the user set point is only an integer, to begin with.

I look forward to a better, more technical reply on this matter.

Joe Z.

 

Joe:
You are missing the point of my post entirely. The point isn't the actual accuracy or precision of the sensor in an SBIG camera. It is that the software (MaxIm DL) ONLY reports the two values above EVER. With other camera systems under MaxIm, such as Apogee cameras, the recorded temps show a range of random values around the setpoint, which makes much more sense.

And no, a 1/2 degree inaccuracy is not inconsequential on a TEC cooled camera. For roughly every 5 degrees more you cool a CCD chip, the dark count goes down by roughly 50%. If you are taking darks at one set exposure time, then scaling your darks to your exposure times, 1/2 degree error introduces a small but measurable error when doing precision photometry.

But all that is beside the point. The point is that no temperature sensor which is correctly implemented would EVER just return two discrete, unchanging values for a given setpoint temp. Over *years* of taking data with these systems, for a given setpoint, they have *always* returned the same two values. This is clearly a problem and needs to be fixed.

 

Doug:
Again, the problem isn't that the display is "coarse", it's that for a given setpoint, only TWO possible temperatures are EVER reported. We have images going back years where this is the case. If you set an STL-6303 to cool to -24C, the only two temps that will EVER be reported are -23.5570 and -24.0144. That's the problem.

 

[

Fully agree, with you Lee.

Upon rereading I see your point, that this is indeed very odd. I will try going back into my images and see if it was different, since I don't use MAXIM - just the basic CCDOPS and CCDSOFT. I wonder if any other user has found the same.

Joe Z.

 

But why would there only ever be two possible temperature values for any given setpoint? Also, don't the chips in Apogee cameras also use a thermistor? They don't display this odd behavior.

 

Thanks Doug, that explains it.