On Sat, Apr 29, 2000 at 05:40:43PM -0700, Shawn T. Rutledge wrote:
>
> 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.
I agree to a point, but if I'm not mistaken nearly all the radios
capable of computer control receive their data through an RS-232
port. Now, the rigs themselves have a variety of of internal
levels and require interfaces for RS-232 communication. Probably
the most important consideration is the "non-standard" data format
using 2 stop bits and the like. Now, whether the rigs' APIs are
fully documented is another story. I have the supplied computer
interface commands for both the TS-850S and the FT-890 that came
with each radio's owners manuals. I've not ever played with them
to see if they work as described.
> 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.
A good idea.
> 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.
I agree it's bad, but I wonder how many would lug a UPS to the Field
Day site? Improved filesystems will help in this regard. Unfortunately,
just because one is using a laptop doesn't mean a power failure won't
occur. For example, I need to use a port replicator on this Thinkpad
760ED in order to use an external keyboard. To power the laptop off of
AC, the unit has to be fed through the replicator and if that power
is lost, the laptop dies as the battery won't take over. So, it's
still a problem.
> 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...)
I'm not aware of contest authorities not accepting logs generated
per their format, but then I'm a casual 'tester. I do know that
as of the November Sweepstakes 2000, ARRL will require logs to be
submitted in their new Cabrillo format. Apparently, all the major
DOS/Win logging program authros have agreed to support this format
by then.
One question about a web browser based logger, will such an application
require a running web server daemon (is that too obvious of a question)?
I would love to see a completely modular system, but I understand this
adds a certain level of complexity. Yet, if hams can figure out the
new rigs, surely they can install a few more software packages...right?
Right? RIGHT?
;-)
73, de Nate >>
--
Wireless | Amateur Radio Station N0NB | "None can love freedom
Internet | [EMAIL PROTECTED] | heartily, but good
Location | Wichita, Kansas USA EM17hs | men; the rest love not
Wichita area exams; ham radio; Linux info @ | freedom, but license."
http://www.qsl.net/n0nb/ | -- John Milton
