I have checked the local walmart shelves, nope, nothing like I have
mentioned...

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

wrote in message
oups.com...
| From: Paul Keinanen on Sun,May 8 2005 11:54 pm
|
| On Sun, 08 May 2005 10:44:27 -0700, Tim Wescott
| wrote:
|
| The basic difference is that with a digital system you either end up
| with a clean signal or a useless signal. In an analog system the
| character and purity of the signal must be carefully guarded, at
| least
| until you manage to digitize it. This means that there will be a
| much
| greater chance that adding a new card to the radio will degrade not
| only
| the function of the new card, but the function of all the other
| cards.
|
| Second, the PC market is a huge one, with great advantages to be
| derived
| from common equipment and software, and much smaller advantages to be
|
| derived from commonality. This is the exact obverse of the radio
| market, including homebrew radios. To make a "card" radio would be
| to
| define a basic radio architecture, probably down to the IF frequency
| (or
| at least to the point of forcing you to match your IF and front end).
|
| While improvements could be made within this structure an independent
|
| experimenter couldn't play around with such things as
| direct-conversion,
| different IF schemes, etc., without extensive modification.
|
| I agree that it would be quite hard to make a good quality radio with
| some common backplane structure. However, connecting various
| functional modules with 50 ohm input and output impedance could be
| used to make quite different radios with good specifications.
|
| That's already been done in the RF industry for a half
| century.
|
| As one example, take the U.S.' AN/PRC-8, -9, -10 series
| of manpack transceivers covering high-HF into low-VHF.
| Still in the vacuum tube era, all of the IF modules
| included the IF tuned circuits as well as the subminiature
| tube. If the tube filament burned out, the entire module
| was replaced. NO alignment tweaking was required. Design
| was done back around 1950.
|
| As for standards on control...start with the ATLAS (for
| USAF test equipment) and continue on to the IEEE-488
| interface. Those standards worked with "modular"
| components capable of testing receiver sensitivity down
| to noise level with KNOWN signal levels. By the way,
| test equipment for RF has been standardized at 50 Ohms
| since WW2 days.
|
| For
| instance Mini-Circuits also makes various diode ring mixers,
| amplifiers and apparently also VCOs that are boxed and have BNC or SMA
| connectors. With each functional module in a metallic enclosure,
| controlling the spurious radiation between modules is much easier. I
| don't know that anyone would make filter modules, which would be
| required to build a complete radio. Also SSB-Electronics sold separate
| amplifier, mixer, frequency multiplier and crystal oscillator modules
| mainly intended for a 10 GHz transverter.
|
| Unfortunately the cost of these modules is quite high, apparently due
| to low production volumes and large amount of manual labour needed to
| assemble them. If there would be a large demand for such modules, it
| would make sense to design them to require less manual labour to
| assemble them and hence get the price to more affordable levels.
|
| Define "more affordable." :-)
|
| "Filter modules" have and are built to order by dozens
| (if not hundreds worldwide) of companies. The costs
| ARE high because they are built TO specifications and
| such have to be TESTED to meet those specifications.
| Is there comparable KNOWN/calibrated test equipment
| in the average homebrewer's hobby workshop that is
| comparable...even at "low" frequencies of HF? Actually,
| Kaylie's Mini-circuits DOES use calibrated, automatic
| test equipment to check out each module, small
| quantities to large quantities. Mini-Circuits doesn't
| have the market demand to do production runs in the
| 10,000-lot quantities.
|
| The mystique on L-C filters is largely that...mystique.
| Without some good, calibrated test equipment, it is
| very difficult to determine what a "filter module"
| has for performance. Synthesis (design) of the values
| for a particular filter type was arduous until folks
| came out with computer-aided design. I have a working
| freeware program for PCs on that...send a message in
| private e-mail if you want one transmitted to you.
|
| As to cost, just look at a cellular telephone handset.
| Those can cost around US$ 50 each, new. They work in
| a band roughly centered at 1.0 GHz. Microwaves.
| Complete microwave Rx-Tx with synthesized tuning.
| For half a hundred US dollars here. A mere 30 years
| ago that would be almost inconceivable. Three years
| ago the U.S. Census Bureau said that one in three
| Americans have a cell phone subscription. That's
| roughly 100 MILLION units either out there or waiting
| to be used. Market quantity and competition in that
| market are the key to bringing down costs. Radio
| hobbyists just cannot possibly get close to such
| market quantities.
|
| While a backplane would not be suitable for running the RF signals, it
| would be a good idea to have a common control interface standard. This
| might be some sort of serial interface or perhaps a CANbus interface
| as used on some AMSAT satellites.
|
| Who says a "backplane would not be suitable?" :-)
| Those PC backplanes carry terribly broad spectra of
| RF...from (literally) DC on up to the low microwaves.
| No "perhaps" about it. Thing is, the layout can NOT
| be done as if it were wire-wrap; i.e., in random
| order of wire placement. With broadbanding anything,
| every single adjacent trace becomes a COUPLER and
| unwitting layouts can produce remarkable crosstalk
| effects. Designers have known that for decades and
| handle it...all kinds of Application Notes and info
| out in public access available for anyone...just too
| specialized for the "weekender" small-project
| assembler hobbyist.
|
| The IEEE-488 is a mature standard for control and
| interface for computer-controlled, interconnected
| systems. Would be a bit TOO all-inclusive for a
| special-purpose new design. The "interface" does
| NOT have to be some kind of "new" thing used on the
| latest whatever out in space. It's just a control-
| and-response avenue carrying signals of a standardized
| kind...a few wires/traces perhaps...laid out properly
| if required to be broadbanded or broad in dynamic
| signal range. Not a big thing, but needs some
| THOUGHT before becoming hardware.
|
|
|

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

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

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

I'm eagerly awaiting the block diagram and system specification which I
assume you'll be working on. I'm sure it won't take you long. Good luck!

Roy Lewallen, W7EL

John Smith wrote:
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

Hmmm, you know, basically just two guys built the first apple desktop
computer--you think it is that much more difficult? Well, maybe!

I think one can begin with at least a mental pic...

....all the voltages which are to be used run on a common bus, the digital
lines are there to, without the "motherboard card", these are pretty much
unused... the audio lines can be hear for digital cards (on the bus for the
audio amp card)--very low level rf might have access though a proper
connector, of some sort (maybe on a shelf now, maybe need to do new specs
for one), there is a bnc/so-239, etc... which "floats" in a slot, capable of
sliding along to gain access to all cards (why limit where the PA will be
inserted?)...an analog bus with connectors available to each card lays on a
line which is also available to any cards requiring it, and provides
connection to a plug which is accessible if an analog panel is used--on this
analog panel are standard components (which may be all there, or added one
at a time, as needed)--meter, vol, squelch, rf gain, tuning (variactor card,
or old variables if room) lcd readout, etc...

Certainly one would just begin with the case, power supply, and the bus(s)
providing everything one can imagine a "card designer/builder" would require
in the future--and put some flexibility in it, just in case you want to do a
case revision/upgrade in the future, maybe you start out with too big a case
right now--looking forward to future times when it would be desirable to
have it smaller, etc...... rf out, rf in?, audio, etc lines--duplicate most
everything in both digital and analog-- ... then "analog panel"/"digital
panel" connectors... maybe expect the case to house no larger than a
100-500 watt PA... larger power through an external unit...

You point is well taken that my bench, time and abilities are limited--I am
trying to finish putting three boys through college...

.... even my overpaid colleges at work just wanna sip beer on the weekends
and watch the game or dvds, or plan the next cruise--could be a sign of my
generations age or decline... my access to real "innovators" is limited...
so is this countries...

.... but, as has been pointed out--this newsgroup is read in other
countries... countries where innovation is not dying but, rather just
blooming...

And, placed beside the first apple desktop (built by, basically, two boys in
a college lab and a garage)--I think most would say "IT IS DO-ABLE!"

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

"Roy Lewallen" wrote in message
...
| I'm eagerly awaiting the block diagram and system specification which I
| assume you'll be working on. I'm sure it won't take you long. Good luck!
|
| Roy Lewallen, W7EL
|
| John Smith wrote:
| 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

Well, most of this requires VERY little innovation and only DUPLICATION...

Many manufacturers make motherboards, hd's, cd's, video cards, audio cards,
tv cards, radio cards, network cards, port expansion cards, home security
cards, security cams, credit card readers, security readers (finger print,
eye retina, etc) etc, etc...

.... That many manufactures share one case with great ease--is made obvious
by the computer on your desktop--indeed--on excellent motherboards, they are
NOT picky about even the processor!!! Intel, Cyrix, AMD, IBM, VIA, etc
(even providing sockets with different pin configurations for different
processors!)... (Some no longer available--they come and they go)

Don't go name brand junk: HP, Dell, Toshiba, Sony, etc--but go generic IBM
case and the world of computer manufacturers is available to you... and
look at the laptop--you know why EVERYONE in the world doesn't have one?
BECAUSE THERE IS NO GENERIC CASE!!!! You are stuck with proprietary junk!!!

Both in rec.radio.amateur.antenna and here there are far more focused on why
something can't be done, than why it can--I think if one ignores this--it
can be done!... this is interesting... and is why I began a thread on
progress.... especially since so many thought there was no reason to even
mention it...

One more thing, just make a generic case for a laptop platform, make the
platform available to support other manufacturers components--guess what...

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

On 9 May 2005 15:08:07 -0700, wrote:

From: Paul Keinanen on Sun,May 8 2005 11:54 pm

While a backplane would not be suitable for running the RF signals, it
would be a good idea to have a common control interface standard. This
might be some sort of serial interface or perhaps a CANbus interface
as used on some AMSAT satellites.

Who says a "backplane would not be suitable?" :-)
Those PC backplanes carry terribly broad spectra of
RF...from (literally) DC on up to the low microwaves.
No "perhaps" about it. Thing is, the layout can NOT
be done as if it were wire-wrap; i.e., in random
order of wire placement.

The PCI signals must run on transmission lines, since the receiver is
not activated by the for forward wave, which is reflected by the
mismatched end of transmission line and the receiver is only activated
by the combination of the forward and reflected wave. So indeed, the
layout is critical to get the signal through, even if no crosstalk
problems would exist.

With broadbanding anything,
every single adjacent trace becomes a COUPLER and
unwitting layouts can produce remarkable crosstalk
effects. Designers have known that for decades and
handle it...all kinds of Application Notes and info
out in public access available for anyone...just too
specialized for the "weekender" small-project
assembler hobbyist.

In a PC, the signals are all around a few volts, thus the crosstalk
problems are not so bad. In a radio receivers, the signal levels vary
from less than a microvolt to several volts, so the crosstalk issues
are much more demanding. Microstrip transmission lines would hardly be
enough, at least striplanes with grounded traces between the signal
conductors in the middle layer would be required, so the minimum would
be a 3 layer PCB.

The IEEE-488 is a mature standard for control and
interface for computer-controlled, interconnected
systems. Would be a bit TOO all-inclusive for a
special-purpose new design. The "interface" does
NOT have to be some kind of "new" thing used on the
latest whatever out in space.

The IEEE-488 requires a lot of signals and a complex handshaking, so
in practice, you would need an interface chip anyway.

The CANbus has been used in the automobile industry for more than a
decade. The CANbus has a nondestructive collision system, so this
makes it possible to have a true peer-to-peer communication system,
without complex protocols (such as token passing).

The AMSAT thing I was referring to is a standard PCB, with a size
about a D connector, with an interface chip on it and it has a few
digital signals. It is included in every module on the bigger AMSAT
birds. This bus structure greatly simplifies the wiring between
modules.

Paul OH3LWR

On Mon, 09 May 2005 16:17:59 -0700, Roy Lewallen
wrote:

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?

There are large, well established operating system created and
maintained by volunteers. The problem with some special hardware is
often that the hardware interface specification is not publicly
available (as with some 3D graphics cards).

Writing a device driver for some radio modules would not be that hard,
provided that the module control is designed in a somewhat sensible
way. As long as the hardware interface specs are available for these
modules, the software is not going to be the show stopper.

Paul OH3LWR

From: Paul Keinanen on 10 May 2005 09:11:19 -0700

While a backplane would not be suitable for running the RF signals,
it
would be a good idea to have a common control interface standard.
This
might be some sort of serial interface or perhaps a CANbus interface

as used on some AMSAT satellites.

Who says a "backplane would not be suitable?" :-)
Those PC backplanes carry terribly broad spectra of
RF...from (literally) DC on up to the low microwaves.
No "perhaps" about it. Thing is, the layout can NOT
be done as if it were wire-wrap; i.e., in random
order of wire placement.

The PCI signals must run on transmission lines, since the receiver is
not activated by the for forward wave, which is reflected by the
mismatched end of transmission line and the receiver is only activated

by the combination of the forward and reflected wave. So indeed, the
layout is critical to get the signal through, even if no crosstalk
problems would exist.

But...there CAN be COUPLING there and that is, very
definitely, part of the layout. When mixed with
analog signals - as would be the case in a "radio" -
the layout can be critical.

In a PC, the signals are all around a few volts, thus the crosstalk
problems are not so bad.

Look again at the 3.3 V logic thresholds. :-)

In a radio receivers, the signal levels vary
from less than a microvolt to several volts, so the crosstalk issues
are much more demanding.

I will disagree on radio receivers on such wide dynamic
ranges. "Several volts" INTO a receiver front end?
No. Such levels aren't encountered in practical
locations and would, definitely, cause enough IM
that would create much distortion and spur products.

In radio transmitters, YES, but those stages can be
individually shielded and thus isolated...do NOT
need to be close to the control lines...or even need
control lines (in the case of an amplifier block).

Microstrip transmission lines would hardly be
enough, at least striplanes with grounded traces between the signal
conductors in the middle layer would be required, so the minimum would

be a 3 layer PCB.

Not the case in practical RF structures done in
the last three decades. [been there, done that,
got lots of T-shirts] It is BETTER to have good
stripline and microstrip as opposed to "ordinary"
PC layout, but that isn't an absolute necessity.


The IEEE-488 requires a lot of signals and a complex handshaking, so
in practice, you would need an interface chip anyway.

That was cited solely as an example of something
that IS mature and used daily in radio-electronics
testing.

The CANbus has been used in the automobile industry for more than a
decade. The CANbus has a nondestructive collision system, so this
makes it possible to have a true peer-to-peer communication system,
without complex protocols (such as token passing).

IF and only if this SDR of the future NEEDS micro-
computer control...or even modular microcontroller
sub-systems.

Trying to use an EXISTING computer interface system
isn't always good because that system has worked for
a decade-plus. While automotive computer interface
system speeds are increasing with increasing control
demands, radios aren't quite vehicles. The control
needs aren't quite the same.

The AMSAT thing I was referring to is a standard PCB, with a size
about a D connector, with an interface chip on it and it has a few
digital signals. It is included in every module on the bigger AMSAT
birds. This bus structure greatly simplifies the wiring between
modules.

I've had hands-in on earlier unmanned spacecraft but
understand the principles...which are similar to the
interface chips for things like USB adapters to work
with Serial or Parallel port peripherals with PCs.
One SOC (System On a Chip) that is essentially a
dedicated mircocontroler is all that is needed.
[FTDI makes those chips, Mouser sells them]

What you describe is more like an outgrowth of the
existing microcontroller adaptation to amateur
radio (and, more, to commercial radio) equipments.
The front panel controls are coupled (mostly) via
DC lines to the actual signal controls on PC boards
to reduce the mechanical complexity...which allows
greater freedom of layout and compactness.
[positive attributes for spacecraft as well]

My "ancient" Icom R-70 receiver has a central
microprocessor doing a great number of control
tasks...and does have some external control
capability through a rear connector. At about
two decades old, that's just one example of what
already existed - in radios - some time ago and
still does. Modern amateur transceivers usually
have two microcontrollers. Some of those allow
external control and a few are entirely controlled
externally. The basics have already been laid
down for the SDR system on what CAN work.

What is lacking is STANDARDIZATION. That can't be
worked out in newsgroups, but requires much more
organization...and willingness to compromise
(almost impossible in newsgroups, heh heh). See
any of the industrial standards (EIA, AES, etc.
in the USA) which are the first steps towards
making ANYTHING "plug and play." Example: The
Cannon "D" connector was on the market in the
early 1950s. A combination of factors made it a
practical connector line used in many electronic
things. Eventually, it became so common in the
USA that it was Standardized in shape, materials,
dimensions, etc., despite the original company
changing in corporate evolution. Wide use made
it "standard." The 25-pin and 9-pin D connectors
are on practically every PC today...as they were
in the beginning of the PC in 1981.

Standardization isn't anywhere close to reality
for SDR now. Nobody can seem to agree on WHAT
range of control is needed, let alone details of
the controlling interface signals. :-) That
might work itself out later.