Sequencing modes for FCC "Intentional Radiator" test

Question

I'm FCC certifying as an "intentional radiator" a product that uses a custom antenna and off the shelf Broadcom WiFi module. The module has an antenna port, so single-modular and limited single-modular certification are out of the question. I have manual transmitter control, through specialized vendor firmware.

My FCC lab is shuddering at the number of test passes, which are some combinations of:

• Two bands (2.4Ghz and 5Ghz)
• Eight protocols (802.11a, 802.11b, 802.11g, 802.11n, 802.11ac, Bluetooth, BTLE)
• Six modulation techniques (FHSS DSSS OFDM HR-DSSS 256-QUAM CKM) at various data rates from 1 to 54 Mbps.
• Two channel pairings (20 Mhz, 40 Mhz)
• Three regulatory regions (US/Canada, Japan, Europe).
• Bluetooth in three modes.
• DFS (Dynamic Frequency Selection) in the 5Ghz band to avoid radar.

Each test takes about two minutes of stunningly boring waiting, then manual set up of the next band/speed combination.

Is it permissible to use software to sweep each of the data rates (say at one rate per second) and check for out of band exceedances during that time period?

Are there other techniques to speed this process up? See also How do I cycle a WiFi transmitter through all modes, for FCC intentional radiator EMC testing?

Answer 1

Is it permissible to use software to sweep each of the data rates (say at one rate per second) and check for out of band exceedances during that time period?

I doubt there is a rule that you have to walk to the device and reconfigure it and then run another test. However, the product needs to be tested in multiple configurations (like powered or battery mode) and a debug cable is probably not going to be an option because it changes the products configuration. So if you can switch the modes wirelessly (without using another software mode) then this would be probably be acceptable.

But if you already have a quote for time and they don't charge addtional hours, why would it matter? If they charge for extra time, then its in your best interest to make sure the testing goes as fast as possible.

Answer 2

A competent lab would be able to script all this setup action and data acquisition, and provide you with simple ASCII commands over a serial line or TCP/IP port to trigger your device to change operating modes. Your device would receive those and change modes as appropriate.

Labs that do such work and don't like wasting customers' money should have such a script suite ready for the tests you're mentioning - they are not unusual, after all. And they should be able to quickly adapt their script to any special requirements. And they should have an application note that details what commands their script sends, so that you can prepare the device ahead of time. And they should have an "emulator" script that substitutes T&M device control and data collection with suitable pauses, but still sends the serial or TCP/IP data, so that you can easily test your device's proper response. That way, when you go to the lab, it should be quite efficient.

Unfortunately, there is some reluctance in that industry against wasting time. Some labs are much, much better than others in that respect.