>From a programming point of view, I have slightly different ordering for the
"quality" of the various serial protocols for rig control. From best to
worst:
1. Kenwood
All of them are the same. There's no need for the user to tell the software
which model. All functions that I've ever thought necessary for rig control
are supported.
2. Icom
One can argue whether the rig-specific address byte is an advantage (allows
multiple rigs to be bussed together) or a disadvantage (forces the user
to tell the software which Icom rig is there). But its main disadvantage
is two missing functions:
a. No control of PTT--saves wiring in the case of using a commercial
sound board for a digital voice keyer.
b. No way to retrieve both the transmit and receive frequencies when
the software discovers the rig is operating split--useful when your
logging software wants to record all the particulars of your contest
QSOs as you make them without any user intervention.
3. Ten Tec
The latest Ten Tecs use Icom-compatible software and include a new command
to activate the PTT, so are actually better than Icom by my standards.
The Ten Tec Omni V (early models had defective controller software that
crashed on any query) and Paragon had unique protocols that are hard to
support. A working Omni V takes as much as 15 seconds to command to a given
frequency, though, because there is no direct way to set the frequency. The
software has to tune the rig as if it were using the front panel.
4. Yaesu
No two are the same. When writing Windows software, the worst offender is
the FT 747 because it demands a 50msec delay between characters sent from
the host. Under 16 bit Windows, this requires LOTS of rather obscure looking
code because the delay has to be threaded from timer message to timer message
--it is not kosher to lock down the CPU for 50msec under Windows. Win32
(available now in Windows NT and later this year for a lower price in
the code named Chicago release) has system threading support which would
allow much simpler and obvious code to accomplish the 50 msec delay, but
I estimate that only about 1 in 100 hams is interested in running in the
now-three-year-old 16 bit Windows. It will be 3 to 5 years before
there is any incentive for supporting ham software in the 32 bit world.
More than you ever wanted to know about rig control?
Wayne, W5XD
|