SDR defined and explained http://en.wikipedia.org/wiki/Software-defined_radio
John P. Basilotto W5GI Chief Operating Officer Marketing and Sales Office 512 535-5266 FAX 512 233-5143 www.flex-radio.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Lux Sent: Tuesday, November 20, 2007 11:28 AM To: [EMAIL PROTECTED] Cc: FlexRadio@flex-radio.biz Subject: Re: [Flexradio] Power SDR w/other radios Quoting k5nwa <[EMAIL PROTECTED]>, on Tue 20 Nov 2007 08:40:44 AM PST: > Jim Lux wrote: >> >> The IC7000 *is* a software defined radio, just the software happens >> to be a prom that is not user changeable. >> >> >> >> jim, w6rmk >> >> >> > Darn what ever happened to words having meaning, I guess that went with > the politically correct crowd. > > Software is "soft" versus Firmware which is "firm" and not changeable > on the fly. Then there is hardware which is wired together therefore > very hard to change at all. > > So if you allow words to mean what they say a Software Define Radio > must have it's code in RAM so it can be easily changed hence "soft". What about if it's stored in EEPROM? Changeable (soft), yet static (firm) At work, we've sort of gravitated to software -> code that runs on a CPU firmware -> what's inside the FPGA hardware -> what's been soldered This still leaves open a lot of discussion (what do you call something that runs on a microcontroller instantiated in a FPGA or on one of the powerPC cores in a Virtex Pro?) Is Verilog software and the compiled bitstream firmware? And, this varies from some common other usages: hardware -> what cannot be changed firmware -> what the manufacturer can change at manufacturing time, but users cannot software -> what the user can change, post delivery To a certain extent, in the business world, the semantics are driven by institutional requirements. Most places have different validation and test requirements for hardware and software (not much point in pyro shock or environment testing software, code walkthroughs don't do much for RF hardware designs). But there's always those boundary cases.. Is a CPLD a hardware component and the logic that defines its function software? Or, is the "programmed part" the hardware component. What about a anti-fuse programmed Actel part? What about a Xilinx or Altera with configuration RAM loaded from an offboard EEPROM. There's a sort of bifurcation in configuration management too. Hardware has drawing trees and the like. Software has code repositories and tools like CVS,SVN, SourceSafe. And there's other issues: How do you define interface control documents with the logic able to be changed at run time? For a complex ASIC you can create a datasheet that lays out the control and status registers and the timing behavior, etc.. What about that same function instantiated as part of a bigger design in a 6 megagate part like a 6000 series Virtex 2. Such issues are what I get paid to work on these days..for spacecraft radios, NASA is a small volume customer that is thrifty, much like hams, so we can't just dictate "thou shalt do X" (like DoD can, buying radios in billion dollar lots), but we still want to get some of the benefits of open software/firmware standards for those radios. We also are like hams in that we want long useful life for the hardware (We want to use that spare $2M radio we bought for the 1998 mission that we have sitting on the shelf for a 2010 mission. Read "really cool thing I found at a hamfest 2 years ago"). Just like hams, we also like to have all the functioning and internals laid out for us so we can tinker and modify, or just understand what it will do in an off-nominal situation(i.e. no magic proprietary modem ASIC). We tend to be concerned about efficiency because space qualified processors are a couple generations, if not more, behind... we're just starting to use a 100MHz SPARC V8 as a bold advance from a 25 MHz SPARC V7, no multi GHz Intel CoreDuos or AMD QuadCores flying to Mars or Jupiter any time soon. And besides, when all you've got is a 200W solar panel, you don't want to burn all your Joules on computing..you want to leave some to run that RF Power Amplifier. Our challenge is figuring out what the right level of abstraction and specification is. Too general, and the standard is worthless. Too specific, and the compliance cost to conform exceeds any of the speculative savings from having a standard. The manufacturers all are more than happy to quote you a price to comply to whatever standard you care to give them. > > This reminds me of an discussion I had with a fellow on another list, > he called the SDR-1000 a Superheterodyne receiver instead of a Direct > Conversion Receiver. The only problem with his argument was that the > "Super" in Superheterody does not stand for "great" it stands for > Supersonic, or beyond hearing which unfortunately the SDR-1000 fails. And hey, since there's another mix and filter operation in the software, is it a single conversion or double conversion receiver? What if the A/D sampling operation is used as a downconversion (in "bandpass sampling"). Many oxen are gored, many ricebowls spilled, etc, from such descriptions, if only because the terms come with some baggage from previous experience. (That's why Analog Devices and Maxim describe their I/Q parts as Zero-IF rather than direct conversion, because "everyone knows that DC receivers are evil.") Jim, W6RMK _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Knowledge Base: http://kb.flex-radio.com/ FlexRadio Homepage: http://www.flex-radio.com/ _______________________________________________ FlexRadio mailing list FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archive Link: http://www.mail-archive.com/flexradio%40flex-radio.biz/ FlexRadio Knowledge Base: http://kb.flex-radio.com/ FlexRadio Homepage: http://www.flex-radio.com/
