On 7/26/13 4:41 AM, briana wrote:
Ever since WINxp arrived on the scene hams who send code via computer
to radios via parallel, serial or usb ports (with serial port converters
following) have seen the latency issue in spades. We're talking about
effective baud rates less that 50. 3-4 milliseoond variable latency
changes making the code nearly unreadable. The killer is that the
latency changes randomly.
Previous to WINXP one could do direct writes to the ports under software
controlled timing. All was good.
The solution for WINXP was to bypass WINDOWS handling of port data via
a DLL called DLPORTIO
There is a similar one for WIN7. I haven't timed how accurate it is.
However 65 words per min (6 characters/second) code can be sent with no
detectable timing problems.
The simple act of open and closing a set of contacts at precise times
now requires a huge, faxt machine, tons of software and software to work
around the normal software. That's progress?
no.. what it means is that you have a bad system architecture. You
shouldn't be trying to do hard real time on a machine primarily designed
for user interface experience and running office automation tools like
word and excel. It is no more reasonable to expect a modern PC
(primarily a media display device) to do hard real time control than it
is to expect an iPhone to do so, or even a mainframe computer. The days
are long past when a PC is basically a microcomputer with a few limited
peripherals.
Hams have problems because the developers have insufficient budget or
resources to devote the time to writing appropriate code using the
Windows media stack to get the synchronization performance desired.
They're looking for the "quick fix", a'la direct port writes.
Note that real time action in games works fairly well, as does keeping
the video and audio synchronized in various and sundry media players,
even when playing through USB connected devices. Midi sequencers run
just fine with Windows.
So, it's more a matter of spending the enormous amount of time needed to
become facile with the entire multimedia API, all the various hooks and
widgets in Windows, etc. This is a non trivial task, and one that
cannot be done in spare time on the weekends for most people. You
generally need to be immersed in the "windows way" of doing things
(which is exceedingly different from DOS, microprocessor, or Unix) and
understand how it works, and then you need to be using Windows
development tools and have the appropriate libraries, etc. The Windows
ecosystem is quite powerful, but it's different than other ones, so a
life of Unix kernel hacking might give you the general background, but
will result in you fighting with Windows at every turn, because it's
just different.
And, in some cases, moving the timing critical operations off to a
separate device is going to be the wisest plan. The Roland MPU401 Midi
box was one of the first to do this, back in the DOS days.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
