Although there are alternatives, the obvious way to go here is to use an old computer. Any old computer, really, as long as you can keep its RF interference out of the receiver. Even the slowest XT or early Mac would be fine. (If you intend using a Mac do bear in mind that supplies of ready-to-go Mac shareware for observing meteors seem to be pretty sparse, if they exist at all, so you'll be writing your own.)
All your computer really needs is a reliable clock, a few Mb of disk space or even just a floppy, and an operating system that doesn't fall flat on its face twice a day. The last requirement unquestionably rules out Win 95 or 98, which are much too unstable for this kind of application. Use DOS as early as version 3.3 or, if you must use Windows, opt for Windows for Workgroups. Mac Systems 6 or 7 should be fine on older Macs. If you're rolling your own software you'd be crazy not to use Linux. Another advantage of an older OS is that, in the event of a power failure, you can configure your machine to reboot itself in seconds. Display quality is irrelevant, because 99% of the time the monitor won't even be switched on. Low power consumption is important because this device is going to be on all the time. An old laptop running from a float-charged battery would be ideal.
Data logging software is not all that difficult to write, though some folk write it much better than people with my limited programming ability. It needs to record when each event occurs and its duration. This means sampling the digital output of the receiver at regular intervals.
Most observers sample every 10 to 40 mS, which is within the capabilities of even the slowest machines. It's important to save to disk at regular intervals so that a minimum of data lost when (not "if") there's a power failure or system crash. Save your data in a format that doesn't leave you with hundreds of megs of data to wade through each month. It may be fun for the first month, but most people soon tire of unnecessary drudgery. Aim to keep your monthly files under 500K: that way they could be saved on a floppy with room to spare, and then on newer systems you could set your BIOS to turn off the hard disk once the program is running. My software uses 16 bytes to record the time (expressed as the number of seconds after midnight on 1 January 2000) and the length of the burst in milliseconds. This is probably more detail than is needed, but it comes to a couple of hundred kilobytes a month and leaves open the opportunity to analyse the data in great detail should this be necessary. Some other observers record just the number of hits and total duration of reflections in each ten minute period, which is all that NASA's survey requires.
Data
analysis
More talent is needed
for writing data analysis software. Mere mortals can write something to
produce simple monthly summaries such as the one below, while those with
time and talent can create applications versatile enough to show fancy
graphs and hourly distributions using a range of parameters.
|
|
Typical monthly observer's summary, as published in the rec.radio.amateur.space newsgroup
Notes:
1.
Universal time is always used, so you should set the logging computer's
clock to GMT. The observations at the right were collected at a location
located 10 hours ahead of UT.
2.
At 6 am local time you're on the "leading edge" of the globe
as it moves through space, while at 6 pm you're standing on the back porch
looking into the Earth's wake. Therefore there should be a cyclic increase
in meteor activity around 0600 local time (2000 UT at this location),
and a corresponding decrease around 1800 local time (0800 UT). This cycle
is a good way of confirming you really are observing meteors, and not
a neighbour's arc welder in action.
If all the fun of writing your own data analysis software seems like something you could do without, use a spreadsheet to analyse your data. Versions of Lotus 123 are available as freeware these days and have excellent graphing and date manipulation functions.
The most important information to record is, for each ten minute period, how many echoes were detected, what their total duration was in seconds, and the length of the longest echo during that period. This information is best saved in a simple comma-separated variable (CSV) format for importing into a spreadsheet. Part of a typical output file looks like this:
355530,
0.012, 11, 0.2
355540, 0.002,
4, 0.025
355550, 0.003,
5, 0.075
355560, 0.001,
3, 0.025
355570, 0.005,
5, 0.2
355580, 0,
0, 0
355590, 0,
1, 0.025
355600, 0.005,
5, 0.175
355610, 0.001,
2, 0.025
355620, 0.006,
2, 0.35
The
first column shows the start of the observation period in minutes since
midnight on 1 January 2000.
The
second column show the total duration of reflections during that period
in seconds.
The
third column shows the number of hits detected during the period.
The
fourth column shows the duration of the longest reflection during the
period, in seconds.
Alternatives
-
Finnish meteor guru Ilkka Yrjola has made available reliable data logging software for DOS, along with masses of far more useful information than I could possibly provide here.
-
Another good package with useful self-adjustment features is Meteor v.4 , though it helps if you can read French documentation. Its companion analysis package Colorgramme is also available, and this pair may well meet all your needs.
-
R_Meteor is designed to be used with WinRadio cards or sound cards connected to communications receiver tuned to a shortwave AM station. It displays the doppler shifts of ionisation trails and other moving objects that cause reflections. (You can also use it to detect aircraft thousands of kilometres away, but that's altogether another subject.) If you can't find a suitable VHF transmitter to monitor, shortwave techniques could be a good alternative.
[Introduction] [Meteors] [Antennas] [Receivers] [Interfacing] [Data logging] [Links] [Email]