[Flexradio] KB Flex5000
Quick question: Q40:Q40. Will the FLEX-5000's low-pass filters prevent authorized operation outside of the amateur bands? A. The filters are optimized for the amateur bands but will operate over the entire HF spectrum. We lock transmitter TR relay in firmware and require a valid license to receive a key to operate outside of ITU recognized bandplans. Does this mean that there's a embedded firmware component that looks at the commands going to the DDS to set the frequency? That is, the interface to the hardware (at a register level) is different? (I assumed that this would be the case) Will the control protocol be published? What form does it take; e.g. does it use IEEE-1394b usual approach providing a model of shared memory on the host( the SDR5000) that the client (the PC) modifies? James Lux, P.E. Spacecraft Radio Frequency Subsystems Group Flight Communications Systems Section Jet Propulsion Laboratory, Mail Stop 161-213 4800 Oak Grove Drive Pasadena CA 91109 tel: (818)354-2075 fax: (818)393-6875 -- next part -- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20070416/3c767ed5/attachment.html ___ 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/
Re: [Flexradio] KB Flex5000
according Q40, How about amateuf frequencys in other regions, I understand that is not a list in database format in the 5000??? thanks 73 de peter pa0pvn groeten Peter petervn(a)hetnet.nl mailto:[EMAIL PROTECTED] ; pa0pvn(a)hetnet.nl mailto:[EMAIL PROTECTED] ; pa0pvn(a)gmail.com ; pa0pvn(a)amsat.org . Van: [EMAIL PROTECTED] namens Jim Lux Verzonden: ma 16-4-2007 19:03 Aan: flexradio@flex-radio.biz Onderwerp: [Flexradio] KB Flex5000 Quick question: Q40:Q40. Will the FLEX-5000's low-pass filters prevent authorized operation outside of the amateur bands? A. The filters are optimized for the amateur bands but will operate over the entire HF spectrum. We lock transmitter TR relay in firmware and require a valid license to receive a key to operate outside of ITU recognized bandplans. Does this mean that there's a embedded firmware component that looks at the commands going to the DDS to set the frequency? That is, the interface to the hardware (at a register level) is different? (I assumed that this would be the case) Will the control protocol be published? What form does it take; e.g. does it use IEEE-1394b usual approach providing a model of shared memory on the host( the SDR5000) that the client (the PC) modifies? James Lux, P.E. Spacecraft Radio Frequency Subsystems Group Flight Communications Systems Section Jet Propulsion Laboratory, Mail Stop 161-213 4800 Oak Grove Drive Pasadena CA 91109 tel: (818)354-2075 fax: (818)393-6875 -- next part -- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20070416/3c767ed5/attachment.html ___ 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/ -- next part -- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20070416/5fe5acdf/attachment.html ___ 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/
Re: [Flexradio] KB Flex5000
On 4/16/07, Jim Lux [EMAIL PROTECTED] wrote: Quick question: Q40:Q40. Will the FLEX-5000's low-pass filters prevent authorized operation outside of the amateur bands? A. The filters are optimized for the amateur bands but will operate over the entire HF spectrum. We lock transmitter TR relay in firmware and require a valid license to receive a key to operate outside of ITU recognized bandplans. Does this mean that there's a embedded firmware component that looks at the commands going to the DDS to set the frequency? That is, the interface to the hardware (at a register level) is different? (I assumed that this would be the case) Will the control protocol be published? What form does it take; e.g. does it use IEEE-1394b usual approach providing a model of shared memory on the host( the SDR5000) that the client (the PC) modifies? James Lux, P.E. Spacecraft Radio Frequency Subsystems Group Flight Communications Systems Section Jet Propulsion Laboratory, Mail Stop 161-213 4800 Oak Grove Drive Pasadena CA 91109 tel: (818)354-2075 fax: (818)393-6875 -- next part -- An HTML attachment was scrubbed... This does not sound like good news. It sounds as if certain features of the hardware will be controlled by firmware and without the source code to the firmware, you will not be able to make changes to the operation of the radio (those that the firmware restricts or controls). I hope that Flex is not going down the road of proprietary firmware like other manufacturers do. This means that if Flex does not make the source code to the firmware available and for some reason Flex goes belly up in the future no longer supporting the radio, you are stuck with the radio AS-IS. Let's hope this is not the case. At least with the SDR-1000 you pretty much have control over all of the hardware features of the radio by modifying the PowerSDR source code. So, another question for the FAQ would be: How much of the SDR-5000's operation is controlled/restricted by the radio's firmware and does Flex intend to make the firmware's source code available as open source? Phil N8VB ___ 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/
Re: [Flexradio] KB Flex5000
At 10:28 AM 4/16/2007, Philip Covington wrote: O This does not sound like good news. It sounds as if certain features of the hardware will be controlled by firmware and without the source code to the firmware, you will not be able to make changes to the operation of the radio (those that the firmware restricts or controls). I hope that Flex is not going down the road of proprietary firmware like other manufacturers do. Or, to take a more benign view, the firmware is like that inside the existing USB-RS232 and USB-Parallel converters, for which one wouldn't have any expectation of being opensource. There'a a fair number of 1394b to whatever widgets out there that give you a standards compliant implementation with the licensing fees all paid, etc. What one wouldn't want to do is try do demand that the 1394 implementation itself be open source. I just priced some 1394b cores for an FPGA and they run around $100K for the equivalent of a black box you can drop into your design. If you want source, it would be substantially more. And, it goes without saying that the whole thing, even in the cheaper version, is wrapped inside many layers of NDA. So, let's assume that there's some nice 1394 chipset that has the 1394 PHY on one side, and some sort of generic interface on the other. At least with the SDR-1000 you pretty much have control over all of the hardware features of the radio by modifying the PowerSDR source code. Indeed.. one can easily operate illegally, and that's as it should be for an experimentation platform. However, as a consumer product perhaps not. The more that the product of Flex-radio starts to look like a box (as opposed to parts), the more likely that it will require various and sundry forms of regulatory compliance. I think that horse is already out of the barn (viz the inability to do scanning in the official PowerSDR releases). BUT, I don't see this being a huge problem, as long as the interfaces are exposed. It's not like people want to see the microcode inside the DDS's internal controller, or are clamoring for changes in the DDS internals. Whatever is firmware controlled in the Flex 5K makes it more hardware than software, just as you don't (usually) go in and change component values on the PCBs, or the pinout of the opamps. OTOH, if the firmware interface starts to look very high level.. say like CAT commands, and a significant part of the signal processing gets hidden behind that interface, I can see your concern. And, another thing to consider.. perhaps the SDR nK has grown up? It's not a experimenter's platform any more? 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/
Re: [Flexradio] KB Flex5000
On 4/16/07, Jim Lux [EMAIL PROTECTED] wrote: At 10:28 AM 4/16/2007, Philip Covington wrote: O This does not sound like good news. It sounds as if certain features of the hardware will be controlled by firmware and without the source code to the firmware, you will not be able to make changes to the operation of the radio (those that the firmware restricts or controls). I hope that Flex is not going down the road of proprietary firmware like other manufacturers do. Or, to take a more benign view, the firmware is like that inside the existing USB-RS232 and USB-Parallel converters, for which one wouldn't have any expectation of being opensource. There'a a fair number of 1394b to whatever widgets out there that give you a standards compliant implementation with the licensing fees all paid, etc. What one wouldn't want to do is try do demand that the 1394 implementation itself be open source. I just priced some 1394b cores for an FPGA and they run around $100K for the equivalent of a black box you can drop into your design. If you want source, it would be substantially more. And, it goes without saying that the whole thing, even in the cheaper version, is wrapped inside many layers of NDA. So, let's assume that there's some nice 1394 chipset that has the 1394 PHY on one side, and some sort of generic interface on the other. At least with the SDR-1000 you pretty much have control over all of the hardware features of the radio by modifying the PowerSDR source code. Indeed.. one can easily operate illegally, and that's as it should be for an experimentation platform. However, as a consumer product perhaps not. The more that the product of Flex-radio starts to look like a box (as opposed to parts), the more likely that it will require various and sundry forms of regulatory compliance. I think that horse is already out of the barn (viz the inability to do scanning in the official PowerSDR releases). BUT, I don't see this being a huge problem, as long as the interfaces are exposed. It's not like people want to see the microcode inside the DDS's internal controller, or are clamoring for changes in the DDS internals. Whatever is firmware controlled in the Flex 5K makes it more hardware than software, just as you don't (usually) go in and change component values on the PCBs, or the pinout of the opamps. OTOH, if the firmware interface starts to look very high level.. say like CAT commands, and a significant part of the signal processing gets hidden behind that interface, I can see your concern. And, another thing to consider.. perhaps the SDR nK has grown up? It's not a experimenter's platform any more? Jim, W6RMK Let's hope that this is just a miscommunication and there is no firmware to restrict things like frequency coverage. Maybe the FAQ writer was referring the the PowerSDR software when he mentioned the lock out. 73 Phil N8VB ___ 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/
Re: [Flexradio] KB Flex5000
Let's hope that this is just a miscommunication and there is no firmware to restrict things like frequency coverage. Maybe the FAQ writer was referring the the PowerSDR software when he mentioned the lock out. Either way, it's a little more serious than that. The component SDR-5000 might be exempt, but the models with embedded controllers are likely to be prohibited from using GPL software. 73 Frank AB2KT -- next part -- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20070416/052626e5/attachment.html ___ 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/
Re: [Flexradio] KB Flex5000
On 4/16/07, Frank Brickle [EMAIL PROTECTED] wrote: Let's hope that this is just a miscommunication and there is no firmware to restrict things like frequency coverage. Maybe the FAQ writer was referring the the PowerSDR software when he mentioned the lock out. Either way, it's a little more serious than that. The component SDR-5000 might be exempt, but the models with embedded controllers are likely to be prohibited from using GPL software. 73 Frank AB2KT The firewire audio and control interface pretty much needs a microprocessor and the microprocessor needs firmware, so I guess it is not a miscommunication. So, there will be firmware in the SDR-5000 that sits between PowerSDR and the hardware. I guess a lot depends on how much information is published about the firmware functions. 73 Phil N8VB ___ 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/
Re: [Flexradio] KB Flex5000
At 11:50 AM 4/16/2007, Frank Brickle wrote: Let's hope that this is just a miscommunication and there is no firmware to restrict things like frequency coverage. Maybe the FAQ writer was referring the the PowerSDR software when he mentioned the lock out. Either way, it's a little more serious than that. The component SDR-5000 might be exempt, but the models with embedded controllers are likely to be prohibited from using GPL software. Because of GPL? or because of Part 15? From a Part 15 sort of standpoint, it would be straightforward to design a hardware platform that still allows the bulk of user interface and signal processing to be done in an open way, while preventing emissions in places it shouldn't radiate, etc. Not that it would be pretty, but it's fairly do-able. I believe there's a commercial HF power amplifier that implements something like this, with a frequency restriction in a microcontroller that samples the input, and doesn't turn on the DC to the output unless it's in band. heck, just restricting where you can tune the DDS, tied to the sample rate on the audio section (especially if you put some switchable LP filters in the audio) would probably do well enough. ___ 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/
Re: [Flexradio] KB Flex5000
At 02:23 PM 4/16/2007, Frank Brickle wrote: On 4/16/07, Jim Lux mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: Either way, it's a little more serious than that. The component SDR-5000 might be exempt, but the models with embedded controllers are likely to be prohibited from using GPL software. Because of GPL? or because of Part 15? GPL. Version 3 has what amounts to a counter-DRM provision that says, basically, if you're distributing GPL software and it's running on locked hardware, you're obligated to enable either (1) a method for users to replace the locked-hardware keys with their own keys, or (2) replace the locked firmware entirely. And how would this comport with, e.g., a USB to RS232 interface that the software treats as a serial port? I suppose that's not locked hardware in the sense you mean? I would assume that the firmware/hardware in the future Flex-Radios would fall in a similar case.. it might implement a IEEE-1394b interface to the DDS which exposes some set of functions, and that's it. I don't see this as being materially different than the USB dongle providing access to a baudrate control register, and only providing some subset of all possible baudrates the hardware might conceivably generate, if you were free to muck around with the digital frequency divisors internally. Or, for that matter, the 1394b interface itself. It incorporates patented aspects which are licensed by the consortium, and I see little difference between a ASIC that implements the interface and a FPGA that implements the interface. Or, would it be your contention that in order to be fully GPL3 compliant, the software would have to have unfettered access to the physical layer bits? Anyone who's interested in DRM issues should bone up on the discussions concerning GPL v3. Thanks to the ...or any later version... clause in GPL v2, the version now in draft will probably be the law of the Free Software universe before very long. There is, of course, quite a bit of discussion with respect to GPLV3 (e.g. Linus isn't particularly wild about it). Is it a reasonable assumption that PowerSDR would be released under GPL v3, or GPL v2, or under some other license? What about all the bits and pieces needed to make it work (jack, portaudio, dttsp, pthreads, etc.) Could *anyone* release a GPL v3 visual studio application, considering that such applications are so thoroughly bound up with the microsoft windows guts. I confess I've not been following all the twists and turns of GPL v3, since my work tends to either be closed or totally open (as in do with it what you will, the taxpayers paid for it). Jim -- next part -- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20070416/96050912/attachment.html ___ 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/
Re: [Flexradio] KB Flex5000
GPL v3 is trumped by federal law as determined by the communications hegemony on 1919 M STREET N.W. The Flex 5000 will be required to submit for several certifications and will require FLEX to have certain locks on its hardware to meet certain certifications. This will get even worse when Flex tries to submit for the ability to scan (part 15: CFR 47, Part 15, Subpart B). For example, Flex must submit proof that the receiver has no spurs that can be tuned onto Cell towers and mix the cell tower into the bands it DOES cover directly. GPL has absolutely nothing to say about any of this since no license can violate federal law (if you want to stay in business for long and out of the large fines associated). I would prefer to have the scanning capability so I can run cognitive code (for example) doing something useful. This is scanning the minute we do it because the rules SAY that it is. When we do this, Flex must have submitted their radio to the testing that shows it cannot respond up to a certain specified level to emissions on cellular telephone towers. It is crazy, but congress is still livid about Newt's silly phone call being overheard and it is congress that has mandated this. If what is meant by some in this conversation is: Will the code require interaction with the hardware to work? No, that is not the case, there are no secret handshakes in the code. The code will have no check at all to see if the hardware is compliant or licensed or anything. The code will fail to start the nonexistent hardware connected on firewire just as ANY code would, GPL or not, that expects a device to be there which is not. It will be just as if you told it to talk to an FA-66 that was not there. It will issue an error message and fail. But all of the code interacting with the hardware is visible now in the branch save the driver which will be distributed separately once the hardware is released. That is as it should be and PowerSDR will surely fail if you tell it to hook to a firewire device that is not there! It seems absurd to suggest however that GPL ANY version code cannot work with (say) a sound card just because it has proprietary code associated with it. Ubuntu supports Nvidia drivers for my machines and I download them using Ubuntu's installation tool. They surely know more about GPL than I do and I am sure they know more than all of us combined. IF Flex distributes driver's for their hardware under separate cover, and clearly marked as non-GPL, it will be the same thing entirely. All Stallman will do with a v3 that prevents this is make Microsoft very happy indeed. If I were Ballmer, I would be sending him money to support v3 to have this outcome. Consider the Flex 5000 to be a very fancy sound card. Its drivers, etc. can be distributed separately from all GPL code. Should Flex distribute the drivers for their hardware just as sound card manufacturers now do, under separate cover, it is clear they are compliant unless FSF changes the rules. For all I know, Flex may give it away, except for those pieces which THEY DO NOT HAVE RIGHTS to distribute, such as some of the hardware associated with the firewire. They must comply with those licenses and rather than have no radio at all, I presume we all want them to comply with their hardware driver requirements. Flex users have become quite accustomed to going to Roland, M-Audio,etc. for the drivers. The super fancy Flex 5000 sound card would be no different whatsoever and no one would suggest that it would be a good outcome if GPL code would be forced not to work with these sound cards OR the fancy Flex 5000 sound card. I know Stallman would LIKE to prevent the use of GPL code with proprietary hardware drivers and about all he will accomplish is to utterly wreck the GPL IMO. On out of band operation: The Flex 5000 hardware will work outside of the ham bands and especially for those MARS frequencies that are near ham bands but I suspect what will happen is that like ALL amateur radio manufacturers, no specs will be provided for the radio out of band. The filters are definitely optimized for the ham bands. I even suspect that if you operate sufficiently below the ham bands significantly inside a filter that covers a ham band, the third order harmonics will not be sufficient suppressed. But that is the nature of doing UNINTENDED use of a piece of equipment. I expect will be not much different than ICOM, Yaesu, Kenwood, Ten Tec, etc. and their bandpass filters optimized for the ham bands. NTIS has just made the out of band operation requirements SO severe in any case, in terms of spurious emissions requirements, that NOT ONE amateur radio transmitter currently manufactured, that I know of, can meet it. This is almost surely the manufacturers of expensive equipment winning the day to prevent inexpensive amateur equipment from being used out there. This will
Re: [Flexradio] KB Flex5000
On 4/16/07, Robert McGwier [EMAIL PROTECTED] wrote: GPL v3 is trumped by federal law as determined by the communications hegemony on 1919 M STREET N.W. What I do believe you've succeeded in showing here is that the whole issue is far from clearly drawn. What I don't believe is that the arguments you've offered are more than voodoo analogies. For example, the GPL in any version isn't trumped by federal law -- unless, of course, you mean that some federal law rules out using some software entirely. That's possible. The logic goes downhill from there, but the whole subject gets tiresome very quickly, so, enough. 73 Frank AB2KT -- next part -- An HTML attachment was scrubbed... URL: http://mail.flex-radio.biz/pipermail/flexradio_flex-radio.biz/attachments/20070416/f30a2ae5/attachment.html ___ 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/
Re: [Flexradio] KB Flex5000
At 04:42 PM 4/16/2007, Robert McGwier wrote: GPL v3 is trumped by federal law as determined by the communications hegemony on 1919 M STREET N.W. The Flex 5000 will be required to submit for several certifications and will require FLEX to have certain locks on its hardware to meet certain certifications. This will get even worse when Flex tries to submit for the ability to scan (part 15: CFR 47, Part 15, Subpart B). For example, Flex must submit proof that the receiver has no spurs that can be tuned onto Cell towers and mix the cell tower into the bands it DOES cover directly. yep.. This IS a sticky wicket, although having a very simple RF structure means that meeting the test is easier (no worries about images of the IF, etc.) clearly marked as non-GPL, it will be the same thing entirely. All Stallman will do with a v3 that prevents this is make Microsoft very happy indeed. If I were Ballmer, I would be sending him money to support v3 to have this outcome. Hence the turmoil in the GPL community about v3.. Consider the Flex 5000 to be a very fancy sound card. This is sort of the model that I would think would be useful.. instead of just sending paramters that set sampling rates and gains and switch settings, you also send LO tuning frequency, cal tone on/off, tx/rx, etc. But the real question is how smart is that sound card. At one end of the spectrum is the new Icom PCR2500 (which has the sound card integrated). At the other is some sort of firewire hub lashup with a FA66, a 1394/parallel converter, and some relays. Its drivers, etc. can be distributed separately from all GPL code. Should Flex distribute the drivers for their hardware just as sound card manufacturers now do, under separate cover, it is clear they are compliant unless FSF changes the rules. I think that's the thrust of RMS's efforts.. He wants the drivers to be GPL as well. For all I know, Flex may give it away, except for those pieces which THEY DO NOT HAVE RIGHTS to distribute, such as some of the hardware associated with the firewire. They must comply with those licenses and rather than have no radio at all, I presume we all want them to comply with their hardware driver requirements. Indeed... We benefit greatly from the low cost of consumer equipment, which in a large part would not exist if someone couldn't make money from the IP embedded therein. On out of band operation: The Flex 5000 hardware will work outside of the ham bands and especially for those MARS frequencies that are near ham bands but I suspect what will happen is that like ALL amateur radio manufacturers, no specs will be provided for the radio out of band. The filters are definitely optimized for the ham bands. I even suspect that if you operate sufficiently below the ham bands significantly inside a filter that covers a ham band, the third order harmonics will not be sufficient suppressed. But that is the nature of doing UNINTENDED use of a piece of equipment. I expect will be not much different than ICOM, Yaesu, Kenwood, Ten Tec, etc. and their bandpass filters optimized for the ham bands. And there is a move afoot in these NTIA regulated areas to start actually measuring the radios that people use, just because the mfrs don't guarantee the specs. NTIS has just made the out of band operation requirements SO severe in any case, in terms of spurious emissions requirements, that NOT ONE amateur radio transmitter currently manufactured, that I know of, can meet it. The spec has always been there.. it's just not been enforced before. I don't have an old copy of the Red Book handy, but certainly as far back as 2003, the spurious emission requirements were the same. I'd suspect the requirements are based on MIL-STD-188-141.. rev B is 1999, rev A is 1988. RevB calls out -60dBc for spurious signals more than 1kHz below the bottom edge of the signal. Broadband noise (not discrete spurs) have to be 90 dB down (120 goal) for frequency more than 5% away from the carrier. Discrete spurs more between 4 tiems the bandwidth and 5% of the center frequency have to be -60dBc, more than 5% away, -80dBc, and harmonics have to be -63dBc. These requirements are quite similar to the redbook, and, in fact, the MIL-STD references the redbook with respect to modulations not specifically described in the standard. This is almost surely the manufacturers of expensive equipment winning the day to prevent inexpensive amateur equipment from being used out there. I don't see it being as malevolently motivated... It's more a recognition of modern technical standards that are *easily* achievable in a mass produced radio. For instance, the frequency control requirement is based on being able to tune a SSB voice channel without needing a clarifier. Since those selfsame amateur equipment manufacturers also make fully compliant radios, with a design that's not much different than the amateur rig, the practical
