Carl Clawson wrote:
1) Have the computer generate the CW and waggle some lines to the radio.
This is problematic because no modern operating system has deterministic
timing. You never know when the OS will decide to go do something else for a]
I think you mean consumer operating system for PCs, but even that is not
entirely true.
Whilst MS-DOS, as long as you restrict the TSRs, behaves more like an
I/O library than an operating system and therefore it easy to control
the timing, there are special operating systems around, intended for
embedded systems, which do have tightly controlled real time responses.
Even Windows has real time priorities, that have absolute priority over
normal programs, and there are real time extensions to Linux. On Linux,
writing a custom device driver is also easy, as long as you are happy
writing state machine type code.
One of the key applications for domestic consumer Windows is multimedia
and Windows has a special multi-media timers mode that gives it a timing
resolution of 1ms. I'd suspect there are lot of people who would claim
that they could detect a misplaced note. A lot of Linux systems also
run the clock at 1kHz. If you are in the sort of single user single
application environment that you get with MS-DOS, Linux allows you to
busy idle and read the time to microsecond, or better accuracy.
The remaining problems are interrupt latency and inappropriate hardware
interfaces. Windows and Linux can overrun clock interrupts at 1kHz,
particularly if you use IDE drives without enabling DMA. The solution
is to be careful with how you configure device drivers and to avoid
actively using problem drivers. By inappropriate devices, I
particularly mean USB.
Another possible own goal would be using programming languages that are
designed for use by semi-skilled programmers in non-realtime
environments. These can often go into a garbage collection phase, where
they compact their internal memory usage, which can take some time.
That tends to include all languages called "Basic". .NET and Java also
suffer from this problem, even though Java and C# tend to be associated
with more skilled programmers. If you want good real time performance,
you need to use the lower level languages that are common in open source
software, but disliked by most programming managers, because they
require more skilled staff.
while, and you get choppy code if you're unlucky. You also need a circuit to
key from the parallel port, or use DTR/CTS on serial, which is OK until you
reboot your computer and it keys up your radio. Plus, AFAICT you can get
paddle inputs only via a parallel port. (Seems like a serial port could take
A lot more people can use a keyboard at over 40 wpm than can use a
paddle at those speeds! Paddle input isn't going to be a priority.
paddle input on DSR & RTS, but I don't recall ever seeing that. Probably
because you'd need to add in both + and - power supplies. The advantage of
the parallel port is that you can set a pin to +5 V to power your paddle
input circuit.)
As it's not a priority, you wouldn't expect many choices. However,
stealing supply voltages from RS232C outputs is no problem.
--
David Woolley
"The Elecraft list is a forum for the discussion of topics related to
Elecraft products and more general topics related ham radio"
List Guidelines <http://www.elecraft.com/elecraft_list_guidelines.htm>
_______________________________________________
Elecraft mailing list
Post to: Elecraft@mailman.qth.net
You must be a subscriber to post to the list.
Subscriber Info (Addr. Change, sub, unsub etc.):
http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/subscribers.htm
Elecraft web page: http://www.elecraft.com
