[time-nuts] was RS-232,

[Jim Lux]

On 7/26/13 8:46 AM, Brian Alsop wrote:
> Hi Jim,
>
> You mean to imply no commercial programs ever use "quick fixes"?

heavens no.. Plenty of 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.

Yep. I'm one of them.  I think it is fundamentally unfair to whine about 
"why won't what I buy today do what my 30 year old widget did, at no 
cost".  There was a short time when PCs were slightly grown up from the 
Altair/Imsai/Cromemco/Soroc/etc days, but were still pretty low level. 
So simple hardware hacks (using the printer interface as a general 
purpose parallel I/O) were easy and feasible.

But it's unrealistic to expect this from a modern PC.  The industry has 
moved on. The sweet spot of "consumer gear providing a hardware hacking 
platform at low cost" is long gone.  Today, if you want to do that sort 
of parallel port hacking, you buy an Arduino or some other comparable 
platform. (or, if you want to do it on a modern media player/PC, you 
suck it up and learn to use the modern platform, but that's a big 
investment of time).

  It's the same in cars. It's unrealistic to expect to use your engine 
hacking skills acquired in the 70s on hardware from the 60s with designs 
dating to the 40s and 50s on a modern engine.   The modern tuner hackers 
work with the engine maps and hack the ECU, but that, like working with 
modern PCs, requires an investment in newer tools and a fairly hefty 
investment of time in learning how the new systems work, and what's 
adjustable.  That knowledge of engine thermodynamics and combustion will 
be useful in hacking both 1960s and 2000s vintage cars, but the detail 
skills are different: less knuckle busting today, more arcane keyboarding.



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

No.. I'm not saying that modern developers of ham software aren't clever 
or sophisticated.  It is that they tend to rely on quick fixes which are 
not long term reliable or durable over the underlying platform changes. 
  How many programs relied (still rely) on a stack of legacy software 
adapters/emulators.  There's probably software out there that still uses 
BIOS INT 14, running in  DOS emulation box, running in a WinXP 
emulation, etc.

(and this is true in industry.. I'll bet there's someone in the US being 
paid with a paycheck printed by some old IBM 1400 series code running in 
emulation.  Certainly there is a lot of System/360 software and PDP/11 
software running in emulation out there.)


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

Most hams aren't RF designers either, and don't design and build their 
own radios.  What I argue is that if they want modern integration, and 
that connecting the PC is an essential part of their system, then they 
need to allocate some resources towards making that work.  Maybe they 
shouldn't spend the kilobucks on the radio, but should spend X/2 
kilobucks on the radio and X/2 kilobucks on the software to make the PC 
work with the radio. That is, if the desired user experience is radio 
and PC playing together.

Granted, hams (and many, many other users) have a tough time paying for 
software. It's intangible, the reproduction cost is tiny, etc.

Hey, we have the same issue with spacecraft design.  More and more of 
modern spacecraft is software based, but the long traditions are 
hardware centric. And to be fair, the development model for software is 
radically different than hardware.  There really isn't the "ready to cut 
metal" step in software design and development that there is in 
hardware.  But it's just as hard to get people to spend appropriate 
resources on software development vs hardware in industry as it is to 
convince hams that they should pay for software development vs buying 
new hardware for their hobby.


ANd keeping it more along time-nuts... Think of the new array of 
instruments that are USB or Ethernet only interfaces. That's a 
fundamental difference in how you interact, and there's been a LOT of 
growing pains and evolution, with a whole host of compatibility issues. 
  Look at all the versions of what the interface via GPIB looks like.. 
Early days you were basically sending binary coded switch closures; then 
you sent commands with a couple letters followed by an argument 
(FR1000MZ); then you have the whole hierarchical SCPI stuff now.

And the User interface side is also evolving.  I'm no huge fan of 
Labview (from a software development/CM standpoint, mostly)but NI has 
spent a fair amount of effort in making it consistent over the multitude 
of operating system versions.



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

Sure.. And you're basically trying to shoehorn a real time control and 
data acquisition system into what is, these days, really designed as a 
media player and glorified typewriter.   You're trying to leverage an 
inexpensive media player (the PC) to do something it's really not suited 
for, and as a result, you either have frustration, or you spend a lot of 
unpaid time making it work.

Wouldn't a better long term solution be to do what they DO for realtime 
data acquisition and control..  Have a box with all the needed 
interfaces (perhaps modular) and an appropriate data connection to a box 
that does the user interface, and have that user interface via something 
that is able to leverage low cost consumer gear?

But there, you get back to the market potential.  A lot of hams aren't 
interested in spending money on a SCADA system. They want to spend in 
small discretionary chunks of $50-200 to incrementally change their 
system. And my basic contention is that you can't get to "well 
integrated with modern PCs" by an incremental $100 strategy.

You *can* do almost hard real time (certainly at the millisecond scale) 
with Windows, but it is expensive in terms of software.  There are 
relatively few people who know how to do it, and they command 
commensurate wages.  And, it would seem, that none of them have ham 
radio as a hobby, or at least, if they are, they aren't interested in 
using their real-time Windows skills on it.

For myself.. I've gotten to where I don't do the same things at home 
(coding, RF design and build) as I do at work.  The itch gets scratched 
at work, and I can use my time at home to scratch other itches.  Yep, I 
am an appliance operator and proud of it.



>
> BTW, calling it wireless isn't appropriate.  There generally is a huge
> rat's nest of wires and cables behind the desk.

And that's true of most data acquisition and control systems..