[Aavso-photometry] When to submit "Fainter Than" versus actual numbers.

[Jeff Hopkins]

Hello Gary,

Thank you for your explanation of "time series." To me that is 
observing a short term event object. An example would Algol as 
opposed to a long term event object such as epsilon Aurigae.

It appears to me that the standard deviation of the program star is 
not done correctly. The whole purpose of the standard deviation for a 
data point is to give an accuracy figure for it based of the actual 
spread of the data. In order to do that you need to have at least 
three data points to work with. The standard deviation represents the 
spread of those data points. The points must be determined over a 
period short enough so the data does not actually change 
significantly during the measurement period. This can be a problem 
for short term event objects. For occultation work where the 
integration time is a millisecond, it is not possible to do an 
average or standard deviation because the event data can change on a 
millisecond basis. For most other short term events the best you can 
do is to take the measurements as quickly as you can, group and 
average them and use the group to determine the standard deviation. 
For example over your 4 hour period, I would have experimented with 
grouping of three data points at a time. Each of those sets of three 
data points would be averaged to produce the final data point and a 
standard deviation. I would use the middle data point time as the 
time for the data point. You will end up will fewer data point, but 
more accurate ones that have meaningful standard deviations.

This past fall I did observations of Algol over two months. Some 
nights during the eclipse I took UBV data continuously for around 6 
hours.  I took sets of readings (3 in each color) about every 2 
minutes. The comparison star readings bracketed those and also took 
about 2 minutes, so I ended up determining a data point about every 5 
minutes. Since I could not get three sets of data to average for a 
data point, I could not do a standard deviation. I did average the 
raw counts for the 3-10 second integrations however. The reason for 
this was that Algol was changing significantly over a 10 minute 
period. I could watch the average counts change from set to set while 
the comparison readings remained relatively constant from set to set. 
A very interesting project.

Specifying a standard deviation for check and comparison stars tells 
you nothing about the spread in data for a program star data point. 
To specify a standard deviation for the program star data the 
standard deviation must be determined from a set of program star 
data. Remember, the standard deviation represents a spread of the 
data. If the event is changing faster than you can get data, then you 
probably cannot get a standard deviation. Averaging data that is 
changing rapidly is also wrong and misleading. Standard deviations of 
check and comparison stars tell you only about that data. While it 
may give you a nice warm feeling it really does not tell you anything 
about the program star data. The check and comparison stars data may 
be steady, but something could be going wrong with the program star 
data. The only valid way to produce a standard deviation for a 
program star is by using 3 or more magnitudes (close in time) 
averaging them and taking the standard deviation of them. If the 
event is changing too fast, then you can't do that. The 0.192 
standard deviation is not only bad, but misleading. Again standard 
deviation is a measure of the accuracy or how good the data is. The 
star most likely actually changed over that period so a standard 
deviation tells you little, but can be very misleading. It was not a 
large spread do to inaccuracies, but due to actual data change.

Using the standard deviations of the check and comparison stars does 
not look good as a guide because they are jumping around. You 
indicated standard deviation varying from 0.017 to 0.066 magnitudes. 
That means the program star data could be jumping around by at least 
as much and possibly more.

As to collecting 10 million photons, first, with a photomultiplier 
tube (PMT) you do not collect the photons. You count them. The photon 
ceases to exist once it hits the PMT's photocathode. Discarding QE, 
saturation and dead time, one photon will produce one pulse. 10 
photons per second will produce 10 pulses per second, 10 million 
photons per second will produce 10 million photons per second. The 
output of the PMT goes to a pulse conditioning circuit that has a 
threshold limit (pulses of lower amplitude are not passed as they 
were not produced by photons) an amplifier and then to a pulse or 
frequency counter. The frequency counter is gated to count pulsed for 
a set period and then display the results while counting for the next 
period. Typically you can set the gate period for .01 second, 0.1 
second, 1.0 second or 10 seconds. The brightest star I have observed 
with my 8" telescope is Algol with a B magnitude of about 2.0. This 
resulted in about 1.5 million counts per second or 15 million per 10 
second gate time. The data is just read as the number on the counter 
and written down. Some systems have automatic computer logging of the 
data, but I prefer the manual interface. It gives me a better chance 
to review the data and spot problems real time. Note, with photon 
counting of bright objects a dead time must figured in. The higher 
the counts, the higher the dead time (time when more than one photon 
arrives, but only one can be counted). While at first this may seem a 
problem, it turns out that it is fairly easy to determine a systems 
dead time (mainly the pulse shaping circuit on the PMT voltage 
divider and the resulting pulse width) and factor it in. What one 
must be careful of is PMT saturation where the output become 
non-linear. Counts approaching 10 million per second would be getting 
close to that limit. That is why larger telescopes cannot be used 
easily to do photon counting on bright stars.

Jeff

At 05:58 -0700 1/27/05, BailyHill at aol.com wrote:
Hello Jeff;

You asked about "time series".  We use this term to describe an 
observation of a single object, many times, on the same nite.  So the 
particular time series of BZ Uma that I was referring to, had 95 
images, of 2 minute exposure, over a 4 hour period, done 
continuously.  So I have an estimate of the Target about every 2.5 
minutes, allowing for downloading, etc.  This allows us to study 
flares, superhumps in CV, and any other time varying behavior that a 
target star may be exhibiting.

So as a result, we get a light curve of the target or object, and 
also the light curves of any other stars which appear in all images. 
This allows us to plot the time variation of the check stars, which 
should be constant, and any variation is a measure of the noise of 
the process.  It also gives us a basis of comparison.

As an example, BZ Uma had a Std Dev of ,192, which you commented was 
not very good.  On the contrary, since the check stars of the same 
magnitude as BZ Uma were much more constant, with std devs of .045 to 
.066.  In fact, examination of the BZ Uma light curve shows a broad 
brightening in 16 of the 95 frames that drives its std dev higher. 
The same brightening is not seen in the check stars.  Since this is 
so, it gives us confidence that the brightening of BZ Uma is real, 
and not an artifact of our process, clouds, aurora, etc. 

These errors are very driven by the magnitude.  As an example, in the 
same time series on BZ Uma, the check stars around 13th mag had std 
devs of .017 to ,024 mag, which is much more typical.  I am sure that 
if there were brighter check stars in the field, the std dev could be 
driven down to a few milli mags. 

I was wondering, on the targets that you collect 10 million photons, 
how bright are they typically?  You say you collect for 3-10 seconds. 
How do you read out the total?  Do you know how it is done?

Clear Skies
Gary

-- 
Jeff Hopkins
HPO SOFT
http://www.hposoft.com/Astro/astro.html

*********************************************************
  Small minds speak about people * Average minds speak of events
************   Great minds speak of ideas!    ****************
*********************************************************
		     Hopkins Phoenix Observatory
  		       7812 West Clayton Drive
		   Phoenix, Arizona 85033-2439 U.S.A.
        			www.hposoft.com