.... I forgot to mention, that while the minimal OS of the radio itself would
be a minimal linux kernal--a USB, TCP, serial, parallel, etc hardware
interface could be chosen so windows users would find it transparent--and
they access the radio either through a GUI or commandline interface... when
using the digital capabilities...

The most basic starter of this radio might be a regen receiver (or TRF) and
a one watt xmitter board and analog of course... great for new
"bootstrapping" hams...

Warmest regards,
John
--
When Viagra fails to work--you are DOOMED!!!

"John Smith" wrote in message
...
| Roy:
|
|
|
| Like Linux, a superior operating system when compared to windows--it would
| mainly be done by "the community"... all the hardware guys would have to
do
| is make known the ports, address, etc... they are really un-needed from
| there--but, it would speed the takeoff of the "system" if they did provide
a
| beginning point... and, one can always run a de-compressor (if they have
| compressed the executable), then a disassembler to asm, then a converter
to
| "C" and, if you can program, you can now "tweak" the code anyway you would
| like... you will have a copy of it!!!!
|
|
|
| If the "hardware guys" didn't know how to provide a software interface,
| there are "linux hams" who would, most likely, if asked, "sponsor" such a
| effort on the Linux platform--hopefully--the interface to such a radio
would
| bypass BOTH Mac and Windows, why these OS's are sufficient for home users,
| non-technical business and gov't--the technical mind deserves more, the
| power of linux (unix really) would serve them much better...
|
|
|
| However, the "system" we are speaking of would ONLY require a software
| interface if you inserted that card/module which allowed computer control,
| otherwise it would be using the analog card/module and associated
| faceplate...
|
|
|
| I think most here start right out trying to "limit" this "system" I have
put
| forward--there would be no limits to it... if you can see a limit, that
is
| only a bug which needs designed around...
|
|
|
| The homebrew community might be the best place to design, develop and
| introduce this from... as, if you allow too greedy a manufacturer
| control--it will just end up dying from his/her attempts to squeeze too
much
| blood from the turnip!!! That is what has happened in the past...
|
|
|
| Warmest regards,
| John
| --
| When Viagra fails to work--you are DOOMED!!!
|
| "Roy Lewallen" wrote in message
| ...
||I don't think much of the discussion has looked very closely at what I
|| think is envisioned here -- a mainframe which would accept various
|| "cards" from numerous vendors. As I detailed in an earlier posting, it's
|| tough enough (and costly) to make a robust interface when a single
|| company has full control of the mainframe and plugins. But let's think a
|| little about the problems of making a mainframe which could accommodate
|| cards from various vendors -- cards which have different performance
|| characteristics.
||
|| The first question is, who will define the interface? Who will dictate
|| modifications as they become necessary?
||
|| Then let's consider a vendor who wants to make, say, an audio amplifier
|| card. It has digital signal processing with a dozen different modes.
|| Each mode has considerable adjustment range, for example the width of a
|| bandpass filter. The interface would have to have pins dedicated to
|| these functions, and the front panel would have to have switches and
|| controls for them. How about an oscillator? One might be digitally
|| tuned, another analog. There are bandspread and RIT to accommodate in
|| addition. What do we do about T/R switching and timing if it's to be
|| used in a transceiver? How about shielding specifications so it won't
|| interfere with other cards?
||
|| The only possible way I can see something like this being even possible
|| is for a virtual "front panel" being done in software and appearing on a
|| PC screen; only in that way could each card be sure that the necessary
|| controls would be present. Some sort of serial bus with expandable
|| protocol would be used for all controls.
||
|| Then the question becomes, who will define, develop, and maintain the
|| software? I can tell you from experience that it's no easy matter to
|| keep any software working properly as new operating systems, protection
|| software, and hardware appear. Add the necessary hardware interface to
|| the equation and the job gets tougher yet. Oh, and what do you do when
|| key components of the interface become obsolete and no longer available?
||
|| It's common for people who've never had to design something which will
|| be reproducible by the thousands and operate without error, to say how
|| easy something will be. As one of those people who spent a career
|| designing just such equipment, I'd bet serious money that the cost of
|| development and maintenance of the interface would never pay itself back
|| in sales. Unless, of course, it's done by volunteers. My question is:
|| Why don't folks like "John Smith" get off their duffs and do it?
||
|| Roy Lewallen, W7EL
|
|