The bias frames taken during startup are now saved to a separate bias_validation folder within the nightly image directory on freya (eg ~/data/images/YYYYMMDD/). This should send fewer "corrupted" images over the fence to the DRP and hopefully cause less headache for @robertdstein in terms of parsing images with bad/missing header entries. It would be better if these images had full headers, but because they are generated within the camera control code themselves, rather than initiated from WSP, the images do not have access to all the housekeeping/telemetry data needed to stuff the headers appropriately. A possible future update could have the camera daemon request this information from WSP, but at the moment all communications between the camera daemon and wsp are single-directional (eg wsp talks to the camera daemon, but the camera daemon just "listens").
The bias frame checker can now take address arguments, eg checkCamera -n pa pb. This is really only useful for internal checks, but it is a necessary step towards having WSP bring up sensors that die randomly in the night as has happened several times recently. Otherwise, triggering a startup routine will automatically check the bias of all sensors, and sometimes the cold bias images look different than the warm bias images, which would cause the camera daemon to do a hard reboot of otherwise working cameras while running which is not good. Having the ability to just check/restart individual sensors will make it more practical for WSP to fix these camera issues automatically on the fly.
This update makes two changes:
The bias frames taken during startup are now saved to a separate
bias_validationfolder within the nightly image directory on freya (eg~/data/images/YYYYMMDD/). This should send fewer "corrupted" images over the fence to the DRP and hopefully cause less headache for @robertdstein in terms of parsing images with bad/missing header entries. It would be better if these images had full headers, but because they are generated within the camera control code themselves, rather than initiated from WSP, the images do not have access to all the housekeeping/telemetry data needed to stuff the headers appropriately. A possible future update could have the camera daemon request this information from WSP, but at the moment all communications between the camera daemon and wsp are single-directional (eg wsp talks to the camera daemon, but the camera daemon just "listens").The bias frame checker can now take address arguments, eg
checkCamera -n pa pb. This is really only useful for internal checks, but it is a necessary step towards having WSP bring up sensors that die randomly in the night as has happened several times recently. Otherwise, triggering a startup routine will automatically check the bias of all sensors, and sometimes the cold bias images look different than the warm bias images, which would cause the camera daemon to do a hard reboot of otherwise working cameras while running which is not good. Having the ability to just check/restart individual sensors will make it more practical for WSP to fix these camera issues automatically on the fly.