Forums

Does EVERY device with a wireless transceiver (e.g. Zigbee) need FCC approval?

Started by Mike V. October 13, 2004
I understand that if I make a device which has in it a wireless Zigbee
transceiver (or any active wireless transceiver), that I would need
FCC approval.

However, what if i made a little soapbox-shaped transceiver unit, and
have some wired serial connection (e.g. i2c, CAN, rs323), would I only
need FCC approval on that soapbox unit, regardless of what other
products I connect it to via serial wire?

I guess its analogous to having a Linksys or Netgear wireless router.
The devices that are connected to it don't have to be FCC-approved.

Basically, I need to know if FCC fees will make Zigbee
transceiver-integrated embedded systems expensive than just using one
common FCC-approved Zigbee unit, and wire it to my other products.
Mike V. wrote:

> I understand that if I make a device which has in it a wireless Zigbee > transceiver (or any active wireless transceiver), that I would need > FCC approval. > > However, what if i made a little soapbox-shaped transceiver unit, and > have some wired serial connection (e.g. i2c, CAN, rs323), would I only > need FCC approval on that soapbox unit, regardless of what other > products I connect it to via serial wire? > > I guess its analogous to having a Linksys or Netgear wireless router. > The devices that are connected to it don't have to be FCC-approved. > > Basically, I need to know if FCC fees will make Zigbee > transceiver-integrated embedded systems expensive than just using one > common FCC-approved Zigbee unit, and wire it to my other products.
It's a little hard to understand what you're asking. Most microprocessor-based finished goods need to be FCC-compliant as "unintentional radiators". If you have an "intentional radiator" such as a zigbee transmitter then that probably has to be compliant as well under a different set of rules. As to the test environment, during compliance testing, your device must be connected and talking to devices that it would normally be connected to. For example, a Linksys router would have to be connected and routing packets to other devices while the emissions tests were performed. I probably didn't answer your question, but I did the best I could.
[Please remember to choose only *one* group for followups, if you
crosspost.  Fixed.]

In comp.arch.embedded Mike V. <valemike@yahoo.com> wrote:
> I understand that if I make a device which has in it a wireless Zigbee > transceiver (or any active wireless transceiver), that I would need > FCC approval.
*Every* device you sell (in the U.S.) needs some kind of FCC approval. In other words, the FCC can take any random device at any time, test it, and if it violates some FCC regulation, they'll have it removed from the shelves. So the actual question is what kind of approval you need. For some kinds of devices, approval is implied by the fact they don't do anything likely to cause trouble, for others, you'll have to run tests and present results to the FCC to prove all regulations are met, and you can't go to market without a written statement of approval by the FCC.
> Basically, I need to know if FCC fees will make Zigbee > transceiver-integrated embedded systems expensive than just using > one common FCC-approved Zigbee unit, and wire it to my other > products.
That depends entirely on the properties of the Zigbee standard, like 0) what frequency range it uses 1) how it manages emission strength 2) what parts of it are controlled by immutable hardware, and what parts the software / end user gets to manage E.g., point 2) is what makes life miserable for WLAN hardware support on Linux --- chip manufacturers claim they can't publish complete datasheets because that would enable users to configure the chips to violate FCC regulations (or their counterparts elsewhere) on frequency band usage and emission levels. So you're eventually stuck with a chip that nobody can be allowed to know how to program without signing an NDA and further paperework. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
You sort of answered it, but maybe I can rephrase it. 

Here's one scenario: For example, a third party company sells a little
kit which they got FCC approval on. This kit has an RS232 interface to
attach to other devices. So I buy hundreds of those "plug-in" kits
(well maybe I shouldn't be calling it "plug-in"), and want to
wireless-enable 5 different legacy embedded devices we currently sell.
Will I then need to submit all five of those products for FCC
approval, since the third party kit is already FCC-approved?

I concluded from your answer, Jim, is that the third party kit really
does not need FCC approval, and instead the burden to get it approved
falls on the company using the kit, for each and every product it is
connected to. Oh well.


Jim Stewart <jstewart@jkmicro.com> wrote in message news:<Ov6dnSzcpPbGUvDcRVn-jQ@omsoft.com>...
> Mike V. wrote: > > > I understand that if I make a device which has in it a wireless Zigbee > > transceiver (or any active wireless transceiver), that I would need > > FCC approval. > > > > However, what if i made a little soapbox-shaped transceiver unit, and > > have some wired serial connection (e.g. i2c, CAN, rs323), would I only > > need FCC approval on that soapbox unit, regardless of what other > > products I connect it to via serial wire? > > > > I guess its analogous to having a Linksys or Netgear wireless router. > > The devices that are connected to it don't have to be FCC-approved. > > > > Basically, I need to know if FCC fees will make Zigbee > > transceiver-integrated embedded systems expensive than just using one > > common FCC-approved Zigbee unit, and wire it to my other products. > > It's a little hard to understand what you're asking. > Most microprocessor-based finished goods need to be > FCC-compliant as "unintentional radiators". If you > have an "intentional radiator" such as a zigbee transmitter > then that probably has to be compliant as well under > a different set of rules. > > As to the test environment, during compliance testing, > your device must be connected and talking to devices > that it would normally be connected to. For example, > a Linksys router would have to be connected and routing > packets to other devices while the emissions tests were > performed. > > I probably didn't answer your question, but I did > the best I could.
Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> writes:
> In comp.arch.embedded Mike V. <valemike@yahoo.com> wrote:
> > Basically, I need to know if FCC fees will make Zigbee > > transceiver-integrated embedded systems expensive than just using > > one common FCC-approved Zigbee unit, and wire it to my other > > products. > > That depends entirely on the properties of the Zigbee standard, like > > 0) what frequency range it uses > 1) how it manages emission strength > 2) what parts of it are controlled by immutable hardware, and what parts > the software / end user gets to manage > > E.g., point 2) is what makes life miserable for WLAN hardware support > on Linux --- chip manufacturers claim they can't publish complete > datasheets because that would enable users to configure the chips to > violate FCC regulations (or their counterparts elsewhere) on frequency > band usage and emission levels. So you're eventually stuck with a > chip that nobody can be allowed to know how to program without signing > an NDA and further paperework.
So the chip manufacturers will allow you to mistakenly violate FCC regulations because they won't give you the info needed to avoid doing so?
"Mike V." <valemike@yahoo.com> wrote in message
news:8188616d.0410140403.5887d312@posting.google.com...
> You sort of answered it, but maybe I can rephrase it. > > Here's one scenario: For example, a third party company sells a little > kit which they got FCC approval on. This kit has an RS232 interface to > attach to other devices. So I buy hundreds of those "plug-in" kits > (well maybe I shouldn't be calling it "plug-in"), and want to > wireless-enable 5 different legacy embedded devices we currently sell. > Will I then need to submit all five of those products for FCC > approval, since the third party kit is already FCC-approved?
If you hook up the approved kits to your device and leave them external, you don't have to approve your device as an intentional radiator. If you build the kit INTO your device, you most probably have to approve your device or state the approval from the RF kit in the manual of your device and on a sticker on the device. It works the same as when you buy Bluetooth modules from TDK, in particular their TRBLU20 modules. These modules are approved as an end-product and have an FCC ID. With the module comes a sticker, which I have to put on the ouside of my device in which I use the BT module. I also have to state the FCC ID and the used module in the manual or declaration of conformity and that is all I have to do to be compliant with the FCC regulations. Meindert
Everett M. Greene <mojaveg@mojaveg.iwvisp.com> wrote:
> Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> writes:
[...]
> > band usage and emission levels. So you're eventually stuck with a > > chip that nobody can be allowed to know how to program without signing > > an NDA and further paperework.
> So the chip manufacturers will allow you to mistakenly violate FCC > regulations because they won't give you the info needed to avoid > doing so?
That's not something for the manufacturer to "allow", anyway. If people want to make mistakes, there's exactly nothing their parts suppliers can do about that. The message essentially is "Since mistakes in this area could lead to legal repercussions for both you and us, we're not telling you *anything* about the device, so you won't even get to the point where you could make them until." The part maker wants someone else they can point the blame to in case the FCC or one of its international brethren comes after them. At the root of all this is that WLAN regulations are different in various regions of the world, but the parts makers want to sell the same hardware everywhere. To get out of that fix, they make the chips software-driven, with the firmware uploaded by the OS driver for the chip adapting it to the local specifics of regulation. But that means errors or manipulations to that firmware are all it would take to violate those regulations. In the end, this means that something happened that wasn't originally foreseen: that pure software could be under FCC regulation. Now all that remains is to find a way to stick an FCC approval seal onto a driver update downloaded from some website... To some extent, this is the result of a conflict of cultures between lawyers and engineers. Every engineer will know that shit sometimes just happens, with no individual to be blamed. But the world of law refuses this notion, following their ancient principle "It doesn't really matter who, but some punk _will_ hang for this", amended by the golden rule of all corporate lawyering: "... and it's sure as shit not going to be us!". -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Everett M. Greene <mojaveg@mojaveg.iwvisp.com> wrote:
> Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> writes:
[...]
> > band usage and emission levels. So you're eventually stuck with a > > chip that nobody can be allowed to know how to program without signing > > an NDA and further paperework.
> So the chip manufacturers will allow you to mistakenly violate FCC > regulations because they won't give you the info needed to avoid > doing so?
That's not something for the manufacturer to "allow", anyway. If people want to make mistakes, there's exactly nothing their parts suppliers can do about that. The message essentially is "Since mistakes in this area could lead to legal repercussions for both you and us, we're not telling you *anything* about the device, so you won't even get to the point where you could make them." The part maker wants someone else they can point the blame to in case the FCC or one of its international brethren comes after them. At the root of all this is that WLAN regulations are different in various regions of the world, but the parts makers want to sell the same hardware everywhere. To get out of that fix, they make the chips software-driven, with the firmware uploaded by the OS driver for the chip adapting it to the local specifics of regulation. But that means errors or manipulations to that firmware are all it would take to violate those regulations. In the end this means that rather unexpectedly pure software can fall under FCC (et al.) regulation. Now all that remains is to find a way to stick an FCC approval seal onto a driver update downloaded from some website. To some extent, this is the result of a conflict of cultures between lawyers and engineers. Every engineer will know that shit sometimes just happens, with no individual to be blamed. But the world of law refuses this notion, following their ancient principle "It doesn't really matter who, but some punk _will_ hang for this", amended by the golden rule of all corporate lawyering: "... and it's sure as shit not going to be us!". -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
> Here's one scenario: For example, a third party company sells a little > kit which they got FCC approval on. This kit has an RS232 interface to > attach to other devices. So I buy hundreds of those "plug-in" kits > (well maybe I shouldn't be calling it "plug-in"), and want to > wireless-enable 5 different legacy embedded devices we currently sell. > Will I then need to submit all five of those products for FCC > approval, since the third party kit is already FCC-approved?
Any device sold needs to have FCC approval (within the expectations of the appropriate class). If you take an approved kit and attach something to it and sell it you'd have to get your part of it approved. The thing you're attaching would require it's own FCC approval regardless of what devices were attached to it. You can't "leech" off the approval of the other device nor does yours 'rub off' onto the other. As in, a computer attached to an FCC approved UPS would certainly still need it's own approval.
> I concluded from your answer, Jim, is that the third party kit really > does not need FCC approval, and instead the burden to get it approved > falls on the company using the kit, for each and every product it is > connected to. Oh well.
If you sell something then you'd be well advised to be sure of it's approval. If you're 'bundling' it as a kit of your own then you may be incurring approval risks. It would make very good sense to contact the FCC directly and ask them. Follow this with assurance from a lawyer skilled in handling FCC licensing issues. -Bill Kearney
wkearney99 wrote:

much snippage...	

> Any device sold needs to have FCC approval (within the expectations of the > appropriate class).
more snippage... Just to be pedantic, the FCC does not approve anything. To the best of my knowledge this is how it works: Your product can be compliant, which means you tested it and you state that it meets regulations, or it can be certified, which generally means that a trusted third-party lab has tested it and found it to be compliant.