LED voltage not written to FITS header

[hpearnshaw]

The LED voltage currently does not get written to the FITS header. For now we get around this in the standard analysis set by putting it in the file name, so it's not an urgent fix, but it's not ideal.

Syntax used in these scripts is:

cam.key('LED='+str(voltage)+'// LED voltage in Volts')
cam.setled(voltage)

where voltage is a float.

Pyarchon output reads:

[DEBUG] command= key LED=1.68// LED voltage in Volts
 return= [u'DONE\n']
OK
[DEBUG] command= bias 9 25 1.68
 return= [u'DONE\n']
OK
module 9 chan 25 is 1.680000 volts

...and an example of the CameraD log is:

2025-03-27T19:14:43.093432  (FITS_file::add_key) ERROR unknown type: DOUBLE for user keyword: LED=1.68: expected {INT,FLOAT,STRING,BOOL}

The actual LED voltage is set correctly as the LED behavior is as expected, but the FITS header does not get written.

[chazshapiro]

Does the server's "key" command work correctly in the script? It works from bash. Does it work elsewhere in the python scripts?

[chazshapiro]

I'm adding a priority tag since this may be a general issue with the FITS headers.

[chazshapiro]

I ran a script that used

cam key VLED=<float>

and the VLED key didn't make it into the headers

[hpearnshaw]

The script led_header_test.py in /home/user/CMOST/Analysis/cmost-analysis replicates this problem.

The output FITS file in /home/user/CMOST/Analysis/data/20250403/cmost_DIE103_testledheader_0064.fits shows that, of three test FITS headers (TESTHEAD, a float; TESTINT, an integer; and TESTSTR, a string):

• TESTHEAD doesn't get written at all and the CameraD log gives the following error:
  2025-04-03T17:23:39.241679 (FITS_file::add_key) ERROR unknown type: DOUBLE for user keyword: TESTHEAD=1.23: expected {INT,FLOAT,STRING,BOOL}. This appears to be the root of our LED header problem, in which we can't put floats in FITS headers because somewhere they are being loaded in as doubles.
• TESTINT gets written correctly
• TESTSTR gets written correctly

The key strings seem to be sent directly to the camera via __send_command in pyarchon, so I don't think the problem is in pyarchon.

@astronomerdave let me know if you'd like me to raise it as its own issue in camera-interface.

[astronomerdave]

This was a bug which has been fixed (CaltechOpticalObservatories/camera-interface#58).
It now supports keys of INT, LONG, FLOAT, DOUBLE, STRING, BOOL. By default, any decimal value is taken to be a double, which you can override by adding an 'f', and any non-decimal value is taken to be an int, which you can override by adding an 'l' immediately after the value. For example,

3.14 --> double
3.14f --> float
100 --> int
100l --> long

The fix has been compiled on the cmost computer; you need only to restart camerad.

[hpearnshaw]

Wonderful, thank you! This will also need to be compiled on the JPL machine to keep the software consistent - check with @gkyne if you don't already have the details you need.

[astronomerdave]

Wonderful, thank you! This will also need to be compiled on the JPL machine to keep the software consistent - check with @gkyne if you don't already have the details you need.

Would that be the uvex computer (.68)?

[hpearnshaw]

Confirming that this works on the CMOST machine, closing issue.