Just after 9pm, the asteroid Lanzia will occult a 12.7 (combined) magnitude star+asteroid from Santa Cruz, and just 4.5 minutes later, the asteroid Painleva will occult a 13.7 star. Both are of good rank and more than 50% odds of a hit from Santa Cruz. The Lanzia event is also good rank from Highland Way and Karl's place, but the second Painleva event has a less than 50% chance of being a "hit" from Karl's, but given it's a binary star, maybe that's moot. Hopefully his observations will be successful and even a double star miss will be valuable. Altitudes are good; 58 degrees up in Taurus for Lanzia, and for Painleva it's 45 degrees up and 2 deg from Castor in Gemini high in the east.
|
|
|
Kirk and I both got good data. Karl had trouble with the low temperatures affecting power and operation of the camcorder and his computer, alas. The "seeing" was not good - lots of short term flickering, and it affected the S/N and timing accuracy. But I did get both events. Glad I practiced seeing the Painleva field in the Watec LCD screen before I had to swing to it after Lanzia, so I could quickly recognize where it was pointing. And glad that I thought to put my Blue Ice bag against the car's hot air vent wedged between my iPhone and the vent. It both protected the iPhone (which seems to go to Siri when it gets hot, for some inscrutable reason!) and also got me a dry warm source of heat. I placed the camcorder in a small box with air packing insulation between the floor of the box and the blue ice bag, and placed the camcorder on top. I had to tug a bit to get the AV cord to make it far enough to plug in, but it worked. Despite having the camcorder out and running for a good 35 minutes, it recorded just fine in the 38F temperature I believe I had there on Mar Monte drive. I used 4x integration setting.
Nolthenius Lanzia Results - PyOTE log file
The observed duration for me was 7.0 seconds; longer than the predicted 5.9 seconds even though I was nominally north of the centerline. The asteroid may be ellipsoidal, or darker than expected.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Bender Lanzia Results - PyOTE Log file
Kirk observed from home, with identical equipment as Nolthenius. He also used a Watec 910hx integration setting of 4x.
 |
Screen capture of the PyMovie screen, showing the aperture used. |
Target is the blue curve, and the occultation is about 2/3 of the way through. Normally a bit longer would be spent on the trailing end, but we needed to swing over to the Painleva event immediately. |
PyMovie photometry of just the target star. |
A shallow dip, but lots of data points in that dip and a solid positive. |
PyOTE light curve and error bars |
This event is just 4.5 minutes after the Lanzia event. So assuming we stay on Lanzia for 10 diameters, or 54 sec after the event, that gives us just 3.6 minutes to swing to the new target about 2 degrees from Castor and ID the field, center it up, and begin recording. This will not be enough time to pull off the 1.25" adapter and put in the 2" diagonal + Q70 eyepiece again, and then swap it back out for the 1.25" + Watec. We'll have to just leave in the Watec camera and swing it directly go to the target and hope to recognize the field. Luckily, just off the LCD frame square is a 12.9 magnitude SB spiral galaxy which should be visible at high enough integration for a positive ID of a fuzzy patch. It'll be essential to set up early enough to practice this swing through before the Lanzia event, to not muff this rare chance. Kirk checked the night before, though, and said the galaxy was extremely hard to see.
The target star is 13.7 combined, V=14.0, and the C2A data says it is "most likely real as a binary star" and "blended image". So that means we should be alert for a double event and get recording on as soon as possible and for delayed time afterwards. The binary parameters are not given. The drop is 1.2 magnitudes which is good, but the duration is only 1.6s maximum, so don't overdo integration. Maybe 4x if skies are perfect.
The rank is a little worse than for Lanzia. Karl could still get an occultation. |
This Q70 sized chart has no left-right reflection so essentially it's just a larger view of what the LCD Watec field will show, in case somehow the pointing is off. |
The star is a "probable binary" or blend of two, so we should be alert for more than one occultation and less than the 1.3 mag drop predicted. Since the whole event is only 1.6 seconds, that will make interpretation of the light curve possibly difficult. I think the easiest thing is to instead put in the RA and Dec of the actual star, since the two bright 10th magnitude stars on either side should be a good signpots, and not require moving from the galaxy that's above the square. |
A difficult event, because it was so short and also so faint. The conditions were about as good as could be expected, yet my occultation had a 1% chance of being spurious noise, says PyOTE. Kirk did 4x so has many more integrations. We'll see what he gets. But the good news is that the telescope moved to within 1 LCD field of the target and so it was identifiable with enough time to get on target and get the data. Also, the 38F temperatures did not prevent recording for me, although I did take precautions - heating a 1lb bag of Blue Ice over the heater vent of my RAV4, wedged between my iPhone and the vent (thus also protecting the iPhone too). I placed the camcorder on the bag, which was itself sitting on air insulation bags in a small cardboard box.
Nolthenius Results - Pyote Log file2 and PyOTE log file3
I swung the telescope to the target by using the RA, Dec instead of the NGC galaxy. It pointed to a spot up and left of the target, but straightforward to identify on my chart where I was. I kept the recording going w/o pause from one event to the other. My first PyMovie run I took the defaults suggested by PyMovie, but I noticed that when the star was tracking there were significantly fewer pixels being used than when it lost tracking and took the circular aperture. The result was a curve that was noisier than necessary and also had only 3 integrations during the occultation, not enough to ID the occultation in PyOTE. I tried again, and this time lowered the spinner number on the target to 7, to have it grab more pixels around the star blob. This improved S/N to 2.0, and now there were 4 points inside the event bottom and the occultation was ID'd by PyOTE. However, it still has a 1% chance of being spurious noise if we don't consider the time of the event. It's a real event, however, because of the 5 minutes of taping done, this most convincing dip happened at precisely the predicted occultation event time. So while formally the occultation does not have a zero probability of being a false positive, this does not include the Baysian knowledge of the time of the event, the depth of the event, and the duration of the event, which all match quite well.
 |
 |
 |
 |
I have reduced this .avi file one more time, after deciding that using a smaller spinner number generally gives you a better accounting of the light. And also using the jog feature so that after you make a stacked image, you precisely center the tracking star and the target star using the arrow keys to jog them into place. "Snap to blob" works as long as there's enough star there for it to recognize, but if it's too faint, it'll resort to the default aperature and let that move according to the tracking star, so you really need to jog those two at the outset into being perfectly aligned. So, I did that, and I used a spinner value of 6 instead of the default higher number, and it did improve the S/N and the odds of it being noise are now 0.4% instead of the 1.01% on the run above. Here's the results... Pyote log file=test6.pyote.log
 |
 |
 |
Kirk also got a success. He ended up using the same aperture spinner setting as I settled on: setting=7. At 4x setting, he got more points at minimum and that resulted in better S/N, better timing accuracies, and better confidence. Only 0.3% odds it was a random noise dip. Still, note the red bar was left of the black bar. It's unfortunate that the software seems to favor a 0.000000% chance of a false positive before reporting a positive. That's not the usual standard of claiming a significant event in science practice. Also, this PyOTE statistic only considers the odds that a dip such as observed could happen anywhere in your data and be false. The fact that the dip occured right at the predicted time, to the second, should be factored into the calculation.
 |
 |
 |
 |
 |
