[time-nuts] RS 232

Jim Lux jimlux at earthlink.net
Fri Jul 26 13:06:47 UTC 2013


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.




More information about the Time-nuts_lists.febo.com mailing list