The issue is control over the operating system's scheduling
decisions. There are real-time versions of Linux that are comparable
in this dimension to the firmware running in a TNC; given sufficient
CPU horsepower, a Pactor-2 or Pactor-3 implementation on realtime
Linux is feasible.
The
There are variants of Linux with pre-emptive scheduling; this enables
guaranteed real-time response. Linux-based cellphones use this
approach, for example.
See http://en.wikipedia.org/wiki/Hard_real-time
Dave, AA6YQ
--- In digitalradio@yahoogroups.com, Chris Jewell ae6vw-
[EMAIL
GM Dave,
Yes, a technical item up for discussion.
I must assume that you have never done any Near Real Time Systems
development such as ATE or Industrial Control applications under MS-Windows?
I on the other hand have and the WIN32 API beginning all the way back
with Windows NT implemented a
Precise timing isn't the issue, Steve. WinWarbler originally used
GetTickCount() and QueryPerformanceCounter() in its CW generation
code, but a high-resolution timer using the multimedia library is
sufficiently accurate and more convenient. The problem is thread
scheduling. WinWarbler uses
Hi Dave,
I mentioned AMTOR as its timing is more robust that PACTOR I.
As I have stated to the MARS-ALE users, the future version of that
tool when PACTOR I support is added ont he PCSDM will pretty much own
the OS, not a problem for our purposes as that one program running is
our only
Agreed, there's no problem if you can own the OS; but on an end-
user's Windows PC, you can't do that.
73,
Dave, AA6YQ
--- In digitalradio@yahoogroups.com, Steve Hajducek [EMAIL PROTECTED]
wrote:
Hi Dave,
I mentioned AMTOR as its timing is more robust that PACTOR I.
As I
Chas, the term modem is a contraction of modulator
and demodulator; it purpose is the bidirectional conversion of
digital signals to analog signals. There are many different kinds of
modems, employing different modulation techniques to achieve
different speeds and error rates over different
