[time-nuts] was RS-232,

Brian Alsop alsopb at nc.rr.com
Fri Jul 26 15:46:33 UTC 2013


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 at 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




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