Softdevice Controller in Zephyr

[swo_w]

We're evaluating options regarding pre-certified modules. Usually modules are certified using a specific SoftDevice. The module we liked to use is FCC (and more) certified using S113 and S140.

I understand Zephyr no longer uses the same SoftDevice found in the nRF SDK. The (new) nRF Connect SDK can use a SoftDevice Controller with Zephyr Host. nRF Connect SDK no longer seems to use the S113 en S140 labels since version 1.5.0.

Current documentation: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/softdevice_controller/README.html

Documentation 1.4.2: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.2/nrfxlib/softdevice_controller/README.html

Did NCS just relabel the SoftDevices or is the current SoftDevice a completely different version and might the FCC certification no longer apply?

[Kenneth]

Hello,

There is no direct relationship/dependency between the softdevice implementation used and the radio regulations. 

The FCC and ETSI only make sure the module meet the radio regulations in terms of output power, harmonic and spurious emissions. There are some regulations that potentially also require specific requirements of the protocol used (e.g. in terms of hopping etc), however it's very uncommon to qualify or certify according to these regulations, since it limit the usage of the module and since Bluetooth do not meet these regulations. I am not aware of any. You can find a full list of pre certified FCC and ETSI qualified modules with various nRF chips here:
https://www.nordicsemi.com/Nordic-Partners/3rd-party-modules

The softdevice used will however impact the QDID you must refer to when listing the product with Bluetooth SIG, all available softdevice(s) that have been qualified can be found under the specific nRF52 product and depends on which software release you are using in your product, see here for an example for the nRF52840:
https://infocenter.nordicsemi.com/topic/comp_matrix_nrf52840/COMP/nrf52840/nrf52840_ble_qdid_qual_matrix.html 

Hope the helps,
Kenneth

[swo_w]

Hello Kenneth,

Thank you for your reply.

It's interesting you say it's unusual.

Looking at for example the PAN1780 (also in the list with pre-certified modules) they claim in their product specification (  https://mediap.industry.panasonic.eu/assets/custom-upload/Devices/Wireless%20Connectivity/Bluetooth%20Low%20Energy%20Modules/PAN1780/WM%20PAN1780%20Product%20Specification.pdf ) :

6.1

"Regulatory certifications are valid for the following radio relevant software:
• Nordic SoftDevice S140, S113, and Wirepas V4.x or V5.x
• Bluetooth Specification 5.1"

and

6.2:

"Regulatory certifications are valid for the following radio relevant software:
• “Nordic NCS SDK V1.x libnrf-802154” This library implements modulation
according to the IEEE 802.15.4-2006 standard with a 250 kbps 2 450 MHz
O-QPSK PHY."

In emails Panasonic also claims you cannot use other protocols or other SoftDevices than listed (S113&S140) without re-certification(s). This is why my in my original question I asked about the used SoftDevice in NCS.

According to the information in the Product Specification and emails we should/could not use Enhanced Shockburst, Gazelle or maybe even LLPM (which as I understand is no longer actually BLE) either without re-certification.

[Kenneth]

Hi,

I did a search on the fcc id used here:

And did find in the test report:

That they have stated SD140 and SD113 in the FCC listing.

Based on this I agree with you and them that you will need to use those two specific softdevices. However for all pratical purposes this is nitpicking, because both the S140 and softdevice controller in ncs do state for instance Bluetooth 5.1 compliance, so they are the same.

I might expect other modules might not been this specific, but instead claimed Bluetooth LE or similar. In that case I would expect this to not be a problem.

I would like to mention that if you go to the Bluetooth core spec you can find that they do list which regulation that should be used around the world, and I do believe this has been unchanged since Bluetooth v4.0 where BLE was introduced.

LLPM use Bluetooth PHY, the only difference is tighter timing, which allow more reliable transfer and lower latency in poor conditions with much interference. In terms of time on air and throughput with LLPM vs. normal Bluetooth LE it is the same in ideal conditions, so there is no change that should affect regulations with LLPM. 

All that said, you have a valid point about ESB and Gazell, these use a slightly different deviation on the GFSK compared to BLE, and may not be used if not in specific tested by the module manufacturer, though that is not entirely true either, since the 2Mbps of ESB and Gazell should for all practical purposes comply to the same as BLE.

Hope that make sense,
Kenneth

[swo_w]

Apparently I cannot reply to your message, so i'll reply to this one.

This is indeed the FCC report that states the use of SD140. There are actually quite a few manufactures that also mention the use of S140, Fanstel is one of them. Many others just list "BLE 5.x" etc.

I'm not sure for example Panasonic agrees the SoftDevices are the same, but if they implment the same BLE spec and both passed qualification tests so it must be the same from a functional point of view.

One other question that arises regarding the use of LLPM. Since LLPM is a proprietary extension of Nordic, I would say it violates the BLE spec. So if a manufacturer claims it should be "BLE 5.1", strictly speaking you cannot use LLPM?

And if indeed LLPM violates the BLE specifications , can you say BLE Qualification no longer applies... (I assume  you cannot pass qualification tests with this extension enabled)?

[Kenneth]

I don't want to argue on this, since it's really the module manufacturer that knows the best, and I am sure they also want to protect their own module from malicious use. I can fully understand that. What I am saying is that looking at the radio (which is the one that is measured in FCC and ETSI) there are no difference to the output power, harmonic and spurious emissions due to moving from nRF5 SDK softdevice to the nRF Connect SDK softdevice controller. The difference is how the "stacking" of the software api is done, this does however not affect the radio. I think it also worth mentioning that the softdevice is not tested at the test house, instead they are running radio tests that configure the radio phy of BLE. But all that said, please follow the guidelines of the module manufacturer and use module that apply to your specific usage.

Kenneth

[swo_w]

Thank you for your explanation. I understand you don't want to argue what a module manufacturer states.

Can you say anything regarding the use of LLPM and if  LLPM still requires BLE qualification (regardless of the used module)? Since it's no longer fully compliant with the official BLE 5.0 specs (unless I'm wrong stating this..)

[Kenneth]

swo_w said:

Can you say anything regarding the use of LLPM and if  LLPM still requires BLE qualification (regardless of the used module)?

I am not aware of anyone doing any specific radio qualification in terms of LLPM, and from the radio perspective I can't see any reason why they should be either. The only difference with LLPM is the timing between the packets on air, it does not change the charactertistics of the packet itself, actually the peak throughput with LLPM is lower than what you can get with normal BLE, however LLPM only ensure that the overall latency and robustness of the link is improved in noisy environment.

Edit: When you use LLPM you will still need to list your product with BT SIG (and use the QDID for the specific softdevice controller in question), because LLPM do use BLE for all the initiate connection, security procedures according to BLE, the only difference is that it can enter a shorter lantency mode than BLE if both sides of the link support it.

Kenneth