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

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.