Home |
Search |
Today's Posts |
#11
|
|||
|
|||
.... 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 | | |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Any GE Progress Line Units Still Around? | Boatanchors | |||
Amateur Radio Newsline(tm) Report 1394 - April 30, 2004 | Shortwave | |||
Amateur Radio Newsline(tm) Report 1394 - April 30, 2004 | Policy | |||
Amateur Radio Newsline(tm) Report 1394 - April 30, 2004 | General | |||
Why do hams always stand in the way of progress? | Scanner |