UT Sep 24, 2022: Photometry of XX And and indoor tests of high-speed camera

Michael Richmond
Sep 24, 2022

On the night of Sep 23/24, 2022, physics major Abi von Plinsky and I observed the RR Lyrae star XX And for her capstone project. I also ran some indoor tests of the high-speed occultation camera here on loan.

XX And

The star XX And is a variable star of the RR Lyr "AB" type. Its period may be changing slightly on long timescales -- that will be one focus of our study of it.

The main setup was:

• Meade 12-inch telescope
• no focal reducer, so working at f/10
• ATIK 11000 CCD camera
• B, V filters, exptime 30 seconds
• images binned 2x2
• no guiding
• focus values:
  • V: 1.701 yielding FWHM 2.8 at T = 52/11
  • B: 1.730 yielding FWHM 2.5 at T = 52/11
  I set the focus to be about 1.720, about 0.02 units smaller than the V-band value, in order to lie between the best focus for B and V.
  • V: 1.671 at T = 43/6
  Thus, the focus decreased by 0.03 units as the temperature dropped by 5 degrees C. The ratio is a decrease of -0.006 as the temperature drops by 1 degree C.
• camera ran at T = -20 C

Notes from the night:

• mostly clear, with a few brief periods of light cloud
• no Moon
• no skunks
• new soap dispenser in the bathroom -- whoohoo

The object is located at

  RA = 01:17:27.41  Dec = +38:57:02.0    (J2000)

A chart of the field is shown below. The size of the chart is about 31 x 26 arcminutes.

I've marked the location of several comparison stars as well. You can find reference magnitudes for these stars at the AAVSO:

• AAVSO chart for the field
• table of magnitudes from the AAVSO: sequence X27032O

I'm not sure yet which reference star(s) might be best to shift the instrumental magnitudes to the standard scale. These might be good choices:

Label	B	V
C = 111	11.575	11.101
E = 117	12.503	11.745

I took a photo of the finder TV's screen when pointing to this target; this could be a useful reference for the future:

The sky value shows a nicely falling value as the field rises. The sharp drop at the very end is obscuration by the dome panel.

The FWHM graph below shows a gradual rise as the temperature fell from 52/11 when we focused at the start of the run to 43/6 at the end.

Using aperture photometry with a radius of 7 pixels (binned 2x2, each pixel is 1.24 arcsec, so a radii of 8.7 arcsec), I measured the instrumental magnitudes of a number of reference stars and the target. Following the procedures outlined by Kent Honeycutt's article on inhomogeneous ensemble photometry, I used all stars available in each image to define a reference frame, and measured each star against this frame.

Sigma-vs-mag plots show that the floor was about 0.008 mag in V, and 0.009 in B.

The change in zeropoint shows a few brief episodes of clouds.

Photometry shows the star fading in a steady manner over the 3.6 hours of the run. The very end, where all the light curves bend, was ruined by clouds and/or dome obscuration; we should discard it.

High-speed occultation camera tests

After several semi-successful tests of the camera and its hardware, I decided to try some additional tests tonight. I couldn't use it on the telescope, since we were measuring XX And with our ATIK 11000, so I simply placed it on a table in the Observatory House. There was one big difference from all my earlier tests: this time, I carefully read all the instructions provided by Michael Collins, including a checklist of items. As you will see, following the instructions led to success.

My main goal was to figure out the right combination of settings to acquire exposures at a rigid, pre-set interval. I arranged for a set of 10 images, with an exposure time of 50 milli-seconds (msec) and a trigger interval of 55 msec. The guidelines state that the trigger interval must be at least 1 msec longer than the exposure time, in the best circumstances; in this case, I chose 5 msec of "spacing".

The FITS header values of the "DATE-OBS" keyword show that the images were taken at the desired 55-msec cadence:

oaCapture-000000-20220924-000604.fits DATE-OBS= '2022-09-24T00:06:04.0000'
oaCapture-000001-20220924-000604.fits DATE-OBS= '2022-09-24T00:06:04.0550'
oaCapture-000002-20220924-000604.fits DATE-OBS= '2022-09-24T00:06:04.1100'
oaCapture-000003-20220924-000604.fits DATE-OBS= '2022-09-24T00:06:04.1650'
oaCapture-000004-20220924-000604.fits DATE-OBS= '2022-09-24T00:06:04.2200'
oaCapture-000005-20220924-000604.fits DATE-OBS= '2022-09-24T00:06:04.2750'
oaCapture-000006-20220924-000604.fits DATE-OBS= '2022-09-24T00:06:04.3300'
oaCapture-000007-20220924-000604.fits DATE-OBS= '2022-09-24T00:06:04.3850'
oaCapture-000008-20220924-000604.fits DATE-OBS= '2022-09-24T00:06:04.4400'
oaCapture-000009-20220924-000604.fits DATE-OBS= '2022-09-24T00:06:04.4950'

Next, I reduced the exposure time from 50 to 2 msec, but kept the trigger interval at 55 msec. The live-update feature on the computer's screen showed a very interesting variation in brightness at this setting, flashing bright, then dark, then bright, then dark; I think it was picking up variations in the output of the overhead LED light fixtures. Note that a 60 Hz electrical current will cause some sort of variations with a timescale of 1/60 sec = 16 msec. The "beating" between the 55-msec trigger interval and the 16-msec cycle of the current led to these variations, I believe.

Once again, the DATE-OBS lines show that the camera was able to maintain a regular 55-msec cadence. Note that the first image in the sequence starts exactly on the boundary of a full second (01:04:00); the same is true for the previous sequence, and, I believe, every new sequence taken under this sort of trigger condition. (Edit: confirmed by Michael Collins)

oaCapture-000010-20220924-010400.fits DATE-OBS= '2022-09-24T01:04:00.0000'
oaCapture-000011-20220924-010400.fits DATE-OBS= '2022-09-24T01:04:00.0550'
oaCapture-000012-20220924-010400.fits DATE-OBS= '2022-09-24T01:04:00.1100'
oaCapture-000013-20220924-010400.fits DATE-OBS= '2022-09-24T01:04:00.1650'
oaCapture-000014-20220924-010400.fits DATE-OBS= '2022-09-24T01:04:00.2200'
oaCapture-000015-20220924-010400.fits DATE-OBS= '2022-09-24T01:04:00.2750'
oaCapture-000016-20220924-010400.fits DATE-OBS= '2022-09-24T01:04:00.3300'
oaCapture-000017-20220924-010400.fits DATE-OBS= '2022-09-24T01:04:00.3850'
oaCapture-000018-20220924-010400.fits DATE-OBS= '2022-09-24T01:04:00.4400'

My next sequence FAILED to complete. The problem was that I specified a trigger interval -- 5 msec -- which was much shorter than the minimum interval the hardware and software could support. My particular settings of binning and image type led to a a maximum frame rate of 50 frames per second (this information is shown in the oaCapture control window). Now, 50 frames per second corresponds to an interval of 20 msec between frames. My specified trigger interval was only 5 msec, so the computer just couldn't keep up. The result is shown below. I requested a sequence of 10 images, as usual. (Edit: the exact reason for the failure was not that my computer was unable to keep up with the dataflow, but that the camera ignored trigger pulses which arrived too quickly)

oaCapture-000020-20220924-010549.fits DATE-OBS= '2022-09-24T01:05:49.0000'
oaCapture-000021-20220924-010549.fits DATE-OBS= '2022-09-24T01:05:49.0050'
oaCapture-000022-20220924-010652.fits DATE-OBS= '2022-09-24T01:05:49.0100'

After these three images, the software "froze". I had to abort the sequence manually to recover control.

I increased the trigger interval to 25 msec, which is slighly larger than the minimum value of 20 msec. This time, the sequence of ten images did run to completion, with a perfect cadence as requested.

oaCapture-000023-20220924-010840.fits DATE-OBS= '2022-09-24T01:08:40.0000'
oaCapture-000024-20220924-010840.fits DATE-OBS= '2022-09-24T01:08:40.0250'
oaCapture-000025-20220924-010840.fits DATE-OBS= '2022-09-24T01:08:40.0500'
oaCapture-000026-20220924-010840.fits DATE-OBS= '2022-09-24T01:08:40.0750'
oaCapture-000027-20220924-010840.fits DATE-OBS= '2022-09-24T01:08:40.1000'
oaCapture-000028-20220924-010840.fits DATE-OBS= '2022-09-24T01:08:40.1250'
oaCapture-000029-20220924-010840.fits DATE-OBS= '2022-09-24T01:08:40.1500'
oaCapture-000030-20220924-010840.fits DATE-OBS= '2022-09-24T01:08:40.1750'
oaCapture-000031-20220924-010840.fits DATE-OBS= '2022-09-24T01:08:40.2000'
oaCapture-000032-20220924-010840.fits DATE-OBS= '2022-09-24T01:08:40.2250'

Tests with the blinking LED

The occultation camera hardware contains a special calibration sub-system. The timing box can be connected to an LED which can be placed into the light path of the telescope. The box will send a signal to the LED which causes it to light up at the start of each second (within a few microseconds) and remain "ON" for a duration of 20 milliseconds. In order to verify that the times written into the FITS header are correct, one can check to see that the light level increases in the first image taken during each second.

On this night, the equipment wasn't mounted on a telescope, just sitting on the tabletop, so placing the LED in front of the camera was easy. I requested a sequence of 200 images with exposure time 10 msec, and trigger interval 25 msec. If everything was working properly, we would expect to see a high mean light level in the first image taken each second.

And here is the result: exactly what we expect.

A closeup around second 53 shows clearly that only a single image recorded light from the LED ... again, as expected.

In practice, during a real occultation, one could hold the LED in front of the telescope a few minutes before the event to record several blinks; then, after the event has finished, hold the LED up in front of the telescope again. Bracketing the observations with measurements of the LED, and checking the "TSSEQ" value in the FITS header (which increments during each image of a sequence) provide two ways to verify that no frames have been dropped.