On Sat, Apr 29, 2000 at 07:08:44PM -0500, Nate Bargmann wrote:
> Also, mentioned in this thread was rig control. IIRC, some months
> back a post was made to the list of someone writing a library for ICOM
> rig control. Perhaps this could be extended to other models. I think
There is only one listed in the ham-howto, and it's for a particular
Icom radio.
> it would be a good idea to develop such a library so that any programmer
> doesn't have to re-invent the wheel each time rig control is needed.
Unfortunately the radio manufacturers seem to like to reinvent the
wheel... too bad they're not all plain RS/232 with a standard control
language. I agree the software layer should be abstract in spite
of it, but it has the potential to get messy if a lot of different
hardware must be used to interface to all the radios. Probably just
means another layer should be used... SANE (the scanner abstraction
layer) would provide a pretty good example. There is SANE itself,
and there are plugin drivers for each scanner. Some are parallel,
some are SCSI.
>
> Finally, I think the use of a real database like PostgreSQL is a great
> idea for a general logging program. However, for contesting a more
> specialized approach may be better. I had rolled around in my mind
> some time back of a contest logger using Berkeley DB for the database
> backend. I don't know squat about databases and programming, so this
> may be a lousy idea. That said, it would seem a contest logger needs
> to be optimized for speed and data integrity. We all know how the
For speed, the program should be multithreaded; each new log entry
gets enqueued in one thread while another thread reads them from the
queue and puts them in the database.
> lights go out on Field Day or the power fails during the big 'test.
That's bad for a Linux machine anyway, not just for your contest. Use
a UPS or a laptop with charged batteries. Also, transaction-capable
databases might help (but I don't have experience using the freeware
databases this way, so don't know how robust the implementation is
if they have transactions at all). Also, reiserFS or some other
journaling filesystem would help.
> One thing about CT is that I've never lost data on any completed and
> entered QSOs due to power failure and it's happened a lot! Also, it
> would be nice (essential?) for the contest logs to be read by the
> general log program for award tracking and the like.
After they're in the database, arbitrary output formats could also
be produced. If the contest authority finds out how you do this and
doesn't like the indirectness of it for some snooty reason, then hook
up a dot-matrix printer and modify your program to also spit out
timestamped entries on paper as they are entered. That should be in
a separate thread too, obviously. (Reminds me of the point-of-sale
software I wrote a few years ago...)
--
_______ Shawn T. Rutledge / KB7PWD [EMAIL PROTECTED]
(_ | |_) http://www.bigfoot.com/~ecloud [EMAIL PROTECTED]
__) | | \________________________________________________________________
Get money for spare CPU cycles at http://www.ProcessTree.com/?sponsor=5903
