If you observed no meteor so far, just delete the logfile, the dbase
files and the data directory and restart the observation.
start of observation : 2006/11/18 20:16:30
If you observed already some meteors, just delete the logfile
yyyymmdd.log (a copy of it is stored in your data directory) and the
PosDat header file mmddhead.pdf (it will be created again), and restart
the observation.
At the end of the night, you edit the logfile in your data directory,
which contains both observations. Copy the start time of observation
and the effective observing time
effective observing time : 1 h 46 m 41 s
from the end of the first observation to the end of the file. There you
replace the start time at the end of the second observation, and add the
effective observing time from the first part.
Last but not least you delete everything from
19:19:00 End of recognition request
19:19:00 Saving flatfield ... ok!
19:19:00 Saving sensitivity image ... ok!
Freeing resources and finishing ... ok!
...
of your first observation, until
...
Initializing PosDat files '1118data.dbf' and '1118head.dbf'... ok!
Creating recognition threshold history file 'metrec.thr' ... ok!
Creating auto-subdirectory '20061118' ... ok!
19:20:19 Initialize flatfield
19:20:30 Start recognition
of your second observation, and add two new lines
19:19:00 Suspend recognition
19:20:30 Restart recognition
instead. You end up with a file that looks as if you did not interrupt the observation, but just suspended it. You copy the modified logfile into your data directory and post-process it as usual. The meteor counts will be updated automatically, when you delete false detections. If there are no false detections, use the parameter -count to force PostProc to write new meteor shower counts.
If you restarted the camera several times, you can repeat this procedure, i.e. you take the start time of the first observation, add the effective observing times, and replace the begin of all following observations by the two suspend and restart lines.
From false detections showing only clouds and from long gaps where
no meteor was detected you can conclude, that it was overcasted at some
time of night. If it was just at the beginning of the observation, you
correct the time of the begin of observation
20:16:19 Initialize flatfield
20:16:30 Start recognition
and the observing statistics
start of observation : 2006/11/18 20:16:30
end of observation : 2006/11/19 05:18:59
effective observing time : 1 h 46 m 41 s
by replacing the observation start time (correct also the date if skies cleared after midnight!) and subtracting the time from the effective observing time.
If you had false detections in the time when it was clouded, do not delete them by hand from the logfile, but use PostProc. Otherwise these false detections will not be deleted from the PosDat files, and the images will also remain in the data directory.
Similar to the previous point, you correct the time for the end of
observation
05:19:00 Maximum recognition time reached!
05:19:00 Saving flatfield ... ok!
05:19:00 Saving sensitivity image ... ok!
and the recognition end time as well as the effective observing time in
the statistics section
end of observation : 2006/11/19 05:18:59
effective observing time : 1 h 46 m 41 s
Remember not to delete false detections by hand, but always using PostProc.
No problem. Just enter two lines
01:00:00 Suspend recognition
02:00:00 Restart recognition
after you have deleted all false detections, and subtract the time
difference from the effective observing time
effective observing time : 1 h 46 m 41 s
If you have false detections, it is usually quite easy to find out when it was clouded. But sometimes it is just foggy or the limiting magnitude goes down dramatically. What I usually do is to look for gaps, when there was no meteor recorded for more than one hour. These times are marked as clouded as described above. Of course, this is just a rule of thumb: If my image-intensified camera does not record anything within 30 min, I mark these times as well, because it usually records a meteor every few minutes. If, on the other hand, a non-intensified camera has a gap of two hours in the evening hours of spring, when there is hardly any meteor activity at all, and if the meteor before and after the gap show perfectly clear skies, I accept also longer breaks. What I definitely not want are logfiles giving an effective observing time of ten hours with only two or three meteors detected!
You have to do it by hand (see above) - there is no automatic procedure to correct these times.
Take an existing logfile from a previous night and append the last few lines to your logfile:
05:19:00 Maximum recognition time reached!
05:19:00 Saving flatfield ... ok!
05:19:00 Saving sensitivity image ... ok!
Freeing resources and finishing ... ok!
Observing Statistics
====================
start of observation : 2006/11/18 20:16:30
end of observation : 2006/11/19 05:18:59
effective observing time : 1 h 46 m 41 s
# active meteor showers : 4
# observed meteor showers: 3
# observed meteors : 15
Sporadics (SPO) : S=7, Ø=1.6 mag
N-Taurids (NTA) : S=1, Ø=-2.5 mag
Leonids (LEO) : S=4, Ø =-1.0 mag
S-Taurids (STA) : S=3, Ø=1.1 mag
alpha-Monocerotids (AMO) : S=0
Correct the time of the three lines of the end of observation, the start and end date and time, and the effective observing time by hand. Run PostProc with the option -shower to delete false meteors and recompute the meteor counts. If there is no false meteor, use the -count option.
Sometimes MetRec detects two meteors at the same time. Since it cannot
save images for both meteors, PostProc will report "No image available".
That does not mean, however, that you have to delete the meteor without
image. Just remember the x/y-position of the meteor
21:36:05 Meteor #20 at (0.343,0.758)->(0.385,0.688) frames=19 dur=0.74s pixel=7 dir=301° vel=5.0°/s s=2.3
shower=SPO bright=1.8mag (1.894h,47.96°) -> (1.765h,51.36°) acc=2.4'
which is roughly 0.3 / 0.7 is this case, go back to the previous image, and check, whether there is indeed a second meteor at the given position (whereas 0.0 / 0.0 is the lower left, and 1.0 / 1.0 the upper right corner). If that's the case, you can keep the meteor without image. If not, delete it.
In the case, that the previous meteor was much earlier, you need to delete the meteor without image as well. In this case there was a slow moving target (like a satellite) in the background, which prevented from saving the image, but was discarted later on because of its velocity.
That happens sometimes, especially with bright meteors. Please, keep only the record that consists of more video frames, and delete the other one. I don't care if you keep a copy of the image for your own records, but the meteor should appear only once in the archive.
When you plot the line of the detected meteor position in PostProc you sometimes see, that the begin or end of the meteor was misidentified (i.e. the line deviates significantly from the true meteor position). That happens frequently with bright meteors which burn our the image completely. Please, delete this meteors! Even if you think it might be pity for the bright meteor, you should remember that the position you measured is simply wrong, and from a PosDat entry you do not see anymore that this was a measurement error. You could try to correct the position by hand, but is it worth the effort when we have 200,000+ other in the database?
Look at the meteor frame by frame by pressing "M" in PostProc. When the meteor seems to fly around the corner, or when it is moving irregularly - delete it. If you are not sure - delete it. Remember the archive size given above, and that quality comes before quantity.
Yes. But, please, do not send these flash images to me at the end of the month, because they will not be archived!
Yes. But, please, do not send the MISC directory to me at the end of the month, because it will not be archived!
Yes. But, please, delete them before you send in your observation at the end of the month!
Yes. Remember, that each data directory should contain the following files when you send it to me:
If you run your camera automatically, you may need to rename your generic configuration file metrec.cfg and logfile metrec.log before copying them into the data directory.
Yes, since otherwise the meteor files will not be deleted, nor the PosDat entries. To save time, however, you can delete more than one meteor at a time with PostProc by pressing "D". In addition, you can delete a number of meteors in advance with the command line options of PostProc.
No. You should create a new reference star file at the next possible occasion, and re-run PostProc with the -ref option. This will recompute the meteor position from the new reference star file. You can verify that by comparing the position given in the meteor data window at left (that's the corrected one) with the position given in the logfile window below (that's the original position). Beware that the -ref option introduces rounding errors, so it should only be used to correct for mistakes.
Don't correct anything - just tell me when you send me the data. I have some little scripts that can easily correct all the incorrect values (config file, logfile, PosDat data file, meteor data files, meteor file names).
webmaster@imonet.org; last change: December 21, 2007