Click here if you are having trouble logging into the forums
Privacy Policy |
Please read our Terms
of Service | Signup and
Troubleshooting FAQ | Problems? PM a Red or a Green Gu.... uh, User
groz
Pooh-Bah
Reged: 03/14/07
Posts: 1071
Loc: Duncan, BC
|
|
So, I've been working on getting that technique for doing transit measurements down, and last nite I got a pretty decent set of data on the Tres-1b transit. The only bad hiccup, I left things running and went to bed just after 11. I forgot to close the door to my office, and, the kitty has figured out, an open netbook thats running, is a great warm thing to curl up on and go to sleep. The transit was predicted to end at about 00:18, and I had the setup going to shoot frames till 01:45, to get a full hour and more flatline data after the event. Guess the kitty found the netbook about 00:45, and in the process of curling up on the netbook, managed to sit on enough keys to stop things, and put very bad error/pop-up messages onto the screen. Ah well, sometimes things happen, and we learn more lessons from it.
I ran the data thru aip4win this morning anyways, and it shows I've got about 20 minutes or so of post transit shots, instead of the hour+ I was looking for. Other than that, it's got the lowest scatter of all my attempts to date, and overall I think this is a pretty good result for a modest C8 on my back deck.
C8 + 0.63 reducer, with the starlight express sxv-h9 shooting thru the V filter (wheel should arrive this week, and then wooohooo, i can start working with more bands). Guiding was the QHY5 in the 9x50 (Kwiqguide).
The plot is simply the differential magnitude data, with an offset to get both lines into the same scale on the chart. C2-C1 shows a standard deviation of 5.5 millimags, which is my best to date (5.8 was the best prior to this). No averaging or any other smoothing, with one minor exception. wispy clouds drifted thru field a few times, and I excluded 4 frames that had obvious and very bad cloud pollution.
I'm really happy with this result...
Edited by groz (09/21/09 01:40 PM)
|
brianb11213
Carpal Tunnel
Reged: 02/25/09
Posts: 2076
Loc: 55.215N 6.554W
|
|
Bad kitty kat! See if you can find a keyboard with pointy keys....
|
walt r
Post Laureate
Reged: 02/13/07
Posts: 3458
Loc: Doylestown, PA
|
|
Another nice capture.
Maybe a cardboard box over the laptop will keep the kitty off. But then he may just find a way to get under the box.
--------------------
Walt
Obsession 18" f/4.45 #1370 AN/SC
MK67 Deluxe 6" f/12 Mak-Cass, Super Polaris GEM, JMI MicroMax DSC
DIY 60mm f/6 Achromat
Cookbook 245 CCD
|
btieman
sage
Reged: 07/24/08
Posts: 481
|
|
Great job Groz!
My cats haven't tried to curl up on the warm keyboard--but with the USB wire running into the house, the patio door won't latch and they have snuck outside on occasion! The lesson I have trouble learning is to shut off the windows automatic updates. I've lost 2 transits due to my computer automatically rebooting at 3AM. 3AM *seemed* llike a safe time for updates when I set up the system. I've since reconsidered and decided that 8AM is a better time 
You SD of 5.5mmag is in line with my best transits. Does anyone realize a precision better that 5mmag? I've seen reports of 2mmag but no explanation of the acquisition or analysis process that was used. If anyone has any tips/tricks I'd be happy to hear them
Brian
--------------------
CPC 1100
Orion 120st
Milburn Wedge
QSI 520i
Meade DSI Pro
|
brianb11213
Carpal Tunnel
Reged: 02/25/09
Posts: 2076
Loc: 55.215N 6.554W
|
|
Quote:
Does anyone realize a precision better that 5mmag? I've seen reports of 2mmag but no explanation of the acquisition or analysis process that was used. If anyone has any tips/tricks I'd be happy to hear them
Can you make more observations and bin them ... in groups of 6 that would reduce the random error by sqrt(6) i.e. reduce 5 millimag error to 2 millimag.
I've found that sky conditions have a significant effect even when apparently completely clear & uniformly transparent but then I have a coastal location.
|
btieman
sage
Reged: 07/24/08
Posts: 481
|
|
Quote:
Can you make more observations and bin them ... in groups of 6 that would reduce the random error by sqrt(6) i.e. reduce 5 millimag error to 2 millimag.
Well, I'm not sure. I typically run at the highest data rate that I can without blowing out linearity. I've been using a focal reducer and binning, but I've been backing off on both lately because there's some evidence to suggest that shorter focal length/binning increases centroiding errors. I don't understand what that effect is compared to shorter exposures and averaging. regardless, one thing I'd rather not do is lose time resolution.
Plus I would make the argument that time averaging doesn't increase precision as much as it increases accuracy. I'm looking for ways to make the data acquisition/analysis as precise as possible.
Brian
--------------------
CPC 1100
Orion 120st
Milburn Wedge
QSI 520i
Meade DSI Pro
|
groz
Pooh-Bah
Reged: 03/14/07
Posts: 1071
Loc: Duncan, BC
|
|
Quote:
You SD of 5.5mmag is in line with my best transits. Does anyone realize a precision better that 5mmag? I've seen reports of 2mmag but no explanation of the acquisition or analysis process that was used. If anyone has any tips/tricks I'd be happy to hear them
....
Quote:
Can you make more observations and bin them ... in groups of 6 that would reduce the random error by sqrt(6) i.e. reduce 5 millimag error to 2 millimag.
Well, this got me to thinking, and ofc, looking back at some hard numbers. The raw output data has a tolerance of 4mmag on each data point. AIP4Win calculates that tolerance from the ADU values, and when you do the conversion from integer adu numbers, to a floating point result, that will introduce a tolerance. In this case, that tolerance is 0.004 for most of these numbers, which is 4mmag.
Scintillation equations say, for my gear on the setup I used to shoot this series, at the start, scintillation will introduce 1.5mmag, and by the time the series ends, that's up to 2.1mmag.
4+(1.5+2.1)/2 = 5.8 - inline with my 5.5.
Ok, so, now I tried binning in time. Take a running average of 5 points, two prior, this point, and two following. Standard deviation on that result is 2.06 mmag. Scintiallation equations for 400 seconds says scintillation will vary from 0.55 to 0.93mmag. 0.004 * sqrt(5) = 0.0018, or 1.8 mmag. 1.8+(.93+.55)/2 = 2.5.
These numbers all jive, and, this has turned into an enlightening little exercise for me. In order to reduce the scatter farther, I have to reduce the tolerance on the actual raw measurements. To do that, I need more pixels participating in the ADU measurements for both the star annulus, and the sky annulus. There is a tradeoff here tho, as more pixels participate, we get more read noise inside the annulus as well.
For me, this is relatively easy to accomplish, I'll re-do another transit on one of these, but, remove the focal reducer. I can get the same reference stars in frame still, but the stars will cover twice as many pixels, so, the measurement annulus will include twice as many. That should reduce the tolerance on the output from AIP4Win by a factor of sqrt(2). Now, to get up to the same linear range measurements, I'll have to double the exposure time, and that has yet another side effect, it'll reduce scintillation by a factor of sqrt(2).
If this holds, then, shooting a similar event in the same part of the sky, should give me two reductions, one from the ADU conversion granularity, and one from reduced scintillation. I should get about 1.2mmag improvement on the granularity of the ADU conversion, and another 0.5 from reduced scintillation, and that will in theory, take my 5.5mmag down to under 4mmag. On the downside, I'll only get half the number of data points.
Tonite is forecast to be pretty much the same conditions as the evening I shot the set above, and ofc, that same star will be in the same place, but no transit. For this exercise, transit doesn't really matter, so, I think my telescope is going to stare at the same one again tonite, but this time it's going to have the focal reducer removed, and I'm going to generate a scatter plot on the same two reference stars for this configuration.
I'm going to need a new set of flats and darks for this, so I wont have immediate results, wont be able to shoot flats till tomorrow morning. But, this is worth testing I think...
If indeed this does reduce my scatter by a millimag or more, then, anybody want to buy a slightly used 0.63 reducer ? I'm gonna have one surplus....
|
brianb11213
Carpal Tunnel
Reged: 02/25/09
Posts: 2076
Loc: 55.215N 6.554W
|
|
Quote:
Well, I'm not sure. I typically run at the highest data rate that I can without blowing out linearity.
How about time series averaging the data you have.
Start with the first data point. Construct the next one by taking say 3/4 of the existing value and adding the next value in the time series ... and so on. This gives you a running average which will be considerably smoother than the raw data series, but will contain the same trend data - displaced in time, but this can be compensated for.
You should be able to detect a transit with a smaller amplitude, or measure the amplitude of the transit more precisely, at the expense of being a little less certain of the start & end times but not the mid point timing.
All without changing your observational technique, which is obviously pretty good.
|
SleepIsWrong
sage
Reged: 12/07/05
Posts: 442
Loc: Baltimore, MD
|
|
One thing that can contribute to "scatter" in aperture photometry measurements is how the light from "edge" pixels in the aperture are calculated by your photometry software. Particularly if you're trying to keep your apertures as small as possible (I seem to recall reading that the max s/n can be gained using an aperture that is 1.7 FWHM in diameter) it's critical that, along with very accurate centroiding, the contributions by pixels that are partially inside the aperture be very carefully, and consistently, calculated. You also want to be sure to keep the center of each star's PSF on the same pixels throughout the observing run if at all possible. That means an accurately polar-aligned mount (no field rotation as a function of hour angle). Doing so will help minimise any inaccuracies in flat fielding from pixel-to-pixel - which can be 0.003 to 0.005 all by itself.
You should also be careful about doing moving averages as doing so will cause each combined measurement to be correlated to the observations that preceed and follow it. It will look nice but statistically they are no longer valid individual measurements. It's best just to block combine, say, three measurements at a time.
All you guys that do this exoplanet transit monitoring stuff are pretty amazing! Most of what I do is cataclysmic variable stars, usually during outburst. I always feel really proud if, after plotting all my data, I see a sigma for comp2-comp1 in the 0.007 mag range - most definitely not up to snuff for this playground!
Mike
--------------------
14" Celestron CGE (two of 'em)
Soupy, orange, mag 4. skies (woof!)
ST9-XE, ST8-XME
ssp-3 photometer
Mira Pro UE7 & ProScript, IDL v7.1, AIP4Win, MaxIm DL, TheSky6 Pro, PC-IRAF 2.14.1
Way too many white squares in the graphic, below
|
btieman
sage
Reged: 07/24/08
Posts: 481
|
|
Quote:
One thing that can contribute to "scatter" in aperture photometry measurements is how the light from "edge" pixels in the aperture are calculated by your photometry software.
Yes, I certainly see this effect. I wrote my own aperture code so I could move the aperture around like it were a cursor. I easily see 1-4mmag change by rolling the aperture around the few pixels nearest the centroid. Once more than a pixel or two away I start to see 5-10 mmag change with the aperture centered on different pixels.
Does anyone know if there's any value in interpolating the edge pixels of the aperture? Can this reduce the edge pixel effect? My sense is "no" but I haven't coded up anything to give it a try yet...
Quote:
You should also be careful about doing moving averages as doing so will cause each combined measurement to be correlated to the observations that preceed and follow it. It will look nice but statistically they are no longer valid individual measurements. It's best just to block combine, say, three measurements at a time.
Unless your goal is to average out scintillation effects, I don't see how averaging can increase precision. With exoplanet transits, the goal is to get as precise a series of measurements as possible. Accuracy is of little consequence.
Quote:
All you guys that do this exoplanet transit monitoring stuff are pretty amazing! Most of what I do is cataclysmic variable stars, usually during outburst. I always feel really proud if, after plotting all my data, I see a sigma for comp2-comp1 in the 0.007 mag range - most definitely not up to snuff for this playground!
My best sigmas to date are in the 5.5mmag range and I've baged nearly 2 dozen transits. There are many transiters with magnitude dips > 10mmag--which should be well within a 7mmag sigma. Give it a try some night
Mike
--------------------
CPC 1100
Orion 120st
Milburn Wedge
QSI 520i
Meade DSI Pro
|
walt r
Post Laureate
Reged: 02/13/07
Posts: 3458
Loc: Doylestown, PA
|
|
Quote:
Quote:
You should also be careful about doing moving averages as doing so will cause each combined measurement to be correlated to the observations that preceed and follow it. It will look nice but statistically they are no longer valid individual measurements. It's best just to block combine, say, three measurements at a time.
Unless your goal is to average out scintillation effects, I don't see how averaging can increase precision. With exoplanet transits, the goal is to get as precise a series of measurements as possible. Accuracy is of little consequence.
I think if you are doing the analysis then many of the averaging techniques are valid depending on what information you are trying to tickle out of the data.
However, I don't believe that any averaging or even time binning should be done on data submitted. The data should the raw values from a calibrated image. This allows any future researcher to apply any signal processing they need. If the data was already 'smoothed' then there is less data.
An example I've seen on this forum is the humps about 2/3's the way through a transit. It was first dismissed as noise but later found that someone else's result for the same transit also had this feature. Current theory is that both observers captured the stars sunspots. If this 'noise' was 'averaged' out before submitting than this data would be lost forever.
Oh..this (and others here) has been a great discussion and look forward to reading the latest.
--------------------
Walt
Obsession 18" f/4.45 #1370 AN/SC
MK67 Deluxe 6" f/12 Mak-Cass, Super Polaris GEM, JMI MicroMax DSC
DIY 60mm f/6 Achromat
Cookbook 245 CCD
|
StupendousMan
member
Reged: 08/21/05
Posts: 95
|
|
Quote:
Does anyone know if there's any value in interpolating the edge pixels of the aperture? Can this reduce the edge pixel effect? My sense is "no" but I haven't coded up anything to give it a try yet...
Yes, there's value in it. I wrote my own code, too, and eventually went to the trouble of doing sub-pixel calculations to account for portions of pixels which lie within the aperture.
Don't take my word for it -- convince yourself. Generate some artificial data with a range of FWHM -- say, stars with FWHM = 1.0 to 3.0 pixels. For each FWHM, generate a long sequence of artificial stars, with small variations in the central position each time but exactly the same total integrated light. Use your current photometry routine and measure the light from each instance of the star. You'll be able to determine just how much error the "edge effects" are adding to your measurements.
Then re-write your code to perform some sort of sub-pixel calculation. It's pretty easy to just break each pixel into a grid of sub-pixel squares, and count the squares which lie within the aperture, and use a weight based on the number of squares inside vs. outside the aperture.
Use this new code and re-measure the same artificial star images. Compare the results with your current code. If the measurement error drops significantly (compared to all the other sources of error), then use the new code.
|
btieman
sage
Reged: 07/24/08
Posts: 481
|
|
Quote:
Quote:
Does anyone know if there's any value in interpolating the edge pixels of the aperture? Can this reduce the edge pixel effect? My sense is "no" but I haven't coded up anything to give it a try yet...
Yes, there's value in it. I wrote my own code, too, and eventually went to the trouble of doing sub-pixel calculations to account for portions of pixels which lie within the aperture.
Calvin,
Yes, I see through your disguise!
How much of an effect did you see? Upon what do you normally base your apperture setting? Do you have a light curve with/without interpolation for comparison?
The reason I suspected "no" is that no matter where you draw the boundary, some portion of space is slipping in/out of it. Sure, you have a finer grained boundary, but the shifting light cone that causes the edge pixel effect would still aply to the finer boundary. If you don't have an aperture that completely encircles *all* the stars light, any shift in the distribution of that light will still shift in/out of the aperture--no matter how fine grained it is.
Ack...I guess I may have to try it on some real data. I have coded up a viewer that has an aperture cursor that I can easily move around the screen and see all the data AIP4Win spits out. I'm using it now to monitor a transit of Hat-P-1 actually It can't generate light curves yet or do the differential between 2 stars. But it can position the aperture over any pixel I want--unlike AIP4Win which drop the aperture at some "optimized" location. Moving the aperture around pixel by pixel has been very illuminating
Brian
--------------------
CPC 1100
Orion 120st
Milburn Wedge
QSI 520i
Meade DSI Pro
|
brianb11213
Carpal Tunnel
Reged: 02/25/09
Posts: 2076
Loc: 55.215N 6.554W
|
|
Quote:
AIP4Win which drop the aperture at some "optimized" location. Moving the aperture around pixel by pixel has been very illuminating
My understanding is that AIP4WIN computes the centroid of the shape based on the highest pixel value it finds in the star aperture. This is handy if, like me, you find yourself working with large images and so are usually working with the image pane "zoomed out" to 50% or even smaller. Anyhow it's handy to be able to click "somewhere near" a star and have the aperture parked consistently over the star you intended. Practical, and sounds reasonable to me.
If you get a significant difference by moving the centre of the aperture around within a range of a pixel or two, could I respectfully suggest that this is most likely a consequence of either there not being enough pixels in the background ring to smooth out statistical variations due to random noise (try widening it), uncorrected sensor variations (I doubt it, given the obvious quality of your image calibration) or the position of "unseen" faint stars popping in & out of the star aperture and/or the background ring when the centre is displaced.
Here's the point - if the background is "smooth" and the star aperture is large enough to contain all the pixels which have significant contributions to their photon/electron count from the star, you should be able to move the aperture pattern around and get no difference in the derived magnitude of the star. Of course there always will be some noise but the effect of this tends to reduce as the star aperture and background ring include more pixels.
Isn't there some sort of general rule that the radius of the star aperture should be several (3 or 4) times the FWHM of a typical star image; that the inner radius of the background annulus should be about twice the radius of the star aperture, and that the outer radius of the backround annulus should be about three times the radius of the star aperture?
If this "rule" is followed, then given a FWHM of ~3 pixels (which seems thoroughly reasonable for an image shot in normal seeing conditions) the number of pixels involved in the star aperture and the background annulus is so large that any effect of "smoothing the corners" will be entirely insignificant, certainly not worth the effort of doing.
Edited by brianb11213 (10/05/09 08:45 AM)
|
SleepIsWrong
sage
Reged: 12/07/05
Posts: 442
Loc: Baltimore, MD
|
|
Quote:
If this "rule" is followed, then given a FWHM of ~3 pixels (which seems thoroughly reasonable for an image shot in normal seeing conditions) the number of pixels involved in the star aperture and the background annulus is so large that any effect of "smoothing the corners" will be entirely insignificant, certainly not worth the effort of doing.
It's always a trade-off between using as small a star aperture as possible (thus using only high s/n pixels) but being very sensitive to accurate centering and precise partial pixel integrations (subject to "centering noise"), or using a larger aperture (which then includes some low s/n pixels in the outer PSF) that is much less sensitive to centering errors and to how the partial pixels are calculated, but is much more sensitive to errors in sky level determination.
The optimal sized aperture to use in aperture photometry can be calculated and turns out to be about 1.4 fwhm in diameter. An aperture of that size will, teoretically, result in the best signal/noise ratio for each measurement. This result is based on very well sampled data - essentially extremely small sized pixels. The reality is, of course, that the pixel sizes for most telescope/camera combinatioons are usually a significant part of FWHM - that is, the sampling grid is coarse, which introduces centering noise which significantly increases the size of the optimal aperture. Centering noise itself can be somewhat reduced by "properly" performing partial-pixel integrations to include the "correct" amount of flux from pixels that are partially inside/outside the aperture.
Most of what I do is time-series photometry, so I have a lot of images of the same set of stars taken one after another throughout the night. So it's actually possible to run the photometry a number of times for each night's data, trying different star aperture as well as sky annulus values, to see which produces the lowest scatter in measured differential magnitudes between two comparison stars. When I do that I find that I get the best results with an aperture somewhere between 1.7 and 1.9 FWHM in diameter. That is, for my typical 2.7 pixel FWHM images, I use an aperture that is somewhere between 4.6 - 5.3 pixels in diameter.
Mike
Edited by SleepIsWrong (10/06/09 12:45 AM)
|
brianb11213
Carpal Tunnel
Reged: 02/25/09
Posts: 2076
Loc: 55.215N 6.554W
|
|
Quote:
It's always a trade-off between using as small a star aperture as possible (thus using only high s/n pixels) but being very sensitive to accurate centering and precise partial pixel integrations (subject to "centering noise"), or using a larger aperture (which then includes some low s/n pixels in the outer PSF) that is much less sensitive to centering errors and to how the partial pixels are calculated, but is much more sensitive to errors in sky level determination.
Sorry but I don't get it. (Unless unseen stars are making a contribution!)
Surely the size of the star aperture doesn't matter, once it's big enough to collect "all" the photons which actually came from the star. The contribution of the background is subtracted so it doesn't matter how many pixels in the star aperture are receiving mostly, or only, photons coming from the background.
AIP4WIN documents a procedure (which I presume is implemented in the associated software) where the contribution of unwanted stars in the background annulus is removed by ignoring the highest and lowest 20% of the pixels (it's necessary to balance removal of bright & faint pixels to avoid biasing the average of the rest).
In AIP4WIN there is also a note showing how to get the optimal star aperture radius for a particular image ... by using the "star tool" & noting the way the ADU aggregate increases with increasing radius, the graph will "plateau" where the contribution from the star ceases to increase significantly before the (square law) contribution from the increasing number of background pixels begins to steepen the graph again.
If you set the star aperture radius purely on this basis then you will be constrained by accuracy of centering. If you make the radius somewhat bigger you will get the whole contribution from the star even if the computed centroid, or chosen centre point, is a bit "off".
Also, because the contribution of background photons always has to be accounted for, the s/n ratio of the background measure is critical, so the annulus needs to contain lots of pixels - many, many more than the star aperture, if the noise contribution of the background measure is not going to significantly degrade the derived measurement of the star's brightness.
The other remaining sources of error are:
background stars included in the star aperture - OK, if you make the aperture too big these will definitely bite you, but there's a compromise somewhere;
uneven sensor response in the area covered by the background annulus, which should be dealt with by the normal calibration procedures.
In any event, for time series photometry, surely the existence of a constant background star in the star aperture doesn't matter - you still get the same light curve (though with a reduced amplitude if the background star contribution is significant), measurements of eclipse midpoint time etc. are unaffected.
|
btieman
sage
Reged: 07/24/08
Posts: 481
|
|
Quote:
Quote:
It's always a trade-off between using as small a star aperture as possible (thus using only high s/n pixels) but being very sensitive to accurate centering and precise partial pixel integrations (subject to "centering noise"), or using a larger aperture (which then includes some low s/n pixels in the outer PSF) that is much less sensitive to centering errors and to how the partial pixels are calculated, but is much more sensitive to errors in sky level determination.
Sorry but I don't get it. (Unless unseen stars are making a contribution!)
Surely the size of the star aperture doesn't matter, once it's big enough to collect "all" the photons which actually came from the star. The contribution of the background is subtracted so it doesn't matter how many pixels in the star aperture are receiving mostly, or only, photons coming from the background.
I think you're right--once the aperture *is big enough to contain all the star's light* then aperture placement shouldn't matter. 2xFWHM is not big enough. Playing around with aperture sizes in my software--which implements the AIP4Win algorithm but allows me to place the aperture over any pixel I want--I need to be more like 3-4xFWHM before I stop seeing mmag changes from a few pixel movement. This matches my experience where experimentally apertures of ~3xFWHM give me the "prettiest" plots.
According to AAVSO (http://www.aavso.org/observing/programs/ccd/manual/4.shtml#5), the optimal aperture for max SN is 0.8FWHM. I've tested this to be true, but positioning errors add significant noise to the light curves. AAVSO suggests 3-4xFWHM as the optimal aperture size--and my experience is that holds water as well but is not always practical.
For my last 2 transits I've *vastly* impoved my guiding. Those of you following my saga from home will remember I started exoplanet transits with an alt/az mounted scope! A few months ago, I got a wedge and started autoguiding. I was having some flexure issues with the focuser of the guidescope that I'm still working out, but I've since moved to an OAG. Going from unguided alt/az to autoguided but with some flexure did not improve my scatter as much as I had hoped. This last data set (two nights ago) guided at a rate of ~1-2 pixels of motion/hour! The transit was of Hat-P-1 which has a brighter star contaminating the aperture. I had to stick with ~1.7xFWWHM aperture for this one. I'm still processing the results, but it looks like this may be one of my lowest sigmas yet--with a full moon less than 30 degrees away to boot!
If this holds up as I sort out some oddities in the data (I have a 30 minute gap in my light curve that doesn't exist in my raw frames) then I can draw some possible conclusions.
1) OAG are awsome
2) Sub pixel aperture placement around the centroid may possibly help when using apertures that can not contain *all* the photons. If PHD is guiding at sub pixel than that would be similar to aperture placement at sub pixel. If that's true, it's not the interpolation that's beneficial--it's the aperture placement--which may require interpolation to achieve.
So the quest does on
Brian
--------------------
CPC 1100
Orion 120st
Milburn Wedge
QSI 520i
Meade DSI Pro
|
StupendousMan
member
Reged: 08/21/05
Posts: 95
|
|
The size of the aperture does matter, alas. If you pick a very large aperture, then most of the pixels will have very little signal, so you'll be adding noise to your measurement. As Brian stated, it's a tradeoff: small apertures yield the highest signal-to-noise ratio, but suffer errors due to significant portions of the signal falling outside the aperture -- and, more important, from slight differences in this missing fraction for different stars. The "best" aperture can depend on your targets: if you are looking at a target and comparison star(s) which are all about the same brightness, then a small aperture may be best; but if the target and comparison(s) are very different in brightness, then you'll get better accuracy (but less precision) by using a large aperture.
The point to a sub-pixel grid is that you can decrease the size of the error you make due to the finite size of the pixel grid. It's most important when the image is undersampled, of course, and when you are using very small apertures.
The best I've managed to do with our small telescopes at the suburban RIT Observeratory is about 0.004 magnitudes of scatter -- see, for example,
http://spiff.rit.edu/richmond/ritobs/jul14_2009/jul14_2009.html
With a slightly bigger telescope at a much better site (Apache Point, New Mexico), I've managed a bit better: about 0.003 mag:
http://spiff.rit.edu/richmond/sdss/transit/pt_54380/pt_54380.html
When people need _really_ small scatter, they either switch detectors (PMTs will do better than CCDs, if the stars are bright and reasonably isolated), or use special techniques like the Fabry-Perot defocusing optics on the MOST satellite.
|
btieman
sage
Reged: 07/24/08
Posts: 481
|
|
Thanks for the information! I took copy of your Tres1 transit and fitted it with the model fit routines at http://var2.astro.cz/ETD/protocol.php for direct comparison to Groz's Tres1 measurement. Your sigma on the residuals is roughly half what Groz is getting. The scatter on the data looks to be slightly better than half though I didn''t do any math to measure.
It looks like Stupendousman's data was taken on a 20" scope. Groz's is from a C8. I use a C11 and my results are more in line with Groz's. So now the question is: How much of the difference is related to aperture?
Also, it looks like Stupendousman's data was reduced with ensemble photometry. So far I've been trying to get the precision of the measurements as high as I can and haven't started looking too deeply into ensamble techniques. I think I'll start a new thread with my questions about ensemble techniques.
Brian
--------------------
CPC 1100
Orion 120st
Milburn Wedge
QSI 520i
Meade DSI Pro
|
|
0 registered and 0 anonymous users are browsing this forum.
Moderator: RLTYS
Print Thread
|
Forum Permissions
You cannot start new topics
You cannot reply to topics
HTML is disabled
UBBCode is enabled
|
Thread views: 401
|
|
|
|
|
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
