Testing the photometry tool. W_UMa eclipsing binary

[timh]

Finally got around to testing this facility out and a promising start ..

Firstly just to say that the SC 4.1 facility to now point the scope to any RA and DEC is a real boon. Used it to immediately find the comet dead centre in a fairly small f =1200 mm field. Then the new comet align facility in Livestack to gradually build a nice EEA image of it.

But back to the experimental photometry tool.

W_uMa seemed an ideal test subject - close binary with a period of ~ 8h within which there are two equal peaks and two minima corresponding to the two occlusion positions - one yielding a dip in magnitude of 0.68 and the other of 0.73 corresponding to luminance dips of 2.53^n = 1.88 and 1.97 X respectively at about a 4h interval.

The first part of the process was to do the sensor analysis for my OSC AS1294 MC PRO camera. Perhaps the biggest problem here was to establish lighting conditions where the light intensity was low, fairly uniform and reasonably constant. On this occasion I used evening light in the period that light intensity was not dropping too fast - the whole analysis taking only about 7 min or so. More ideally I probably should have carried out the analysis in more constant light indoors - and probably have used the mono camera for preference for this application? But at the end the sensor analysis produced a good enough -but probably not entirely accurate - linear calibration for this test.

Having polar aligned, set up the mount, guiding and found focus I then used Sharpcap to plate solve on W- UMa at RA 9 43 45.47' ; DEC 55 57 0.09.

The photometry tool then produced a screen for example as below .... (AS1294 initially at gain 124 , 10s exposures) with the tool set to display data on 5 stars and sensitivity at 75% . The screen is a bit too busy - the data for some stars at the extreme right for example can move off screen - but it is possible to read the pertinent data for each star.

I adjusted gain and exposure until the star that I was interested in - W_UMa plus two other comparator stars (lower left and top right)- were not saturating -- i.e the peak luminance value was below 65K-- and then used screen shots to capture the total and background ADU data on these 3 stars for as long as conditions permitted. After 130 min conditions had deteriorated so far - due to fog/ haziness - that all three stars ended up about 3 X less bright (lower ADU scores) than initially. Below this point the photometry tool no longer recorded a measurement.

So conditions were very far from ideal. Nevertheless by normalising to relative brightness versus the two comparator stars it was still possible to plot the brightness variations in W_UMa to detect the expected ~ two fold brightness change over about a 2h interval. The data only starts to look unnacceptably noisy just at the point that the stars were fading to below the photometry tool detection limit.

The plot shows elapsed minutes on the X-axis from when the experiment started (~ 8.55 pm on 050223) while the Y axis plots the ratio of the brightness ( total ADU - background) of the two non-variable control stars versus each other (blue points at a constant ratio of ~ 1.1) and the ratio of the W_UMa brightness versus one of the two comparator stars (orange points at a ratio varying from about 1.5 to 3.0).

There would seem plenty of scope to improve this tool - most simply perhaps by adding the facility to set it to save say CSV files at timed intervals? For my part I think that I will try writing an XL VB macro to simulate curves for alternative binary systems in order to produce theoretical curves that could be fit to the data.

Tim

[admin]

Hi Tim,

thanks for the report - glad that it worked well for you!

I will have to look into having some way to log the data automatically from each frame (ideally grouping the data for each star somehow so that it is easily accessible).

From the point of view of output data, I think a dual approach might be best

1) A single CSV file per star - tracked using RA/Dec co-ordinates or (if not available) pixel position
2) A summary CSV file containing the core brightness measure (estimated total electrons) for each star in columns

That way you can either quickly process the summary, or if you want do more detailed investigations on the individual CSV files.

I am not sure what to do about the amount of data being shown - it could all be useful in some circumstances. I could try to make a better attempt at not allowing it to overwrite other data maybe?

cheers,

Robin

[timh]

Thanks for your reply Robin - and indeed for putting the tool into SC in the first place. It is already quite usable if somewhat cumbersome as it stands.

Anything that you could think of to make data capture easier would be very welcome.

In playing with it a bit I some of the main challenges seem to be ...

1) firstly and mainly data capture - any of your suggestions would be good - I like the idea of CSVs including all of the data separately for a few designated stars within any given field.

2) The guiding needs to be good over long periods -- or you come back to recentre every couple of hours or so. So probably a good idea to run this tool within a script that includes an instruction to plate solve and recentr every hours or so.

3) The field of view obviously has to comprise the star of interest and at least two suitable comparator stars and all preferably with brightness within half a magnitude of each other.

4) It would be preferable to be able to designate stars within a field -- I get the impression that at the moment it just picks on the e.g. 5 brightest.

5) There are obviously limits on the absolute star magnitudes that are suitable. Some stars will saturate even at gain zero within exposure times of less than a second. All manageable I think by paying attention to the speed of the set up, judicious use of filters, minimum accurate exposure times etc.

6) In the case that a variable star dips or rise a lot in luminance over the period of observation--- or simply if sky transparency changes --- then there is a danger the data will move outside of the fairly narrow linear range for detection by the camera at a given gain/ exposure. In an ideal world the software would detect signal starting to increase to the point of saturation or to fade below linear detectability and respond by changing gain/ exposure.

I think however that you would need to gauge just how much demand there is for a variable star observation tool like this within SC versus the amount of work it entails. I certainly enjoyed 'looking' at my first one -- and even with the tool as stands it does work.

best wishes
Tim