[Prev][Next][Index][Thread]

Re: (meteorobs) Counting meteors with a Palm Handheld computer

Chris,
thanks for the encouraging and constructive
feedback.

>is the ideal towards which you should strive. I
>would therefore urge you to
>eliminate half-magnitude estimates.

Hmmm, if you do not like to add any half magnitude
steps, you do not have to enter them. During the
Leonid storm night, I did (of course) not enter
a single half magnitude estimate. Observing
in the following night at ZHR 15 was different.

If you fear accidentally typing key A, just make
the cardboard mask covering the "dangerous" keys
a bit larger and there is no reason to bother with
half magnitude steps at all. Perhaps I'll enter a
line in the program to disable key A if for users
who dislike it.

> Also, you should add an "Oops"
>button so that an observer can invalidate an
> improperly entered datum.

This is already implemented (Key B).

>Lastly, I'd suggest that you not throw away any
> data. I think that your
>report should take the form of a list of entries
>with a standard code,
>rather like this:
>
>Dec 13 01 22:15:47 GEM +3

I agree. In the current version I don't throw away
any of the mentioned data.

In the current format, these data will read like
this:

20011213221002
...
221547,gem,3,
...

The first line in the memo file (which
is also its file name)
means that the observation started
on DEC 13, 2001, at 22:10:02
On 22:15:47 a Geminid of +3 magnitude occured.

Delimted ASCII has the vast advantage that
software
to read the data is very easy and safe to make.
Also I tried to keep with the Leonids
in mind  the format as compact as possible.
A memo in Palm OS is restricted to 4Kbyte, these
are 300 meteors
of so. Although the program creates a new one once
the memo is full, I did not want to end up
with many files containing few meteors. Therefore
I eliminated the (redundant) date
stamp for individual meteors (the meteors of one
obveration will always be analysed together, and
the
necessary information timing the observation
will be in the first line of the file).

Thus I would not like to totally change that
format, at
least not on the level of the Palm. I can imagine,
however, to modify the program that currently
converts the
data into Meteor Companion format that it creates
other
desired formats too, including the more readable
one you
are suggesting or possibly any future standard IMO
format.

>I realize that
>this is not the IMO standard format, but I would
hope that the IMO would
>create a new alternate format for reporting data.
The old format was
>optimized for ease of data entry with paper and
pencil. Since we now have
>technology that vastly simplifies this process,
the IMO should make it
>possible to accept such data. We wouldn't have to
worry about bin sizes;
>just report the real data.


Perhaps, provided computer-recording becomes
more popular, IMO should accept raw individual
meteor data
supplied in a to-be-definded standard format. I
think however that, at the moment, there is a
problem is on a
different level, since a digital standard for old
style date (e.g. bins,
magnitude distributions, etc) does not exists. The
result is
that people email their data to Rainer Arlt, and
he and his
friends  T Y P E (!!!) all the  Leonid data
(partly 1-min intervals) into
their computers, which is a tremendous amount of
work. He currently
asks for help in this. So I think that not only a
format for
individual (unprocessed) meteors should be
definded, but in a first step
one for the old style  data, because this will
distribute the labour
involved in hacking the data into a computer
keyboard is distributed on
many shoulders. This approach was very successful
in the comet
observers community.


Cheers
Hartwig







The archive and Web site for our list is at http://www.meteorobs.org
If you are interested in complete links on the 2001 LEONIDS, see:
http://www.meteorobs.org/storms.html
To stop getting email from the 'meteorobs' list, use the Web form at:
http://www.meteorobs.org/subscribe.html
Follow-Ups: