SIG Declaration for Softdevice

[Simon]

Hello,

two part question;

-when a device is registered with the FCC, there is a good amount of documentation uploaded to the FCC website like test reports, photos of the device, operations manual and so on which anyone can see the chip type, layout and how it is used.
Whereas on the Bluetooth SIG site, it is on the registrar to choose which chip was used for the Declaration, and in Nordic's case, also choose which Softdevice version was used.
How then have Nordic customers established proof that a certain Softdevice noted in the QDID is the one actually being used in the device?
Other than showing SES code, or running the hex through Programmer, or a piece of paper drafted by the designer saying this is the Softdevice we are using, what type of documentation are users of Nordic chips showing as proof that this is the Softdevice version flashed to the chip?

-the above question is partly due to this.
When you start developing with say the nrf52832 chip, the SDK code will naturally steer you to use s132, and all other examples that you may choose to merge will also be using SD s132, and everything will be working fine with s132 since most available code for the 832 is written with s132 as SD. If you choose to develop for nrf52810, then examples will be based on SD s112 because 810 will never be a central. The 832 device under development is entirely a peripheral, no central capability whatsoever. Even the SDK directory says ble_peripheral.
Once the product is released and Declared with SIG as 832 with s132 QDID, the developers over time will find ways to add features to the product and maybe use FDS more. With FDS more flash space may be required and the best way to get more flash is to shed central code in the SD. By switching over to s112 using DFU, the same device keeps operating as an updated peripheral product but with more flash space.
The product is better, FCC is ok since radio is the same, everyone is ok except SIG because the SD is now s112. Since the original Declaration was s132, a new Declaration needs to be purchased only because the device needed more flash space and not because the device is no longer functioning as a central.
Is this a case of tough luck, or something not fully anticipated by the Declaration because of how a Softdevice for the 832 can be used?

thank-you,

[ketiljo]

It's not the specific softdevice that is the limitation for the QDID but the features you use. You can upgrade the softdevice to a newer version and if you don't extend the feature set, you don't have to re-list. If you for instance use 1 Mbps datarate, you can't upgrade to 2 Mbps without re-listing. 

[Simon]

Is upgrading a released product from s132 to s112 to get more flash space considered an extension of the feature set?
Which QDID for nRF52832 would cover the upgrade from s132 to s112?

[ketiljo]

You have to look at the features you're using and make sure you don't use any more features, unless you want to re-list. 

[Simon]

Since S112 is a sub-set of S132 (as is S113), then the official position of Nordic Semiconductor ASA,
is that a re-list is not required with SIG if the registered device transitions to S112 from S132,
because more features were not used or as in this case, more flash space was required?

[ketiljo]

If the functionality is exactly the same, with no additional features being used, no re-listing will be needed. 

[Simon]

This is not the same answer I received from BT-SIG:

When Adding a Product to your existing declaration. You will need to certify that the new product(s) share the exact same unmodified Bluetooth design (QDID) as the existing listed products. You will be able to add an unlimited amount of products that share the same design at no additional cost.
Please let me know if you have any further questions or concerns.
Best,
Jonatthan Jean-Pierre

[run_ar]

Hi,

Ketil asked me to take a look at this to get a second opinion. I also checked with our qualification expert. We all agree that in this case you can change SD from  S132 to s112 without creating a new product declaration. But to do this is is important that you do not change the ICS.

In our case we are using the same codebase/design for all our softdevices. This makes the S140 the superset supporting all features. Both S132 and S112 is a subset of this. This means that if you use the S132 and only utilize the peripheral features, it will behave the same as the S112 running the same application, as the S112 has a smaller feature set than the S132.

If you want to take a closer look at our qualifications you can see how the superset LL and Host qualification have references to the subsets here:

https://launchstudio.bluetooth.com/ListingDetails/101754

https://launchstudio.bluetooth.com/ListingDetails/101321

As for the bluetooth SIG statement. As mentioned, you cannot make any changes that dictates that you should change the ICS. In this context the ICS is the product specification. As your BT-SIG contact states, you can add an unlimited amount of products to share the same design (ICS/pixit) at no additional cost.

[Simon]

I doubled checked with SIG on changing SD from S132 to s112 without creating a new product declaration;
"I ran your reply past the rep at Nordic "that the new product(s) share the exact same unmodified Bluetooth design (QDID) as the existing listed products",
and Nordic confirmed as well that as long as our new product does not change the ICS we can use a subset of the superset QDID used in the declared QDID,
https://launchstudio.bluetooth.com/ListingDetails/74321, and continue to add new products based on this exact same design to the same DID."

the reply from SIG;
"After review, the End Product QDID does not consist of any deprecated profiles. This allows for a subset to be created if needed to reference the supported profiles of the design."

more information on Subsetting here;
https://support.bluetooth.com/hc/en-us/articles/360049019592-subsetting

thank-you,