This event passes through Santa Cruz and north, on a nearly north/south oriented path. Karl's on the eastern limit. Santa Cruz is inside the path, and I plan to be closer to the centerline at Sunlit Lane. As I write this tonight 3 days before, fog covers Santa Cruz but up Empire Grade it is clear. This is a bright (relatively) star and a long (6.4 seconds) event which is suitable for getting good profile information if we can get this with a short integration.
It's at 58 degrees altitude, nice and high, and almost due south at Az=176. My tentative site is at Sunlit Lane, but I might instead choose to drive further, to Locatelli Meadow, to get closer to the centerline. This would be especially true if Kirk decides to carpool with me and fog threatens home, where he's staked out his preliminary site.
|
|
|
A good success! Kirk got great data from the Eco Preserve, and I had a scrambling success from Locatelli Meadow. Karl had a successful taping too, but of a miss. The prediction seemed to be fairly close to the reality. We both got 5.2s events.
Richard Nolthenius (PyOTE log file). Reported 8/20/22 to IOTA
I set up at a gate across from the ruins of the Locatelli Ranch (after the CZU Fire of '20). Perfect skies, dry, no wind, no moon. Found the target easily, got on tracking... and found that in my earlier work with the camcorder, I'd not re-packed the remote control! I'd never used it w/o the remote, and vaguely remembered it might not record input signal w/o it. There are buttons on the side with "REC + >>" and "REC - <<", but it turns out those are just positioning buttons for the tape, not recording. I was screwed! BUT, after a frozen-out event of a couple years ago, with recorder failure, I have had a back-up plan ready to deploy. That is, to record the LCD screen with my PowerShot mini-camera on a mini-tripod mounted next to the screen. That is what I did. I chose to up the integration 1 notch to make sure the star was clear on each video'd frame since I didn't now have time to do testing to make sure of the levels. I set it at 8x. Normally, I'd have been able to go 2x or 4x. The star at 8x was quite easy to see, as the PowerShot camera auto-changed its ISO to "medium gray". The time stamps were all very clear. But the difficulty is that the frame rate of the PowerShot is 25 frames/sec, and the frame rate of the Watec output is 30 frames/sec. So that most of the images had blurred times. I so happened, however, that the very first frame and the very last frame had very clear unblurred GPS time stamps, and it gave a frame rate of .0400086 seconds per frame. I used this in PyOTE with the 'manual time stamp' feature to have it assign times to each frame.
In PyOTE analysis, however, it saw this trouble and doesn't have an in-built solution. When I run the video w/o having it do a manual/automatic integration, then it warns there's high correlation between neighboring points and that I need to make sure and do a manual/automatic integration on the data before analysis. If I instead tell it 4 frames per integration, that's not quite correct. It's more like (25/30)* 4 or 3.333 frames per image, and it doesn't have a setting for non-integer frames per integration. So, after pondering this issue, I've decided the following...
The assigned times are correct to within half a frame time, or .015 seconds. The actual Watec integration was 4 frames per integration and this is what should be applied as a manual integration in PyOTE. To minimize offset error, I manually chose 4 points clearly that were part of a single integration, just a moment before the D. And did a 'manual integration' in PyOTE. PyOTE did not complain. Since the R was only 5 seconds later, I believe both these times should be good, although the state timing errors should be increased. Because of the frame offset issue, I've manually taken the PyOTE stated 1, 2, and 3-sigma errors and added an additional 0.02 seconds to each, for both D and R. This is what will go into my IOTA report. Note that when I screen-capture my PyOTE solution, I position the essential timings and S/N so it is visible on the same light curve image.
I got a 5.26 second event
The inset video frame image is from my PowerShot frame of the Watec output on the external LCD monitor. The horizontal bar is a defect in the external LCD screen but not on actual recordings. |
PyMovie image of the composite of all light curves: tracking1, tracking2, target, and sky. |
PyMovie target light curve. All PowerShot frames are here, no integration done yet. |
Same, as imported to PyOTE and after doing a manual time stamp using the first and last frames of the video. No dropped frames. |
Shows the 4 frames I chose to do the manual integration calibration, just before the "D". |
Resulting PyOTE solution. There were saturated pixels in the target, due to loss of photometric accuracy in my method, only in the center of the target. The non-occulted light is therefore artificially less-scattered than is true. This may also mean the timing errors needs just a bit of increase to be fair. |
Clearly a solid occultation. |
Kirk Bender (PyOTE log file) - reported on 8/19/22 to IOTA
Kirk set up and got a good recording after I dropped him off at the Bonny Doon Ecological Preserve parking lot. No drama, like I had. Just the usual Bender-solid data. Below is his PyMovie data. He got a 5.17 second occultation.
Screen capture showing settings. |
PyMovie raw light curve of both tracking stars, target, and 'sky' |
PyMovie raw target light curve |
It was a beautiful night! |
PyOTE reduction. Error bars too narrow to see. Vertical bar at predicted center of event. |
