Hi Jim,
You mean to imply no commercial programs ever use "quick fixes"?
It's difference between seat-of-the-pants field engineering and a
theoretical pursuit. There are no humanitarian costs associated with
failure so standards and formal test program and the like aren't required.
Your are right it is a question of market size the $$ that can be
charged for a package rather what could be with enormous effort.
Many ham programs are free or essentially so. There would be no market
for them if they were not. Hams are basically cheapskates.
To say the programs are not sophisticated or the coders non-skilled is
simply wrong. I suggest you in particular look at the free N1MM code and
what it does. It does indeed use the quick fix.
The other fact is that hams use their PC's for many of the everyday
applications you describe as well. Nor are most hams computer hardware
geeks, programmers, OS geeks (or even OS literate) or network engineers.
They put their kilobucks into radios, antennas and sundry hardware.
Separate computers/OS's for each piece of hardware they have simply
doesn't happen often. In fact, given the array of hardware used,
separate computers and OS's would likely be a nightmare.
BTW, one fix for the timing problem that corrupted code timing is
something called WINKEY. It is an external box. You send it ASCII
characters and it sends out the perfectly timed code. It does work but
has caused quite a few problems in setting it up. There is more it has
to do than just the translation. Radio teletype can be done in a
similar way with the equivalent of a modem.
Then there are multiple antenna rotors to position, logging of contacts,
antenna switch boxes, voice keyers, audio routing, networks, internet
data streaming, multiple radios to control and communicate with,
separate SDR's which automatically troll for stations to contact,
amplifier interfaces which pretune the high power amplifier when
necessary, multi monitor displays, satellite antenna tracking.. The
list goes on. Having one central computer do everything is pretty much
of a must for a single operator.
BTW, calling it wireless isn't appropriate. There generally is a huge
rat's nest of wires and cables behind the desk.
Regards
Brian
On 7/26/2013 13:06, Jim Lux wrote:
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.
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2242 / Virus Database: 3209/6022 - Release Date: 07/26/13
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2242 / Virus Database: 3209/6022 - Release Date: 07/26/13
_______________________________________________
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.
