We are currently in the process of FCC certification for a product that uses nRF52832. Our testing house said the the test has failed because of not qualifying the minimum bandwidth requirement.

[jcvandegrift]

Configuration is all 12 combinations of the following 3 x channels, 2 x modulations, and 2 x bit rates were tested to find the worst case. More substantial testing was to follow using this worst case but we did not pass.

The worst case was determined to be Nrf (¿proprietary?) modulation at 1 Mbit, using a modulated carrier.

1) Do I need Nrf modulation to inter-operate with mobile devices?

2) If I don't have to enable Nrf to operate with iOS, Android devices (for example), how do I disable it?

Configuration Params (all 12 combinations of modes and "channels"):

• modulated tx carrier
• static const uint8_t txpower = RADIO_TXPOWER_TXPOWER_Pos4dBm; // max power according to my interpretation
• static const uint8_t channels[] = {2, 40, 80};
• static const uint8_t modes[] = {
  • RADIO_MODE_MODE_Ble_1Mbit,
  • RADIO_MODE_MODE_Ble_2Mbit,
  • RADIO_MODE_MODE_Nrf_1Mbit,
  • RADIO_MODE_MODE_Nrf_2Mbit
• };
• Data payload is random bytes

Note that "channels" is a misnomer... these are frequency offsets to 2400 NOT channel numbers. this is a bug in the SDK.

6dB BW plots.pdf

[ovrebekk]

Hi 

1) You only need to test the bit rates that you will actually use in the end product, so if you are planning to use BLE only then you can remove the Nrf bit rates from the test.

2) What example are you using to test the part? 
It is common to use the DTM examples for BLE testing, in which case the Nrf bit rates are unavailable. 

Have you had the hardware layout reviewed by us earlier? 
Assuming the layout is done correctly you should be able to pass the test on all bit rates. 

Best regards
Torbjørn

 

[jcvandegrift]

1. We've stopped testing with Nrf and are now testing with Ble 1Mbit and 2Mbit. Whichever of those two is the worst will be used for Phase II testing at three frequencies.
2. I'm using an example that I believe came from this forum (didn't re-find it just now). If I find the original posting I'll re-reply here. Since the tester is happy with ignoring the Nrf modes and just using the Ble modes we're progressing.
3. Our HW was reviewed, it was submitted by our HW designer. This is now a SW (well... radio configuration) issue.

I believe that what I need to do is take my nRF52 SDK 14.2.0 examples/ble_peripheral/ble_app_template.c "like" code and force it to NOT allow Nrf modulation... so that our application is using the same RF stuff that our testing is using. Can I block either Nrf mode in my app, or do I have to pick one of the two bit rates for Ble. In my 802.11 days bit rates were dynamically negotiated within each session which implies both Ble bit rates are enabled. Maybe BLE is different?

[AmbystomaLabs]

First, the radio test code does work well for FCC.  Also, as ovrebekk pointed out you only test with the modulations you actually use.  

Second, you should post a jpeg of the failing spectrum analyzer sweep. It will tell a lot about what is going wrong for you.

[jcvandegrift]

When I run nRF52 SDK 14.2.0 examples/ble_peripheral/ble_app_template.c what modulations am I using?

[jcvandegrift]

My initial posting includes a PDF with one plot per mode.

Can you take a look at that?

[AmbystomaLabs]

Thanks for pointing out the pdf.  I missed it.

Well the spectrum from your device definitely does not look normal. A standard nRF52832 has a rather pronounced LO component and then the FSK plus and minus positions are clearly visible. After that the Gaussian filtering is what gives the soft rounding of the signal until you get to the IP3 products out near the edge of the screen. 

The way the FCC rules are written generally this is done as 100k RBW 300k VBW with a max average. It is unclear from the sweep info if this is just peak, max peak or max average.  Based on the look I would say it is just plain a rolling peak.  This would keep the FSK and LO peaks from forming since they have a randomness in their data. Thus it would influence the results.

Here is a sweep of our product: 

If you would like I can point you to the FCC report for our product which passed.  But I remember the results looking similar to what we did in the lab. 

[jcvandegrift]

After digging into the Soft device specification I’ve come to. the following conclusion:

The SoftDevice we use in normal operation only supports BLE (aka LE) 1 Mbit and 2 Mbit modulation/rates. So a “Central” (i.e. mobile device) will choose the rate, but it has to use the BLE modulation we’re already testing for.

The two proprietary modulations, one of which was just failing FCC minimum bandwidth requirements, is only accessible to code that does not use the SoftDevice.

So the proprietary modulation issue is a concern but does not effect our FCC test outcome.