• State Verified Answer
  • Replies 9 replies
  • Subscribers 86 subscribers
  • Views 2729 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 318971
Options

Does custom firmware invalidate FCC modular approval?

ecorm

When using a third party pre-approved module, does using my own custom firmware invalidate the modular approval status of the module?

More specifically I would like to use a certain pre-approved nRF52805 module, but it comes preloaded with BLE firmware and an AT command interface that allows it to be customized somewhat.

I don't want to pay the exorbitant Bluetooth Qualification fees that bars entry to small start-ups and open-source projects. The device I'm developing is a wireless remote control that can only be paired with another device I'm also developing. So I would prefer to install firmware that uses the Gazell protocol stack instead, which I understand to be royalty-free. Ideally, I would like the module to also run my custom remote control firmware instead of having a separate host MCU.

So, does the modular approval status get invalidated if:

1. I install custom application firmware that runs on top of the Gazell protocol stack?

2. I install the Gazell protocol stack and minimal firmware that allows the module to communicate with a host MCU running the custom application?

Parents
  • +1

    I have just stumbled upon this App Note from Wurth Elektronik that explains things better than anything I have found so far:

    ANR031 - Certification of custom modules

    https://www.we-online.com/components/media/o705723v410%20ANR031_CertificationCustomModule.pdf

    As a bonus, they have nRF-based modules which use a proprietary protocol. I'll check them out to confirm they are royalty-free and appropriate for my application. Note: I am not affiliated with Wurth Elektronik in any way, and I'm not even an existing customer.

  • 0 in reply to ecorm

    I was considering the "Permissive Change Class 1" route, but as the Gazell and BLE stacks seem to be closed-source (understandably), I am not sure if this is easily demonstrable.

    The 178919 D01 Permissive Change Policy v06 document has some guidance on permissive changes.

    Assuming that Gazell uses the proprietary Nrf_2Mbit RADIO mode (as opposed to Ble_2Mbit mode), that is yet another complication in pursuing the FCC permissive change route.

    It would be way simpler for me if a third-party module vendor were to certify their module using the Gazell protocol. Either that, or I pay Bluetooth SIG their exorbitant fees, including a lawyer to interpret all their terms and conditions.

  • 0 in reply to ecorm

    I've done some more digging, and it appears that NRF_GZLL_DATARATE_1MBIT_BLE and NRF_GZLL_DATARATE_2MBIT_BLE can be passed to the nrf_gzll_init function. The fact that Gazell can be configured to use the same modulation modes as the BLE SoftDevice gives me more optimism that an FCC "Permissive Change Class 1" can apply if I reflash a certified module to use Gazell. In particular, I was worried about the 6db bandwidth requirements of FCC 15.247 (a)(2).

    I'm posting my findings here in case it helps others in the same predicament as I. I hope this is okay.

Reply
  • 0 in reply to ecorm

    I've done some more digging, and it appears that NRF_GZLL_DATARATE_1MBIT_BLE and NRF_GZLL_DATARATE_2MBIT_BLE can be passed to the nrf_gzll_init function. The fact that Gazell can be configured to use the same modulation modes as the BLE SoftDevice gives me more optimism that an FCC "Permissive Change Class 1" can apply if I reflash a certified module to use Gazell. In particular, I was worried about the 6db bandwidth requirements of FCC 15.247 (a)(2).

    I'm posting my findings here in case it helps others in the same predicament as I. I hope this is okay.

Children
Related
Terms of service