BLE Software configuration for FCC Spurious Emissions Test

[David Smoot]

I have a dual mode BLE / ANT+ nRF51422 design going through regulatory testing for FCC / EU marketing approval. I have previously successfully tested a very similar design with Ant+.

One of the tests that I am required to do is the "Spurious Emissions Test" where we transmit at the lower, mid and upper points in the allowed 2.4 GHz range while the facility measures peak and average power outside the allowable range. The test facility requires us to limit our transmissions to a particular set of channels. We must configure our system to only use 2.402 GHZ, then repeat with only 2.442, then again with 2.480.

For the Ant+ design, it was trivial to simply change the channel used to meet this testing configuration.

For our BLE design, I do not see a simple way to accomplish this frequency restriction. In the S310 API I see the ability to set the ble_gap_opt_ch_map_t and restrict the channel map. But I would also have to restrict advertising as well. And even if I configured my unit under test to run our current software load over a single BLE channel, I would have to have another BLE radio in the test chamber in order to generate any BLE traffic beyond basic advertising which would result in an inaccurate test

To further complicate the matter, the test facility states that it is acceptable / "standard practice" to simply test the unit in advertising mode on these restricted channels. I believe they are misinterpreting the standard. If you only test in advertising mode, your packet rate is typically much lower than your "active connection" packet rate. If your packet rate is much lower, then your measured average power of any emissions outside the acceptable range is going to be artificially lower than the worst case of an active transmission.

We advocate a different approach. We proposed using the "radio test" example code to generate a worst case signal, where the radio is transmitting continuously a modulated signal at a particular data rate on a single frequency. The facility measures the peak and average power outside the acceptable band at this configuration. Then we do a mathematical calculation of how much lower our actual peak data rate is than this worst case and we calculate a dB offset based upon this calculated number. We base our calculation upon our number of transmission buffers and the transmission interval these packet buffers are used in. We based this approach on FCC documentation and other vendor documents

So finally to the questions

1. Am I correct that testing only in advertising mode will result in a much lower average power than an average packet rate power level?

2. If yes, is that a concern for FCC / EU spurious emissions or is that simply the way it is done?

3. Is the approach of test worst case and calculate a DB margin based on packet duty cycle a valid approach.

4. Is there a better way to accomplish this type of testing on an nRF51422 s310 version 3 / SDK 9 based design?

Thanks for your time if you read this far, David

[Øyvind Karlsen]

Hi,

1) You are correct that the most meaningful/convenient way to test is using the radio_test provided with the SDK. However you should take a second to consider what is actually being tested. What you test is the unwanted second, third, and so on effects caused by the harmonics to your signal. The chip will transmit a carrier at a given frequency, this frequency is shifted slightly up or down to get a logical '0' and a logical '1', this is called FSK modulation.

When you measure this is the lab you will normally use a spectrum analyzer, and your device flashed with frimware that will transmit only at a given frequency, for example channel 2(2.402 GHz). To be sure that you are within the absolute limits set by the FCC you will set your spectrum analyzer to capture the largest value it sees. This means that if your device is advertising at all the frequencies at once, or wether you test one single frequency at a time you will get the same results(time-averaged). There are multiple reasons for testing one single frequency at a time, for instance it makes it a lot easier to see which frequency is causing problems(if there are some)

1) When not using data packet length extension (DLE), available from S132 v.3.0.0, directed advertising has the highest duty cycle in BLE. The duty cycle of directed advertising is 5 %. When doing regulatory testing, FCC for instance, the easiest is to use the radio_test example in the SDK, set it in constant carrier, and measure the harmonics. If the maximum level of the harmonics exceeds the average maximum (but is within the maximum level for the harmonics), the maximum duty cycle for the application (or BLE for simplicity) can be used to calculated the real average of the harmonics.

This post explains the maximum duty cycle when using DLE.

2) For regulatory testing, it is easier to do the testing if you can control the radio directly, like with the radio_test example. Regulatory tests are independent of the protocol, so there is no need to use a softdevice during those tests.

3) Yes, calculate max average of harmonics based on the worst case scenario duty cycle is the easiest way to find average for the worst case scenario.

4) Your approach is the way to go; use the radio test example.

It can be usefult to have a look at our Regulatory and compliance testing whitepaper.

[FormerMember]

This is a slightly late reply.

@endnode : In FCC, the duty cycle is based on the maximum time on air on one channel over a period of 100 ms. If not using DLE, just regular 20 byte packets, the duty cycle when in a connection on a given channel will be very low, because the channel will change for every connection interval, and it will take some time before the same channel is being used over again. However, when advertising, the three advertising channels are being used for every advertising interval. Since directed advertising has the shortest advertising interval, directed have highest duty cycle.

@dinosak : Yes, that's correct, FCC, CE don't care if the product is Bluetooth, ANT, or something else. Therefore, for FCC, CE (ETSI) testing, you can use the radio_test example.