looking for FCC compliance resources: specifically for the Frequency Block Diagram and Operational Description

[LostInCompliance]

Hi, 

I've been struggling through creating the needed exhibits for FCC certification as a fully modular product. I keep expecting there to be example documents or templates for many of these exhibits, but so far have found next to nothing. Is everyone else just re-inventing the wheel every time someone builds a product using this chip? I've managed to slog through creating several of these exhibits, but looking at the Operational Description exhibit, and the Frequency Block Diagram exhibit I'm feeling a bit lost. It would be great if there were some examples out there that I could look at. Is anyone aware of any resources in that direction that I have perhaps overlooked? 

for reference the TCB is requesting the following:

Operational Description

This file must contain the following information for each radio:

For all devices, an operational description of all circuitry and devices provided for determining and stabilizing frequency, for suppression of spurious radiation, for limiting modulation, and for limiting power shall be provided. This description must agree and relate to the block diagram and schematics of the radio.


Describe the modulation scheme; including the type of modulation, and a description of the modulating signal (e.g. video, audio, or data). Where applicable, include the maximum data rate, modulation index, and maximum transmit time during any 100 ms period. Make reference to any applicable interoperability standards or communication protocols.

For unlicensed rule parts (Part 15 and 18), also include a description of the ground system and antenna, if any, used with the device.

For licensed devices, provide a description of the emissions designator.

For licensed devices, provide information on the manufacturers rated power or the specific operating power levels. If the output power is variable, describe the means provided for variation of power.

For licensed rule parts, NOT operating under Parts 15 and/or 18, provide the dc voltages applied to and dc currents into the several elements of the final radio frequency amplifying stage of the device over the power range for normal operation.

If the device is a Part 15.231(b) periodic transmitter, describe compliance with the timing requirements of 15.231(a) of the FCC rules.

If the device is a Part 15.247 frequency hopping transmitter, describe compliance of the associated receiver with 15.247(a)(1) of the FCC rules. Specifically, explain how the receiver’s input bandwidth matches the hopping channel bandwidth of the corresponding transmitter and how the receiver shifts frequencies in synchronization with the transmitted signal.

If the device is a Part 15.247 frequency-hopping transmitter, describe how the device meets the definition of a frequency-hopping spread spectrum system found in Section 2.1. The description should include the number of hopping frequencies, the time of occupancy (dwell time) per hopping channel, and an explanation of how the hopping sequence is generated (provide an example of the hopping channel sequence). Also include a description of how each of the EUT’s hopping channels is used equally on average.

If the device is a Part 15.247 frequency-hopping transmitter, describe how the EUT does not have the ability to coordinate with other FHSS systems in an effort to avoid the simultaneous occupancy of individual hopping frequencies by multiple transmitters.

NOTE: All of the above information associated for FHSS is also required for licensed devices using FHSS technology.

If the device is a Part 15.247 Digital Transmission System (DTS), provide a description of which protocols are used (i.e. 802.11b/g/n etc).

If the device is a Part 15.407 transmitter, per FCC 15.407(c) include a statement that the device will automatically discontinue transmission in case of either absence of information to transmit or operational failure.

If the device is a Part 15.407 transmitter, provide a description of which protocols are used (i.e. 802.11a/ac/ax/etc)

If the device is a Part 15,407 transmitter operating in the DFS bands, provide information on the security protocol implemented.

For all other Part 15 transmitters, provide a brief description of the circuit functions as well as a description of how the device works.

Frequency Block Diagram of each Radio

This file must contain a block diagram showing the frequency of all oscillators in the device. The signal path and frequency shall be indicated at each block. The tuning range(s) and intermediate frequency(ies) shall be indicated at each block (e.g. LO, IF, XMIT Output).

NOTE: The reason all oscillators in the device are required is due to the FCC reiterating that the highest frequency measured is not only contingent upon the clocks in the radio, but any clock in the device. Consequently, an accounting of all clocks/oscillators in the device must be made/shown in the block diagram.

[Sigurd Hellesvik]

Hi,

Does Ketils answer in  RE: FCC (and CE) certification answer what you need?

Regards,
Sigurd Hellesvik

[LostInCompliance]

Yes, and no. I understand that without an antenna the chip is not a full module. What I don't understand is why there are no documents that helpfully cover the known portions of the various exhibits that the FCC (and other governing bodies) require. I do not mean to imply that this would be Nordics responsibility, I'm just surprised that there are 0 documents out there that illustrate successful approaches others have used to generate these onerous documents. It seems strange to me that each and every entity which uses this chip has to re-create the same information in these documents to cover the use of this chip in their product. In many cases something like 80% of all the information in these documents is directly related to the architecture of the chip, the other 20% being related to software and antenna specifics. 

I apologize if this all seems unfair in this context. Again I do not seek to malign Nordic who makes a great product that has an incredible level of support for development. I guess my experience in how well supported that aspect of the product was just led me to have perhaps unreasonable expectations about regulatory support as well. 

Had I known at the time the difference between FCC compliance and the types of compliance non radio modules enjoy we would likely have gone a different route and used a certified module like Laird/Ezurio's module using the same chip. I would not have chosen a different chip/architecture.  

[Kenneth]

Hello,

It's a fair and good question, I think we have periodically tried to write some kind of application note to address this, but have found that it's very difficult to really maintain such information since it would be needed to be maintained continuously, I can find Bluetooth SIG for instance have an overview, but even them are not very detailed:
https://www.bluetooth.com/regulatory-requirements/ 

If you are interested in FCC in specific, they have some guidelines on their home page that should be helpful. Normally when contacting a test house they will ask for the information you need to provide based on the region you want to sell your product, and pretty helpful overall. FCC also have a search engine where you can search up products based on the FCC ID to find what information that has been provided as a reference also.

There are already a large list of available pre-qualified modules where you can avoid doing this, but I guess that's a bit late in the process:
https://www.nordicsemi.com/Resources/Nordic-Partners/Third-party-modules 

I did in the past prepare some guidelines on what software you need to prepare for the test house:
https://devzone.nordicsemi.com/f/nordic-q-a/93215/example-code-for-fixed-frequency-for-ce-certification 

Kenneth

[LostInCompliance]

I appreciate you taking the time to answer. This is probably a better answer than I could have reasonably expected in response to my initial question.

Should Nordic choose to look into tackling this issue again, I would suggest ignoring (mostly) the issue of maintaining the information. I think simply adding a clear and visible disclaimer, that explains that the example given was written on a specific date, for compliance with a specific revision of the regulatory code in question, would be sufficient. I might even go so far as to add to that disclaimer a statement that says that Nordic does not plan to update the examples given going forward.