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?

[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

[ChetanJoshi_PAN]

 swo_w Hi. I work at Panasonic in the team that promotes PAN1780. In continuation of the discussion above, let me contribute with below:

As an SDR, nRF52840 can be driven by a multitude of stacks. There are ofcourse all the softdevices, but also customer specific stacks with their own PHY definitions. As a manufacturer, we are obliged to work within some reasonable bounds to achieve the FCC grants.  We choose the most commonly used SD’s from Nordic, or work with some specialist stack providers to validate and associate with our radio grants. Customers are free to deploy any soft devices, but in a strict legal sense any such action shall invalidate the FCC grant (that is also printed on the metal casing on the module.) As Panasonic, we are required to inform you on the best integration practices for our products. Should you choose, however, to use a softdevice/radio stack not declared by Panasonic to regulatory bodies, them there are additional steps to be followed. For example - In order to be legally compliant, such cases need to be delcared towards FCC for permissive changes by customers. 

Feel free to drop a mail at [email protected] for any related questions on PAN1780

[Kenneth]

Hi ChetanJoshi_PAN ,

Thanks for the feedback and explaining the reasoning behind the choice of softdevice in the fcc grant. I have made some minor changes to my previous replies. Even though I don't think this thread contain any erroneous information, please discuss or comment whether you want this thread to be confidential.

Best regards,
Kenneth

[ChetanJoshi_PAN]

Hi Kenneth 

I also modified slightly. This doesn’t have to be confidential, atleast on our behalf.