Basically these two executables create batch (.BAT) files that have simple short names which include always the correct parameters for each observation run.
To overcome the difficulties in the most frequently done process: starting the MetRec, doing the postprocessing and copying the files (since I run my camera as fixed and do the analysis in ON-LINE real-time mode, and need to run the RefStars only once in a month), I made two small DOS executables to ease setup for each evening's observation. With the other, you can get MetRec running in just a few seconds and keystrokes! The other executable is for doing the RefStars procedure. Both reduce mistakes and frustration with all those parameters.
Each observation's configuration file is generated automatically
with proper header and data filenames (at least for my time zone! with
PC's clock set to UTC) from computer's BIOS date. The MetRec execution
parameters are also created, so you do not have to pay much attention to
any of these. The key sequence to run MetRec is now always the same every
night : 1 2 and in the morning 3 4 5.
If you need to do RefStar setup first; you do it with "0".
|Name of the .exe or .bat to run||Run with OS Actions||Comments|
|0 .exe (NOTE: run this only when you need to do RefStars!)||DOS > grab -2 -pal -int 32 -mean yyyymmdd.bmp
> refstars yyyymmdd.bmp yyyymmdd.ref mymask.bmp
|Grabs reference image using Meteor 2 card with PAL system video, saves it - runs RefStars, reads MY-CFG.CFG and updates RefStar file's date-name and saves updated config as METREC.CFG|
|1 .exe (run when observation begins)||DOS Basically; creates observation's config file, creates 2.bat, 3.bat, 4.bat and 5.bat. See comments.||Reads METREC.CFG and replaces next observation's header and
data filenames with current date from PC's clock (which actually is not
necessary if autoconfiguration = yes) and writes updated config file as
2.bat with commands "metrec yyyymmdd.cfg yyyymmdd.log" with command to delete 2.bat after quitting MetRec.exe, and creates
3.bat with "postproc yyyymmdd.log" and create
4.bat with commands to copy logfile, config and dbf files to the data/yyyymmdd directory
|2 .bat||DOS > metrec yyyymmdd.cfg yyyymmdd.log||Start observation by executing MetRec|
|3 .bat||WIN or DOS > postproc yyyymmdd.log -noimage -maxcount 3||Now, do the postprocessing for latest observation, it automatically deletes all meteors with no image saved and deletes all meteors over any 3 second time periods where number of detections exceeds 3 meteors (kills instantly most of the clould-clutter fake detections from log)|
|4 .bat||WIN or DOS > copy mmdd*.dbf data\yyyymmdd
> copy yyyymmdd.log data\yyyymmdd
> copy yyyymmdd.cfg data\yyyymmdd
> pkzip c:\uploads\yyyymmdd data\yyyymmdd\*.*
|Copies DBF, LOG and CFG files to data\yyyymmdd directory and Zips all the files of last observation to \uploads directory|
|5 .bat||WIN or DOS > radfind -sol "before" "afer" -maxp
2 -iter yyyymmdd.log rad.000
Where: "before" is PC date minus 5 days and "after" PC date plus 5 degrees from current PC date converted to solar longitude value.
Note: for WIN you need the WIN compiled version of RadFind.exe
|Executes radiant finding software on iterating mode with 2 degree max
radiant diameter and using previous night's log file and exgluding solar
longitudes 5 days before and 5 days after the current PC date. Outputs
a file called
I recommed you create e.bat batch file with command line:
edit rad.000 so you can see the RadFind result log simply by typing e [Enter]
Note: the 2.bat file deletes itself after MetRec's execution. Reason: if you hit 2 by mistake the next day instead of 3, the 2.bat batch is no longer there to restart MetRec and to destroy your logfile from last night! Remember this, if you have to re-start Metrec with the 2.bat file : it won't be there for a second start - you have to re-run 1.bat first to recreate it again. So, ignore the DOS error message of 'batch file not found' after quitting MetRec - that is just the way it should be.
You may wonder why we need all this? So do I...
The Met-rep.exe software reads effective observing duration and numbers of sporadic and shower meteors from each night's MetRec's observing log file and sums up numbers from a period of one month or from one year's time from 1. Jan. to 31. Dec. or as winter-season report: 22. June to 21. June. The output is on screen and as text file. The directory structure assumed is (\metrec) \data\YYYYMMDD\YYYYMMDD.log - the default path structure for MetRec. All you need to do is to download this Met-rep.exe DOS software, copy it to MetRec's directory, start it and answer if you want to create a monthly report, winter or annual report and for which year (and for what month). In a few seconds all the subdirectories have been searched for .log files and the necessary data picked up for summing process and the results are displayed on screen and as a new ASCII file in MetRec's directory. (SPO mean magnitude calculation added 02-10-2005 ). Unfortunately the changes in IMO's meteor catalog needs a countinuous update process and the reporting software can only recognize and count and report the shower which names are in it's internal shower listing when I have last time generated the Met-rep.exe.
MetRec analysis on observed meteors as plot display on 11./12. Aug. 2000.
The MetRec software never will detect all the meteors within the field of view, but should find more than half or them, which has to be sufficient. High quantity of annoying false detections are caused by clouds, some from insects, areoplanes and birds, some of which may clearly exhibit curved trails - MetRec does not reject them. Satellites are sometimes detected and some random noise - the amount may depend on the detection threshold parameter setting. The V4.1 and up is more effective in filtering out false detections. Line-drop-outs from bad VHS tapes can be mostly eliminated by use of 4-head VCR during playback.
Optionally MetRec identifies meteors from shower radiants and saves detailed data on the meteor's position, angular velocity and brightness in numerical form besides saving the images. This is not all. If you wish to include your data in IMO's videometeor archives, you need to FTP all the saved BMP images, log and other observation-related files from every observation (possibly by compressing them first to ZIP file), but first removing manually the cloudy hours from the logs. This may mean 30 megabytes to FTP monthly. If you run the camera with on-line analysis every clear night for 6 hours, it still takes you some 15 minutes every day to operate (mostly post process...) the system, however automatic the meteor detection is! With off-line playback-system the time consumed increases dramatically. So the procedures requiring daily manual work should be cut to minimum. If you plan to travel to a remote site and record the whole night and analyze the tapes on a daily basis, I doubt you can have a life outside videometeor observing and a regular work. With on-line-analysis and permanent camera setup, it all is much less time consuming, simple and even cheaper!
The most annoying defficiencies of MetRec still are:
Mask file for WAT-902H (not in correct format since here: JPG)
MetRec needs a mask image to exclude areas which are not to be
used for detection of meteors. With a full TV frame, wich for instance
Watec WAT-902H produces when captured with Matrox Meteor 2 card, need to
mask one to 3 lones on image sides, because there is no video and because
sensitivity control algorithms boost up the sensitivity on the 1...2 dark
pixel lines at the very edges of the image, which results fake detections
in large numbers! The mask file shown above prevents this, but remember,
the file has to be in 2-color depth (1-bit) in Windows BMP format in MetRec's
directory, to work. In your setup configuration file (Metrec.CFG) the "Mask
Filename =" must refer to correct mask image file.
This is specially written for the eggheads who generously let everybody know in every possible turn, that DOS is nowadays good-for-nothing.
With MetRec you need a minimum of one-to-two non-DOS applications for easy operating: the FTP software to upload the data to IMO's archives and possibly the automatic NIST clock setting software. In the evening, boot with diskette to DOS, run the desired MetRec executables (with the batch files I explained earlier)... next day post-process the observation and zip the data to \uploads directory. Remove the boot diskette and reboot to Windows, run the FTP software and upload the data, shut down the PC, then plug in the DOS boot diskette again for next observation. While you were uploading the observation, NIST clock setting program has corrected your PC's time to within a second. This however will not correct OS system clock drift during observation - nothing will.
The DOS boot diskette should have (presuming you have DOS (C:\DOS), MetRec (C:\METREC) and related MIL (C:\MIL) drivers on to C: drive!) these files:
LH C:\DOS\SMARTDRV.EXE /X
DEVICE = C:\DOS\HIMEM.SYS
DOS = HIGH,UMB
Note: the country and keyboard settings are here for a Finnish PC!
The disk must be bootable and thus also have COMMAND.COM. Smartdrive
makes the post-processing to work fast and also speeds-up saving of meteors
during observation - use it!
This simple video-driven cloud detector filters-off high frequency video components, such as stars and only a low frequency part of the video is fed to a peak-detector, which output is filtered, compared to pre-set threshold level and a delay circuitry is triggered, as LF video's amplitude increases above threshold. The video image's background should be fairly dark and it may not include largish illuminated white areas, such as moon, excessive glare from bright objects outside FOV, that can jam cloud detection or cause mis-triggering. I suppose if you have absolutely no light pollution and the sky remains dark when overcast, this system will not work, but neither should MetRec then detect any clouds either! If your camera has AGC, turn it OFF! If it can not be set off, and it clearly hampers the use of this detector, swap to another video camera without AGC.
|Detector unit PCB's parts list:
1 10k potentiometerm 10-turn
1 10k trimmer resistor, 10-turn
1 4.7 nF 63V ceramic
3 10 nF 63V ceramic
2 33 nF 63V
1 100 nF 63V
1 330 nF 63V
1 1 uF 25V
1 2.2 uF 25V
1 10 uF 25V
1 22 uF 25V
1 330 uF 16V
1 1000 uF 16V
1 LED red
1 LED yellow
1 LED blue
1 switch, SPNO, momentary
1 12 V DC SPCO PCB relay (such as Omron G5V-1)
2 BNC female chassi connectors
1 AA119 or similar Ge-diode
1 1N4007 diode
2 BC547 or 2N2222 transistor
1 ICM7556 IC (DIP casing)
1 LM324N IC (DIP casing)
The video from the camera is looped through this detector unit. Unit's output relay drives the two keyboard control relays controlling the "remote keyboard", that is used to give "Suspend - Resume" commands to MetRec.
It seems the minimum increase in LF (low frequency) content of the video above black-level, which can be reliably used to trigger suspension, is about 50 mV. Setting the threshold closer may suspend MetRec for no real reason. The first 2.4 second activation delay circuit gives time for a fireball to fly and MetRec to register it - though I do not have experience wether a bright fireball could really cause the suspension to occur. The detector seems by it's design, to be more sensitive to vertical brightness gradients, and less sensitive to flat slightly grayish screen during thin flat cloud cover. The clouds that appear more as horizontally elongated structures, are detected and triggered easier as they produce LF component on the video which the LPF passes through. In situations where, for instance the Moon, or it's glare brightens-up part of the image, the detector may have to be switched OFF (flip to local keyboard) or, MetRec will not resume until the glare is subsided. This may be what you want, or not - I have detected meteors while the Moon is in the corner of the screen.
Typical voltages for LM324N pins 3 and 5 are shown on the schematic diagram to help tuning. The 12 V DC power supply has to be with good regulation and have almost no voltage fluctuation when load current varies - or the whole unit turns to a flip-flop due to unwanted internal (+Vcc-bus) feedback. Ordinary +Vcc-zapping NE556 timer IC should not be used, preferred type is ICM7556, unless you want to add a separate voltage regulator to the LM324N. I have used +12 V from the PC's own PSU and it's stable enough.
The 10-turn precision potentiometer for setting the trigger threshold is adjusted properly by feeding a dark clear-sky video image from the camera, turning carefully the potentiometer up and monitoring the blue "level" LED. When it begins to light up, the two delay LEDs, yellow and red also light up about 2 s later. Turn the knob back "a little" from this point, until yellow LED goes off and stays off. Since the second timer's delay is long, like several minutes, it can be reset with the Reset switch, provided the first timer is no longer activated (yellow LED is no longer lit). The delays can be altered by almost any amount by chancing the R and C values at ICM7556's pins 1 and 2 (trigger-delay) & 12 and 13 (resume-delay). The delays can be re-calculated for a narrow FOV or wide FOV camera and for a single passing cloud patch or larger group of cloud patches, which ever you see proper. Less observing time is lost if you run shorter delays, but then you also tend to get an awful long listing of "Suspended - Resumed " time-stamps on your log files.
On the first test night: 1 h 34 minutes was suspended by the cloud
detector&ext. keyboard-system due to early evening's intermittent clouds
with a couple of meteors detected before the sky cleared. The MetRec
detected however about 25 pcs of those darn cloud images. This may sound
poor, but presumably the cloud image number would have totaled in several
hundreds without this system. On the following night it was clear for a
few hours, then clouded-out for the rest of the night; during transition,
about 20 cloud images were saved after which, MetRec remained automatically
suspended by the cloud detector for the rest of the night. I am satisfied
on the performance over the previously used far-infra-red sky-temperature-metering
based switch. This video detector unit takes about 20-times less time to
build, compared to FIR detector and is a lot cheaper (no exotic Thermopile
detector), and stable to use and it even works much better with those thin
The keyboard switch & video cloud detector driven aux-keyboard replaces the "monkey" hitting "U" when clouds appear and "R" to resume recognition once the sky cleared.
Since MetRec has no software-based cloud detection, or an input port designated for external cloud detector input, and it no longer supports "loss of video", the only way is to send "Ctrl+U" and "Ctrl+R" from the keyboard to halt and resume meteor recognition. I built a Far-Infra-Red (FIR) sky thermometer with a Thermopile detector, that was set to close a relay when sky temperature raises above certain set-point and to keep the relay closed until sky had cleared and 5 minutes had passed by. As said, this FIR detector is now replaced by this better-working video-based detector.
The cloud detector's output relay drives two relays in a box near the PC. Those relays are fed with 12 V DC (loop) from the cloud detector's output relay and there are 1000 uF 25 V capacitors in series with the coils to keep the relay closed only for about a half a second to make a "keystroke" pulse. As of now, the only glitch of the system is, when too quick successive CLOUDS -> CLEAR -> CLOUDS are sent from the cloud detector's DC current loop, the "CLOUDS" realy's series capacitor won't have time to discharge and MetRec will not always be Suspended. This is a minor nuisance and may be corrected with smaller relay coil series capacitors (470 uF or even less instead of 1000 uF), or re-designing the cloud detector - keyboard interface, but this has not proven to be much of a trouble.
The relay contacts are connected to a dismantled keyboard processor's pins, which were originally connected respectively to "U" and "R" keys in the now omitted keyboard matrix.
"Ctrl"- key does not need to be hard-wired ON, since the "Ctrl"- key's hit (make) is sent only once when you push it! This means you have to press and keep "Ctrl" key down from your keyboard before and when you flip the switch over to "Cloud-detector" and then release "Ctrl" key! Otherwise the "Ctrl" "make" is not the last command sent to PC and it assumes the box is just sending "U" and "R" and MetRec will not "Suspend" or "Resume" recognition. The same process needs to be done while switching back to you local keyboard: push down the "Ctrl" and flip switch to "local kbrd" and release "Ctrl" key. This sends Ctrl "break" command to PC, so for instance when you try to quit MetRec (Esc and Y), they will not be understood as "Ctrl+Esc" and "Ctrl+Y" - you could never exit with those. This Ctrl make-brake hand-over method is the easiest way to make the system work and keep it simple.
The relay coil's have resistance of about 750 ohms and the bleeder resistors are 1 kilo-ohms. Note: Since the capacitors must discharge before new command pulse can be produced, the same "drive state" from the cloud detector must not be repeated at too short intervals (as explained above). If the pulses are too long and MetRec gives you the Screen-saver, reduce the 1000 uF capacitors to 470 uF or even smaller.
The outputs: "data" and "clock" of this "aux keyboard's" processor, are connected to a double pole ON-ON switch, which is used to select whether the local keyboard by the PC is in use, or whether the control has been turned over to the cloud detector. The PS/2 keyboard connector's pin numbers can be found easily from the web, but are also shown on the diagram below.
This switching arrangement has many advantages:
since the cloud detector may be off-line sometimes or the night is going
to be clear for sure, the cloud detector can be disabled (left out). The
/ Cloud Detector switch can be flicked at any time to any position.
Just see that you are not leaving MetRec suspended unintentionally by flipping
to local keyboard when MetRec has been suspended by the cloud detector
- the "Resume" would not get to MetRec.
Parts list (except for the cloud detector PCB - listed in previous chapter!):
1 used but working keyboard
(PC PS2) (trace and mark "U" and "R" key-connections and
the "common-return-wire" for "U" and "R" keys from kbd matrix
to processor before dismantling the PCB - you need to know where to hook
up the Susp. and Res. relays and their common wire)
1 Female PS2 connector w. some cable
1 Male PS2 connector w. some cable (from the keyboard where the processor was taken from)
2 1 k ohm resistors
1 DC-connector for 12 V (socket + plug and cable)
1 DPDT minitature switch (Local kbrd / Aux kbrd)
1 m of wire for PCB-to-PCB wiring inside the unit
2 small PCB-type SPST relays with 12 V DC coil
2 1N4007 diodes (accross relay coils to damp the spike)
2 1000 uF 25 V electrolytic capacitors (in series with relay coils)
2 10 k ohm 1/4 W resistors (pull-up)
1 300 mA fuse with fuseholder for +12V DC line
1 preferably: metal enclosure (keyboard cable's GND & kb-processor's PCB's GND are connected to enclosure GND for EMC immunity)
It takes one evening to complete this unit with proper electronic workshop tools.
Warning: do not short-circuit the
+5V line - it may damage the PC's motherboard. Avoid hot-plugging any PC
This schematic is adapted from AD8010 data sheet
It needs a +- 5 volt power supply, but only less than 20 mA of current is drawn. The FB marked components are ferrite beads in DC power lines. Bond all grounds together, keep wires short and PCB foil short at pin 2 for low capacitance. A metal enclosure with BNC female chassi connectors is preferred.
Since any video coaxial cable has to be terminated only at
the end-of-the-line to a single 75-ohm terminator impedance, and the
video from the camera may have to be connected to one, or two frame grabbers,
perhaps a VHS or DVR, and a TV or monitor with SCART input, etc., which
each already do have a 75-ohm termination, proper connection is possible
only with the video-splitter unit. The video source (camera) is built with
75- ohm output impedance and can supply 1 Vpp video signal to a 75 ohm
termination load. If you connect the video coaxial line parallel to several
75- ohm terminted equipment, the video level drops: for two 75-ohm loads
you only get 0.5 Vpp, for four, just 0.25 Vpp. This in well outside the
standard - you do not only loose contrast, but the equipment receiving
the video have really hard time finding the too weak synchronisation signal
from the video stream and you start experiencing synch problems; the picture
rolls and flips. But also: make sure all the lines connected to splitter's
outputs are terminated to 75-ohms.
The length of the PVC body-tube depends
on how long the lens+camera+connectors+heater resistor space are, but it
is not critical as long as it's sufficient. The end-plates are fitted with
rubber gaskets (+ possibly some sealant on the front plate, as it never
needs to be removed). Those gaskets may be cross-sectionally round (hard
to install if you don't have grooves on the surfaces), or sheet type rings
cut from a 2...4 mm thick sheet of rubber. The design may also use 4 pcs
of threaded rods spaced 90° apart radially, instead of just two, ensuring
the front plate doesn't bend so easily when tightened, which could crack
the glass. The glass is secured to the front-end plate with flexible sealant
(MS Polymer). The cables are fed through the back-end plate with
two IP68-class PG9 or PG11- sized cable-glands. If the heater power
uses a separate cable (AC), you need to install 3 cable glands. All the
metal hardware (rods, bolts, nuts, washers) should preferably be non-corrosive
(stainless steel, the plates and camera bracket: aluminium), if you can
There is no support-arm mounting shown here - you either use a large band-type hose clamp around the PVC body-tube, like in many telescopes, or secure it from the bottom with a few M8 bolts. All the holes made on the body-tube or end-plates must be properly water sealed! There are better sealants than ordinary bathroom-type silicon that usually falls-off in 2 years - modified silicon polymer sealants (Wurth: MS Polymer, etc) seem to be good (clean the surfaces from grease with a solvent before applying!)! The front and back plate's M6 nuts (6 or 12 pcs) need rubber washers - if you suspect they might leak water in, cover them with the sealant. A 4 mm drain hole on the lowest edge of the casing (with camera pointing upwards: rear/bottom side) might be necessary as a fail safe, just in case a leak occurs and since the internal pressure varies with temperature, the enclosure breaths air in and out from somewhere anyway. With a drain hole the enclosure won't be filled with water. To keep moisture out, you should never leave the camera unheated even when not used. Keep the heater power on (at least during night-time with clock-timer), or take the camera down and indoors for storage when not used for a long while. The enclosure should be painted silver or white from outside to keep the temperatures at reasonable level in sunshine!
Finally, the glass window (glass flat) has transmission losses; ordinary soda-lime glass has about 87% transmissivity, but an anti-reflection coated optical glass flats have typically about 97% transmissivity and they are optically perfect. This still means only 0.1 magnitude difference, so it may not be worth while in the first setup to spend money on. Everything inside the enclosure (but the camera lens) should be painted black to reduce reflections from the glass inner surface!
Link to CCD
Meteor video camera
Link to intensified (MCP) Meteor video camera
Link to skylight polarisation during twilight and it's reduction by filters
Back to OH5IY's main page