> If you want to operate the camera without an intensifier, however, it
> should be as sensitive as possible, of course. Rob McNaught has been
> experimenting with the Watec camera down under, and Werfried Kuneth is
> testing this camera under more common skylight conditions compared to
> the Australian outback. :-)
Perhaps I'm repeating myself, but the WAT-902H with f/0.85 lens barely
detects the sky background during full Moon. Thus its detections are
constant throughout the month (30-40 per 10 hours). My intensified camera
drops by about a factor of 3 between dark time and full Moon. Using
similar MetRec parameters as the Watec this goes from about 400 to 150,
but I've started to use more conservative parameters for the intensifier,
so I only have useful data for trajectory/orbit analysis. Two positions
just don't cut it!
Still finalising some trajectory/orbit software, but this afternoon, got
a first velocity; 17.3 km/sec from the Watec data and 17.2 km/sec from the
intensifier for a mag +3 sporadic from the deep southern sky. A pleasing
start. Steve Quirk and I should be able to produce around 300+ orbits each
month. Still have to work on the error propogation.
Cheers, Rob
Tom,
> I was curious how well the 902-h was working for you because I'm about to
> buy a camera, and have considered:
>
> Watec 902HS
> Watec 902H
> Genwac GW100N
> AstroVid 2000
just to repeat as this question is asked frequently: If you look for a
camera that records the screen of an image-intensifier, a simple CCD video
surveillance camera will do a fine job. It does not need to be especially
sensitive, as the system is limited by the primary lens and the gain of
your tube, not the camera. Typically the phosphorous screen of the
intensifier is bright enough to be recorded without problem by an
"ordinary" camera. Manual gain and/or black level is fine, but personally
I hardly ever use this option. In twilight the background brightness
changes that strong, that without automatic gain the image is typically
completely saturated in the evening or morning. Or if you start the
camera in twilight with manual settings, the image will be ways too dark
at midnight. So this is why I have been working with activated AGC for
some years now.
If you want to operate the camera without an intensifier, however, it
should be as sensitive as possible, of course. Rob McNaught has been
experimenting with the Watec camera down under, and Werfried Kuneth is
testing this camera under more common skylight conditions compared to
the Australian outback. :-)
Cheers,
Sirko
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www-i6.informatik.rwth-aachen.de/Colleagues/molau *
**************************************************************************
Folks,
> gain control to automatic. This was fine until some mornings it was partly
> cloudy at sunrise, and there were thousands of MetRec cloud detections!
> Now, Steve doesn't let it run into daylight. We alter the FlashThreshold
> (or whatever the parameter is) depending on the liklyhood of cloud and
> moonlight, but the morning weather isn't always predictable. We use a much
clouds have always been a problem with MetRec. I tried different methods
to detect clouds, but have not really been successful so far. A "star
detector" would be the natural solution, but that may take some extra
computing power. Changes of the background brightness are no good
indicator if your video camera has automatic gain activated.
I found the best way to reduce the number of false detection is to
increase the RecognitionThreshold (in my case from 0.75 to 0.90) and the
MinimumFrameCount (in my case from 2 to 3). I'm just testing a new way
to cope with clouds: If there are too many detections in a short time
intervall, MetRec changes the values of these two parameters to some
fall-back values specified in the config file. The activation of these
parameters in the presence of clouds works quite reliable, but I have not
yet a good solution at what time to switch back to the original values
when the clouds are gone. Currently it alternates between the cloud and
no-cloud values, which is not what I really want.
BTW, another solution would be an external cloud detector by measuring the
"sky temperature". Ilkka Yrjola is just working on such a piece of
hardware. Let's see what he comes up with in the end.
All the best,
Sirko
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www-i6.informatik.rwth-aachen.de/Colleagues/molau *
**************************************************************************
Hi,
We have recently purchased Watec 902HS and Astrovid 2000 units.
Although astronomical field tests have not been extensive yet in
terms of meteor detection, in terms of side by side optimized
sensitivity the Astrovid unit was substantially more senstitive than
the Watec, somewhat contrary to specs as I understand them. This is
too bad since the Watec is significantly less expensive. I've not
tried the non HS unit. As you probably know, we were warned about
static type noise with the HS, which doesn't seem too bad.
Bob
--
========================
Robert Hawkes
Professor of Physics and
Head, Department of Physics
Mount Allison University
67 York St.
Sackville, NB, Canada
E4L 1E6
rhawkes@...
FAX (506) 364-2583
phone: (506) 364-2582
> Anyway, I'm curious how well the camera is working without an intensifer. I
> just got a 25mm Gen 2 intensifier and am doing some experimentation.
I've done side by side comparisons with a WAT-902H with 25mm f/0.85 lens
and an 18mm Gen II intensifier with 55mm f/1.2 lens and also an 85mm f/1.2
lens (phosphor imaged by a security camera). To some extent the comparisons
are not a true reflection, as I used different values for the
RecognitionThreshold and MinimumFrameCount in MetRec. For the WAT-902H
the MinimumFrameCount was 2 whereas for the intensifier it was 4.
Results: The 85mm lens had about the same sky coverage but about six times
the number of detections. The 55mm had an (inversely) proportional larger
field and a similar detection rate. With both these lenses, all Watec
detections were also recorded by the intensifier. I did one test with a 24mm
f/1.4 lens. This had lowered overall detections, and a proportion (30%?) of
the Watec detections were missed by the intensifier.
On a typical 10 hour night at the moment, the Watec is producing about
30 to 40 detections. In tests I did some months back with an 8mm f/1.4
lens (for 1/3inch CCD, so corners vignetted) I was getting less than 10.
Hope this is of some use.
These tests were done to optimise the detection and field overlap for
two station triangulation to derive radiants and orbits. We decided
on a traingulation center closer to the Watec, as it was the limitation.
The intensifier uses a wider field of view and is more sensitive. The
whole of the meteor layer recorded by the Watec is covered by the
intensifier. On a typical night we get about 80% of the Watec detections
simultaneous with the intensifier.
Cheers, Rob
I was curious how well the 902-h was working for you because I'm about to
buy a camera, and have considered:
Watec 902HS
Watec 902H
Genwac GW100N
AstroVid 2000
Right now I'm leaning towards the Genwac GW100N because it has external
controls for Shutter speed, Manual Gain, AGC, Gamma correction. Also their
Web site has a reduced price right now but it's still more expensive than
the 902H.
BTW, there seems to be some kind of trademark and patent infringement
dispute between Watec USA and Genwac. Genwac is some kind of partner or
subsidiary of Watec Japan, they claim that a separate company Watec USA that
is not afiliated with Watec Japan is building unauthorized copies of their
cameras.
It's quite confusing and unclear to me which company is building which
camera. I think that Watec USA is building the 902HS and the 902H is built
by Watec Japan, and the GW100N is built by Watec Japan but sold by Genwac
USA. Is everyone else now confused too? ;-)
Anyway, I'm curious how well the camera is working without an intensifer. I
just got a 25mm Gen 2 intensifier and am doing some experimentation.
Tom Kreyche
-----Original Message-----
From: Rob McNaught [mailto:rmn@...]
Sent: Friday, August 24, 2001 9:57 AM
To: W. Kuneth
Cc: metrec@yahoogroups.com
Subject: Re: [MetRec] Metrec w/WAT-902h 0.0003 lux camera?
Werfried,
Steve Quirk has my camera, but the Hi and Low gain switch is behind the
back plate which you have to remove (4 small Phillips screws if I remember
correctly).
Is your 2.6mm lens for a 1/3 chip or the 1/2inch? I got a lot of vignetting
when I used my 2.3mm for a 1/3 inch CCD.
Cheers, Rob
Robert H. McNaught
rmn@...
-----------------------------------------------------------------------
MetRec Homepage : http://www.metrec.org
MetRec Download sites:
http://www-i6.informatik.rwth-aachen.de/I6/Colleagues/molau/software/metrechttp://ftp.imo.net/pub/software/metrec
-----------------------------------------------------------------------
To unsubscribe from the MetRec info list, send a blank message to
metrec-unsubscribe@egroups.com, or visit www.e-groups.com/list/metrec
-----------------------------------------------------------------------
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
On Mon, 27 Aug 2001, Werfried Kuneth wrote:
> The gain and ALC settings are available direcly on the outside of my 2.6mm
> lens. My questions is if you changed anything with these "gain" and "ALC"
> settings, or did you leave anything in original condition?
Sorry Werfried, I totally misunderstood. We don't use gain control on the
lens, in fact our lens is totally manual aperture setting. Unless the lens
is designed for a 1/2 inch chip, it will certainly produce vignetting. It
wouldn't make sense to market a 1/3 inch lens that had a nearly flat
illumination out to a 1/2 format. I'm certainly in the market for a 2.6mm
(or wider) lens for a 1/2inch chip. Are you sure that there isn't a
switch behind the back plate to toggle between Gain Hi and Low? This is
different from the automatic gain control or lens iris control. I'd assume
you are using the same PAL model as me.
Cheers, Rob
Initially I just had the gain set to Hi with automatic gain control off.
However as Steve's setup is basically automatic, we thought about running
it from evening twilight/daylight into morning twilight/daylight and set the
gain control to automatic. This was fine until some mornings it was partly
cloudy at sunrise, and there were thousands of MetRec cloud detections!
Now, Steve doesn't let it run into daylight. We alter the FlashThreshold
(or whatever the parameter is) depending on the liklyhood of cloud and
moonlight, but the morning weather isn't always predictable. We use a much
lower value for this parameter for moonlit cloud, but on a moonless night,
the clouds are invisible, it being a dark site, so we put the parameter
way up, so very bright meteors in the field aren't ignored as flashes.
Robert H. McNaught
rmn@...
Werfried,
Steve Quirk has my camera, but the Hi and Low gain switch is behind the
back plate which you have to remove (4 small Phillips screws if I remember
correctly).
Is your 2.6mm lens for a 1/3 chip or the 1/2inch? I got a lot of vignetting
when I used my 2.3mm for a 1/3 inch CCD.
Cheers, Rob
Robert H. McNaught
rmn@...
Hello Group,
Please is anybody using the Watec Wat-902h camera?
I use it with a 2.6mm/F1.6 lens, no intensifier. Metrec performs quite well
now, after some adjustments suggested by Sirko.
But what about the camera settings:
There are 2 controls at the lens:
the left control, called "Level" is at 50% between "L" and "H"
the right control, called "ALC" is at 30% from "P" to "H"
There is a switch at the camera: Shutter on and off, which I have in "off"
position.
Can I adjust anything, or leave it as it is?
Any help is appreciated
Thank you in advance
werfried kuneth
That would be wonderful! I'd urge one slight piece of caution regarding
_interpreting_ such a movie. To correctly interpret motions, one has to
consider the _absolute_ motion of the head itself, something I'm sure Pavel
is fully aware of. Both the head and fragments experience variable
deceleration, so the position relative to the head is not a simple
relationship.
The technique will probably be best if the intensifier intensity could
be cranked high enough to bring the video camera's electronic shutter into
play. (Don't try this at home without parental supervision)! The shorter
exposures of the video frames for bright light sources tend to freeze the
action, without the smearing of the object's motion. I notice this
particularly when I run a normal video in daylight. No meteors yet, but the
birds appear as a succession of perfect snapshots, not the blur I get with
birds (mostly bats) at night. (Actually I may have had a daylight meteor;
three "dots" that were too fast for an unresolved aircraft.)
I've recorded a dozen or so meteors that disintegrate to dust, but two nights
ago had a rather nice fragmenting meteor, with the fragment decelerating
dramatically and diverging slightly to the side. I'll look at it after
MetRec operation stops tonight. I think this is my 21st night of operation
in August, out of 24!
Cheers, Rob
Robert H. McNaught
rmn@...
Hello folks,
at the Meteoroids conference early August Pavel Spurny of
Ondrejov observatory presented an impressive meteor movie. It was similar
to our meteor bands, but centered at the head of the meteor. This way
changes in the head became much better visible.
I thought that this feature is really useful and implemented it in the
last two days. It is indeed fun to observe how especially long-lasting
meteors evolve. So I did not want to let you wait for that until the next
release of MetRec. If you wish, you can download the new BND viewer
(showbnd.exe) from the two servers. To show this head-centered animation,
you must have a meteor band (*.bnd), a sum image (*.bmp) and the meteor
data file (*.inf).
All the best,
Sirko
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www-i6.informatik.rwth-aachen.de/Colleagues/molau *
**************************************************************************
Some time ago I commented on problems I was having with the Raw Image
going very bright often for some hours at a time (if not noticed). The
cause of this problem appeared not to be in the intensifier, and I believed
the input video signal was okay.
When it happened tonight, I tried someting different. The video camera
was switched off for several seconds and voila, problem solved. It could
still be a problem within the capture card, but at least I have a means
of dealing with it rather than turning the gain on the intensifier way
down, with a resulting loss of meteors.
Regarding the gain of the intensifier, although I use a 0.01 lux security
camera to image it, the intensifier seems very bright to produce an
acceptable image in MetRec (after suitable adjustments of brightness
and contrast). How would others describe the intensifier output
intensity?
Cheers, Rob
Robert H. McNaught
rmn@...
Hello friends,
the active observers among you will have noticed the new feature of
RefStars, that it remembers the coordinates of the center of fov from the
last reference image you measured. Some of you have complained that
orientation was easier before when RefStars always started at Orion.
In order to make life easier I have added the option, that you can jump at
every time during the alignment of the star map to three well-known
regions: CTRL-O -> Orion, CTRL-U -> Ursa Major and CTRL-X -> southern
cross. If you need this feature, you can download the updated refstars.exe
as usual. In addition, refstars with not keep the right ascension and
declination from the last measurement, but the altitude and azimuth. In
other words: If you grab the reference image 3 hours later at the next
day, RefStars will correct for the change in siderial time.
Cheers,
Sirko
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www-i6.informatik.rwth-aachen.de/Colleagues/molau *
**************************************************************************
Sorry, but it happened again: By fixing one minor bug in MetRec I
introduced another one ... :-(
It affects only observers who use the Cuno time inserter (i.e. who work
with TimeBase = 2). In the case that your observation starts after local
midnight, but before midnight UT, the date will not be corrected properly
at midnight UT.
I've just uploaded a corrected metrec.exe file.
Cheers,
Sirko
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www-i6.informatik.rwth-aachen.de/Colleagues/molau *
**************************************************************************
Hello folks,
the new version 3.4 of MetRec has just been uploaded to the two sites
ftp://ftp.imo.net/pub/software/metrec and
http://www-i6.informatik.rwth-aachen.de/Colleagues/molau/software/metrec.
As always, I suggest you download it a.s.a.p. I have used and tested it myself
in the last weeks and did not have any problems. You can download either
individual files, or the full software package as an self-extracting archive
(install.exe).
There are no major changes with respect to the previous version, but following
your suggestions a number of minor features have been added to make the work
even more convenient, and a bug in the timing routine has been fixed.
Here is a short list of the modifications:
Grab:
* The brightness and contrast values are saved in two unused bytes of the
BMP header. RefStars reads these values from the reference image and stores
them for MetRec in the reference star file. So the VideoBrightness and
VideoContrast values in the MetRec configuration file have become obsolete.
* The start values for brightness, contrast and frame integration can be
specified in the command line. The new syntax is:
grab {-1 | -2} {-pal | -ntsc} [-full] [-br b] [-con c] [-int i] filename
RefStars:
* RefStars now saves some basic parameters (observing site, center and
diameter of field of view, ...) automatically in a logfile at the end
of a measurement. Next time you run RefStars it will use these old values
as start values.
* So far, the L1O position errors indicated by different star diameters in
the coordinate grid were relative values. If you switched to a different
order of plate constants, the mean squared L1O error for this order was
used as reference to translate position errors into star diameters.
Now the absolute values shown. If you watch the coordinate grid and change
the order of plate constants, the scale is not changed anymore. Thus, you
can directly compare the position errors for different plate constant
orders. If you leave the coordinate grid and activate it later again, a new
scale will be determined according the mean error at the time you switch to
the grid.
* The step size for positioning the star map has been adapted to the
diameter of fov to allow also precise positioning when the fov is very
small.
* If you rotate the field of view, the cursor keys will now still shift
the fov in the given direction making it much easier to locate the star
field accurately.
* Before you leave RefStars you have to pass an extra safety question in
order to ensure that you did not hit ESC by accident.
* Due to the changed content, RefStars can only work with BMP files created
by the new version of Grab, and MetRec runs only with reference star files
created with the new version of RefStars.
* All observing sites with site code 0 got their own IMO code now.
MetRec
* Obsolete VideoBrightness and VideoContrast values (see above)
* The Parameter MaxRecognitionTime has been replaced by RecognitionEndTime.
So no matter at what time of night you start the observation, you can
always finish at dawn without the need to modify the configuration file.
* When the recognition is suspended, you can now modify the brightness and
contrast of the video signal on the fly without the need to leave MetRec.
This is for the case that your camera system cannot cope with large changes
in the image brightness (i.e. moon, twilight). Be aware that this may
introduce errors in the computed meteor brightness - but if the background
changes significantly the brightness values will have systematic erros,
anyway.
* A new parameter AutoConfiguration has been introduced, that sets a number
of parameters to default values as used in the AKM video network:
TimeZone = 0
FrameStackCount = 1
SaveSingleFrames = no
SaveMeteorBand = yes
SaveSumImage = yes
SaveMeteorData = yes
StopDetectionOnSave = no
AutoSubDirectory = yes
FileNameRule = 2
EquatorialCoordinates = yes
CreatePosDatEntry = yes
PosDatHeaderFile = mmddhead.dbf
PosDatDataFile = mmdddata.dbf
You can delete these parameters from your config file when activating
AutoConfiguration. If you leave them and specify different values, they
will be ignored. This helps especially for the PosDat file names, as the
correct name is determined from the date automatically.
So if you do not change the reference star file, you can often reuse
the previous configuration file without changes.
* Especially for our observers far away from Europe the new parameter
DateCorrection is important. So far, MetRec always used the date of the
previous day for file and directory naming if the observation started
between midnight and midday UT (i.e. 20010521, if the observations started
at 20010522, 1:00 UT). This caused confusion for observing sites where midday
UT falls into the local night time hours (i.e. in Australia, Japan). They
can now deactivate the date correction by setting DateCorrection to no.
* The new parameter SaveFlashImage allows you to save video frames where a
flash was detected. The files get the name flashxxx.bmp with xxx being the
flash number. However, this is neither marked in the logfile nor is there
any processing in PostProc. So you have to delete the files manually if
you don't want to keep them. The default value for SaveFlashImage is no.
* The image of the last meteor is displayed in the lower left instead
of the lower right window, so that you may have a look at the meteor and
it's position in the star map at the same time.
PostProc:
* When staring PostProc you can specify the optional command line parameter
-archive. Then MetRec will assume that all files (logfile, PosDat files,
image files) are located in the same directory as the logfile.
This will help you if the directory where your observation is stored is
changed (e.g. in the video database from basedir\yyyymmdd\ to
yyyymmdd\cameraname\).
* Before you leave PostProc you have to pass an extra safety question in
order to ensure that you did not hit ESC by accident.
* You can leave the single band mode (M) by pressing k or d. In this case
the meteor is immediately kept or deleted without the need to wait until
the end of the meteor band.
* PostProc will warn you either if the time of a meteor (i.e. two meteors
in very short succession), it's velocity (<3 deg/s or >35 deg/s) or it's
position error (>3x the mean L1O position error) is suspicious. The
corresponding values are highlighted making it easier to recognize
possible problems.
Last but not least all programs support the hot key combination ALT-S to
create a screen dump at almost any state of the program.
Enjoy the new version,
Sirko
PS: On this occasion I would like to remind you to the registration procedure.
The MetRec package is availabe for free for amateurs, but commercial and
professional observers (e.g. astronomers using MetRec for their profession)
are required to register for their site and pay a one time registration fee
of 500 DM.
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www-i6.informatik.rwth-aachen.de/Colleagues/molau *
**************************************************************************
Folks,
early next week I'll upload the new version of MetRec. That is a good
opportunity to also update the list of observing sites.
If you have already carried out video observations or intend to do so in
the future, and if your observing site is not yet in the distributed
refstars.osc file, please, send me the
* name,
* geographic coordinates,
* altitude, and
* IMO code (if you have one)
of your site(s).
Thanks,
Sirko
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www-i6.informatik.rwth-aachen.de/Colleagues/molau *
**************************************************************************
Hi Rob,
> I've used my Meteor II capture card for around 500 hours since purchasing
> it in February. Recently I've had some problems with the raw image in
> MetRec suddenly almost saturating, as if the brightness and contrast had
> spontaneously increased. Some nights in the last week, several meteor
> detections in a row had this saturated appearance when viewed in PostProc,
> then it returned to normal. My first thought had been that the cause was an
> external light source, or problems with the power supply or the intensifier.
I observed some irregular flashes, too. Even though they are certainly not
as strong as in your case (saturation), they are obvious in the real-time
raw image display and strong enough for MetRec to report a flash. So far I
thought this was a camera/cable problem, but maybe I should run my VCR in
parallel, too, and see whether the signal really contains these flashes,
or whether it is indeed the grabber.
Of course, this requires some clear skies, which has been a rarity here in
Germany in the last three months. :-(
Cheers,
Sirko
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www-i6.informatik.rwth-aachen.de/Colleagues/molau *
**************************************************************************
Hi all,
I've used my Meteor II capture card for around 500 hours since purchasing
it in February. Recently I've had some problems with the raw image in
MetRec suddenly almost saturating, as if the brightness and contrast had
spontaneously increased. Some nights in the last week, several meteor
detections in a row had this saturated appearance when viewed in PostProc,
then it returned to normal. My first thought had been that the cause was an
external light source, or problems with the power supply or the intensifier.
This evening it occurred early in the night and examination of the raw image
directly on a separate video monitor shows that the input image to the PC
is fine and thus the problem is either with the my PC, the Meteor II or
MetRec. Has anyone had such a problem in the past? Guess I should try
reseating the card, as the PC gets moved around a lot.
Cheers, Rob
Robert H. McNaught
rmn@...
Hello all,
The automatic MetRec running batch file generator software now also
includes batches to execute postprocessing and to copying necessary files
to the data\yyyymmdd subdirectory.
http://www.sci.fi/~oh5iy/astro/1.exe
This means the number of daily keystrokes to run and postprocess one
night's observation is reduced by 142 keystrokes (from 150 to 8).
Greetings,
Ilkka
------------------------------------------------
Homepage index: http://www.saunalahti.fi/oh5iy
------------------------------------------------
Hello all,
I prepared a small .exe tool which enables me to start MetRec with 4
keystrokes and very little time when I do the analysis as on-line and in
real time.
The starting key sequence (after booting the PC to metrec directory) is
always this: 1 Enter 2 Enter
It may not work for your timezone and you need to run the PC in UTC, but it
is not my problem.
http://www.sci.fi/~oh5iy/astro/1.exe
Greetings,
Ilkka
------------------------------------------------
Homepage index: http://www.saunalahti.fi/oh5iy
Finally: 501 squares on 144 MHz, took 21 years to get them.
------------------------------------------------
Dear friends,
by chance I found a serious bug in MetRec V3.3, that only occurs in this
latest version.
This bug concerns only those of you who do *not* work with the Cuno time
inserter, i.e. who work with TimeBase = 1 or 3. It does *not* affect
observations with TimeBase = 2.
Due to some stupid programming error the internal clock counted
21h, 22h, 23h, 1h, 1h, 2h, 3h, ...
This has two consequences: All meteors that appeared between 0h and 1h
of your computer time are stored with a time offset of +1 hour and all
equatorial coordinates of these meteors are wrong by the same amount
given your camera was unguided. If you have TimeZoneCorrection set to -2,
all meteors between 22h and 23h will have that 1 hour offset.
I just uploaded a bugfix of metrec.exe which does not contain the error.
You should immediately switch to this new version. In addition, a minor
bug in RefStars was fixed, so you can also download refstars.tyc and
refstars.exe at this time.
If you have observations that contain the error, you can correct them
manually as follows:
* determine which meteors are affected, i.e. which meteors appeared at
0..1h (TimeZoneCorrection=0), 23..0h (TimeZoneCorrection=-1), or
22..23h (TimeZoneCorrection=-2)
ATTENTION: If TimeZoneCorrection=0, for example, then not all meteors
with given times between 1..2h are incorrect, as the following example
demonstrates:
23:58:00 Meteor #3 -> correct
23:59:00 Meteor #4 -> correct
01:00:00 Meteor #5 -> !!incorrect!!
01:01:00 Meteor #6 -> !!incorrect!!
...
01:58:00 Meteor #10 -> !!incorrect!!
01:59:00 Meteor #11 -> !!incorrect!!
01:00:00 Meteor #12 -> correct
01:01:00 Meteor #13 -> correct
* correct the PosDatDataFile entries of these meteors:
- subtract 1 hour from the appearance time
- subtract 15 deg from the right ascencion of meteor begin and meteor end
* correct the files names
- rename the affected files by subtracting one hour
* correct the logfile entries
- subtract 1 hour from the appearance time
- subtract 1 hour from the right ascencion of meteor begin and meteor end
- correct the date and time of the end of observation at the logfile
end, if necessary
* the shower association of these meteors can not be corrected by hand
Sorry for the inconvinience!
Best wishes,
Sirko Molau
PS: It could be that this bugfix is still not 100% clean even though it
was running fine in last tests. Anyway, next week I'll be at a
conference and this was the best I could achieve at 2:30 a.m. this
morning...
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www-i6.informatik.rwth-aachen.de/Colleagues/molau *
**************************************************************************
Dear friends,
some time ago Peter Jenniskens reported problems with MetRec and NTSC
sources, however, without tracing down the problem. Yesterday I finally
had the chance to test the software with an NTSC video source myself, and
no problem whatsoever occured. In other words: MetRec does not only in
theory support NTSC, but also in practice. :-)
Best regards,
Sirko
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www-i6.informatik.rwth-aachen.de/Colleagues/molau *
**************************************************************************
Hello friends,
I recently bought a new computer. This time one of the major issues was to
have an optimal system for MetRec. As I often observe away from my main
site in Aachen I decided for a portable computer. The main problem,
however, is the PCI frame grabber that does not fit into a notebook.
After an intensive internet search I decided for a Compaq notebook with
docking station. It's not really cheap, but the Mini docking station for
Armada notebooks is quite compact and portable.
During the Perseid camp I had plenty of time to test the computer, and I'm
fully satisfied. The system is easy to move, runs stable and fast, and for
observation preparation or post-processing the notebook can be released
from the docking station.
If you are looking for a portable solution and have enough money to spend,
I can recommend you this setup.
Best wishes,
Sirko
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www-i6.informatik.rwth-aachen.de/Colleagues/molau *
**************************************************************************
Dear friends,
just in time for the upcoming Perseids I prepared another update of MetRec.
You should switch to the new version as soon as possible, since it contains
important improvements for observations without the "Cuno time inserter",
and also the directory naming convention has changed.
What are the major differences to the previous version?
* RefStars allows now to measure even faintest stars without problems. You
can enhance the contrast of the zoom image with 'e' and also remove the
crosshair in the zoom image.
* MetRec is prepared for double station observations. If you intent
to do orbit calculations you need to set SaveMeteorData in the config
file to yes. Then MetRec will save in addition to the image(s) a text
file hhmmss.inf with detailed information about the meteors' position in
each video frame. An additional program which I'm currently working on
will allow to combine recordings from different stations, to refine the
measurements, and to compute orbital elements.
As required for double-station observations, an altitude column has been
added to the list of observing sites (refstars.osc). This information
is written to the reference star files created with RefStar, so that
older version of these files cannot be used with MetRec V3.3 anymore
(unless you manually add a line "Altitude 0" in the *.ref file after
Latitude).
* So far meteor velocities for TimeBase != 2 contained larger errors. This
was due to the lack of accurate timing from the PC's internal clock, which
is updated every 1/18s only. I finally found a method to still determine
the current time with millisecond accuracy, so that now there is the precise
time available for every video frame. Hence, the velocity will be as accurate
as if you were using the Cuno time inserter. Still, if you have the
choice, I recommend you to use the time inserter.
* I finally decided to change the AutoSubDir function. If CreateIAPLogfile
is set to yes, it will behave like before as required by the IAP people. If
it's set to no, however, the name of the directory created will be according
to the evening, not the morning (i.e. 20000717 for the night July 17/18). This
is to be consistent with the other file naming conventions (logfile,
config file, reference star file, ...) used within the AKM network.
In case you have already many directories with the old names and do not
want to rename all of them by hand, I put some gawk scripts to the temporary
directory
http://www-i6.informatik.rwth-aachen.de/Colleagues/molau/tmp
They create a batch file tmp.bat that corrects all subdirectorys in the
current directory, and all logfiles they contain (i.e. correcting the line
"Creating auto-subdirectory '...' ok!").
Copy gawk.exe, rename.awk, scandir.awk, autodir.awk and runme.bat into your
data directory and start runme.bat.
It creates the file tmp.bat with the corresponding DOS commands.
!!CHECK THIS FILE CAREFULLY BEFORE STARTING IT!!
I have tested the scripts on my own database and they worked without problems.
However, I do not want you to lose any data. I suggest you copy a part
of your database to a temporary directory and run a test there first. After
the renaming postproc should have no problem in parsing your logfile as
before the renaming, and the logfiles should all have the original size.
!!RUN THE TMP.BAT SCRIPT ONLY ONCE! IT WILL DELETE ITSELF AFTER EXECUTION!!
* Now MetRec displays not only all meteor plots, but also optionally the
position of only the last detected meteor among the stars (type 'l' during
recognition). This should help you to check whether the coordinate conversion
works correctly by comparing the position of the meteor in the last meteor
image with the plot.
* For those of you who have not yet worked with MetRec, a number of screen
shots are provided in the screen subdirectory, and explained in the readme
files. This should help to get started easier.
As usual, you will find the latest version 3.3 of MetRec in my homepage
http://www-i6.informatik.rwth-aachen.de/Colleagues/molau/software/metrec/
and at IMO's ftp server ftp://ftp.imo.net/pub/software/metrec.
Enjoy August!
Sirko
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www-i6.informatik.rwth-aachen.de/Colleagues/molau *
**************************************************************************
Hi Sirko,
komme gerade von mehreren Dienstreisen zur"uck und habe MetRec3.2 noch
nicht ausprobiert. Von Deiner Beschreibung her aber sehe ich dass Du mal
wieder super sachen gemacht hast! Gratuliere!
Laffy
At 08:13 AM 4/17/00 +0000, you wrote:
>
>
>Dear friends,
>
>it's been a long time without MetRec updates :-), but now the new version 3.2
>is available at IMO's ftp server and my own homepage:
>
>ftp://ftp.imo.net/pub/software/metrec
>http://www.informatik.rwth-aachen.de/I6/Colleagues/molau/software/metrec
>
>The main changes are as follows:
>
>* There was an error when saving very long meteor bands, which is fixed now.
>In addition, I wrote a small tool ShowBND which displays meteor bands, so
>that you do not have to use PostProc for that. The only parameter is the
>name of the meteor band image.
>
>* I tried to implement a cloud detector, but that was more difficult than
>I thought. When the video camera's AGC is activated, clouded skies look
>remarkably similar to clear skies with only 'a few missing stars'. To detect
>stars at only little computing costs is non trivial.
>Anyway, the biggest problem usually occurs if could patches drift through
>the fov. Then the flatfield will be smoothed strongly, and behind the cloud
>numerous false detections occur. To cope with that, I introduced the
>FlatFieldFlooring parameter.
>This ensures that the flatfield can never become smaller than the value
>you specify. Normally you can set this parameter to zero, but in the presence
>of clouds you can set it to 10 or 20. There will still be false detections,
>but their number should reduce then.
>
>* The brightness computation for meteors was improved. I realized that the
>main error came from the brightness measurements for reference stars. When
>a star close to a bright edge of the fov was measured, the pixel sum became
>ways too large. The first thing I did was to add the option in RefStars
>to measure the position of a reference star, but not it's brightness. So
>if you want to measure a star near the edge (or a double star), you press
>'x' instead of 'enter' and get it's position without the brightness being
>measured.
>In addition, the brightness calculation routine in MetRec was improved.
>It's not yet perfect, but the values should be more realistic than before.
>
>* I found a bug in the computation of the mean meteor path, that occured
>only very rarely. PostProc also made some trouble if there were more
>than 1000 meteor entries in a logfile. Both bugs are fixed now.
>
>* If you measure a large number of reference star, it is sometimes
>difficult to find misidentified stars. Now there is a help: If you switch to
>the coordinate grid in RefStars, where you see the stars and their errors
>as before (the bigger a star, the larger it's L1O error). If you then hit
>the cursor keys you can move the crosshair and place it at the bad star.
>Then you only need to leave the coordinate grid display and press 'd' to
>delete the star, since it's the one closest to your crosshair.
>
>* The ReferenceDate, -Time, and OperationMode entries are now entered in
>RefStars and saved together with the reference star file. The corresponding
>MetRec configuration file entries are not required anymore. This ensures
>that you are always using the right reference time & date.
>
>* When starting RefStars you can optionally supply your MetRec input mask.
>Then only stars inside that mask may be segmented automatically.
>
>* The meteor shower list was updated. Shower that are active over several
>months were split into different entries to ensure that their proper position
>is used.
>
>* The 'Time Jump' warning occured too often in the logfile. That's fixed now.
>
>* Finally, a new operation mode was implemented: Beside guided and unguided
>MetRec can now also cope with drifting recordings. What I mean is not
>arbitrary drifting like in an airplane, but if your mounting was not properly
>aligned or if it was too fast or slow. For that you have to grab two
>reference
>images, one from the begin and one from the end of your observation. The
>first
>image is measured as usual with RefStars. Then you have to identify a few
>stars in the second image, and RefStars will compute how your mounting was
>misaligned and at what speed it was running. Finally, MetRec will correct
>position measurements for this drift.
>
>That's all for the moment. Questions, comments, and suggestions as always via
>e-mail to me.
>
>Best wishes,
>Sirko
>
>PS: The following files need to be downloaded, if you are upgrading von
>version 3.1: metlogo.bmp, metrec.cfg, metrec.exe, metrec.shw,
>postproc.exe, readme.txt, refstars.exe, refstars.osc, showbnd.exe
>
>--
>**************************************************************************
>* Dipl.-Inform. Sirko Molau * *
>* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
>* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
>* * *
>* phone: +49-241-8021615 * Shakespeare *
>* fax : +49-241-8888219 * *
>* email: molau@... * *
>**************************************************************************
>* www : http://www.informatik.rwth-aachen.de/I6/Colleagues/molau *
>**************************************************************************
>
>
>
>
>------------------------------------------------------------------------
>Enter to WIN one of 10 NEW Kenmore Ranges!
>Only at sears.com
>http://click.egroups.com/1/2677/3/_/154670/_/955959202/
>------------------------------------------------------------------------
>
>To unsubscribe from the MetRec info list, send a blank message to
>
>metrec-unsubscribe@egroups.com, or visit www.e-groups.com/list/metrec
>
>-----------------------------------------------------------------------
>
>
>
>
----------------------------------------------------------------
Detlef Koschny email: dkoschny@...
European Space Agency
ESTEC Sci/SO
Keplerlaan 1 phone: +31-71-565-4828
NL-2201 AZ Noordwijk ZH fax: +31-71-565-4697
----------------------------------------------------------------
Dear friends,
it's been a long time without MetRec updates :-), but now the new version 3.2
is available at IMO's ftp server and my own homepage:
ftp://ftp.imo.net/pub/software/metrechttp://www.informatik.rwth-aachen.de/I6/Colleagues/molau/software/metrec
The main changes are as follows:
* There was an error when saving very long meteor bands, which is fixed now.
In addition, I wrote a small tool ShowBND which displays meteor bands, so
that you do not have to use PostProc for that. The only parameter is the
name of the meteor band image.
* I tried to implement a cloud detector, but that was more difficult than
I thought. When the video camera's AGC is activated, clouded skies look
remarkably similar to clear skies with only 'a few missing stars'. To detect
stars at only little computing costs is non trivial.
Anyway, the biggest problem usually occurs if could patches drift through
the fov. Then the flatfield will be smoothed strongly, and behind the cloud
numerous false detections occur. To cope with that, I introduced the
FlatFieldFlooring parameter.
This ensures that the flatfield can never become smaller than the value
you specify. Normally you can set this parameter to zero, but in the presence
of clouds you can set it to 10 or 20. There will still be false detections,
but their number should reduce then.
* The brightness computation for meteors was improved. I realized that the
main error came from the brightness measurements for reference stars. When
a star close to a bright edge of the fov was measured, the pixel sum became
ways too large. The first thing I did was to add the option in RefStars
to measure the position of a reference star, but not it's brightness. So
if you want to measure a star near the edge (or a double star), you press
'x' instead of 'enter' and get it's position without the brightness being
measured.
In addition, the brightness calculation routine in MetRec was improved.
It's not yet perfect, but the values should be more realistic than before.
* I found a bug in the computation of the mean meteor path, that occured
only very rarely. PostProc also made some trouble if there were more
than 1000 meteor entries in a logfile. Both bugs are fixed now.
* If you measure a large number of reference star, it is sometimes
difficult to find misidentified stars. Now there is a help: If you switch to
the coordinate grid in RefStars, where you see the stars and their errors
as before (the bigger a star, the larger it's L1O error). If you then hit
the cursor keys you can move the crosshair and place it at the bad star.
Then you only need to leave the coordinate grid display and press 'd' to
delete the star, since it's the one closest to your crosshair.
* The ReferenceDate, -Time, and OperationMode entries are now entered in
RefStars and saved together with the reference star file. The corresponding
MetRec configuration file entries are not required anymore. This ensures
that you are always using the right reference time & date.
* When starting RefStars you can optionally supply your MetRec input mask.
Then only stars inside that mask may be segmented automatically.
* The meteor shower list was updated. Shower that are active over several
months were split into different entries to ensure that their proper position
is used.
* The 'Time Jump' warning occured too often in the logfile. That's fixed now.
* Finally, a new operation mode was implemented: Beside guided and unguided
MetRec can now also cope with drifting recordings. What I mean is not
arbitrary drifting like in an airplane, but if your mounting was not properly
aligned or if it was too fast or slow. For that you have to grab two reference
images, one from the begin and one from the end of your observation. The first
image is measured as usual with RefStars. Then you have to identify a few
stars in the second image, and RefStars will compute how your mounting was
misaligned and at what speed it was running. Finally, MetRec will correct
position measurements for this drift.
That's all for the moment. Questions, comments, and suggestions as always via
e-mail to me.
Best wishes,
Sirko
PS: The following files need to be downloaded, if you are upgrading von
version 3.1: metlogo.bmp, metrec.cfg, metrec.exe, metrec.shw,
postproc.exe, readme.txt, refstars.exe, refstars.osc, showbnd.exe
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www.informatik.rwth-aachen.de/I6/Colleagues/molau *
**************************************************************************
Dear friends,
in these minutes I'm uploading a new version of MetRec to the two
servers www.imo.net and www.informatik.rwth-aachen.de. Is contains a
number of new features and improvements:
* Minor bugs in PostProc and ClockPos were fixed.
* RefStars has become an automatic starfinder: Before you choose the field of
view, a segmented image is displayed. You need to choose the right threshold,
so that the stars are optimally detected. When you later identify
reference stars, the cursor jumps automatically to the detected stars
beginning with the brightest. So, essentially all you have to do is to
verify the detected stars and the corresponding star catalog entries, which
makes the measurement of reference stars even more comfortable.
* The brief jumps of the recognition threshold after a flash or other events
have been removed. However, in return MetRec react relatively sensitive to
clouds now.
* A new parameter FrameBufferCount defines how many frames MetRec
shall keep in it's internal ring buffer. If you have enough memory
(>16 MB) you should choose the highest value of 50 frames,
which means that meteors lasting up to two second can be saved completely.
* You can temporarily suspend the recognition in MetRec by pressing CTRL-U,
and resume with CTRL-R. A nice feature I have 'stolen' from Pete Gural's
MeteorScan software. It is especially useful if you want to interrupt
recognition (i.e. because of clouds, etc.) without the need the restart the
software afterwards.
* The upper left window may show either the mean subtracted image (as before)
or only those pixels, which are above the internal threshold (ROIs). The
display can be modified at run time by pressing I or R.
* MetRec now automatically computes the effective observing time, i.e.
the time at which recognition really takes place. This value is not only
displayed, but also printed together with the meteor shower counts and
other values in the new observing summary at the end of each logfile. So,
preparing your monthly observing report has become much easier now.
* So far you had only the chance to save all single frames of a meteor
and/or a sum image. The first option was rarely used, since it produces
quite a lot of data. However, the sum image does not preserve the dynamical
aspect of the meteor. This is why I have implemented meteor band saving
as a third option, similar to Pete's MeteorScan and what Chris suggested
at the last IMC (configfile entry SaveMeteorBand). The idea is, that not
every single frames is saved completely, but only the region that
contains the meteor. I have been testing this feature for some weeks now,
and it is extremely useful. On average, the meteor band image (extension
.BND) is smaller in size than the sum image, but it preserves very well
the true appearance of the meteor. The bands can be dislayed with
PostProc.
* The call syntax of MetRec has changed slightly to
MetRec configfile logfile [com1 | com2 | lpt]
That is, the logfile is now always written, but in addition the output can
optionally be sent to either a serial or the parallel port. However,
there still is a problem with the communication over the serial port,
which has to be fixed in the future.
* Finally: All hotkeys are displayed by the screen saver. So if you
forgot which key to press to see the last image or the meteor plot, just
press any key to activate the screen saver and read the instructions.
Enjoy the new version and have a most successful Leonid observation!
Best wishes,
Sirko
PS: At each server you will find a file history.txt, which lists all recent
software updates. So if you wish to know whether you are still using the
latest version of MetRec you can find that out without the need to download
all files.
--
**************************************************************************
* Dipl.-Inform. Sirko Molau * *
* RWTH Aachen, Lehrstuhl fuer Informatik VI * __ *
* Ahornstr. 55, D-52056 Aachen, Germany * " 2B v 2B " *
* * *
* phone: +49-241-8021615 * Shakespeare *
* fax : +49-241-8888219 * *
* email: molau@... * *
**************************************************************************
* www : http://www.informatik.rwth-aachen.de/I6/Colleagues/molau *
**************************************************************************