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