nRF52 series Continuous Carrier Issue

[Julian Dinsdale]

We have product under final development which uses an nRF51822 as a peripheral to a RP2040.  Product has worked well for many months using Nordic proprietary radio TX/RX.  On the nRF51 series there is TEST a radio register 0x540 which allows the nRF&51 to be placed into a constant carrier more to allow compliance testing.  This seems to have been left out of the radio registers on the nRF52811 and presumably it is not activated.

There are reference drivers for the nRF52 series that purport to be able to activate a constant carrier on the nRF52 series. In viewing the driver in some detail I cannot get any understanding of how the nRF52811 is put into a constant carrier mode

We have our own nRF52 series driver running well under MicroPython. We wish to add a function that allows for a continuous carrier.  Is there a document or an application note that specifically defines how the registers of the nRF52811 should be managed to place the chip into a constant carrier mode

Our existing pcb modules have the nRF52811 as a peripheral  to. RP2040.  The nRF52811 is programmed via the SWDIO/SWCLK and data is exchanged between the nRF52811 and the RP2040 via an SPI interface.  The radio on the nRF52811 works well and testing show that at least 8 adjacent 1 MHz channels operate continuously with a very low error rate.  The modules have an on- board antenna etched into the pcb

We now need to perform pre compliance and compliance tests but cannot do so until we can set up a continuous carrier.  We can control the channel number and transmit power with the existing driver

Any assistance with identifying what registers are involved in setting up a constant carrier would be appreciated

[Hieu]

Hi Julian,

Continuous carrier is demonstrated in the Direct Test Mode sample/application. In particular, here is the code that start the continuous carrier mode: https://github.com/nrfconnect/sdk-nrf/blob/v2.6.1/samples/bluetooth/direct_test_mode/src/dtm.c#L1443-L1473.

Please give this implementation a try and let me know if that works.

Hieu

[Julian Dinsdale]

Hi Hieu

Many thanks for your response which was appreciated. 

We actually have a version of Zephyr application compiled and  running.  We need to run it independently via Putty but it works.  We have been able to use it to demo hardware operation of the antenna and spectrum generated and all seems fine at the laboratory level. 

My main reason for making the inquiry was that the testing of devices that operate in the 2.4GHz spectrum has become all the more necessary as different authorities tighten up on compliant requirements.  This is certainly true here in Australia where any product that works in the 2.4GHz spectrum must have an Australian compliance mark attached to the product before it can be sold into the market.  This is similar to the CE marks in the EU

We can and do test the products which we design for compliance and it is a laborious and expensive process.  We use the nRF51 or nRF52 series on a number of modules.  We use MicroPython and have operating drivers that work with both the nRF51 and nRF52 series products.  We are only using these products in a limited way - primarily the Nordic proprietary operation.  The products are used in the schools and Universities in Australia primarily for teaching and research. 

The Zephyr application is downloaded onto our modules to activate a test mode which we can then use to undertake pre-compliance testing.  This means we load different firmware onto the board to run testing and we then need re-load the operating firmware to place the modules into their normal mode of operation.  Compliance testing seems to require  the actual firmware supplied on the product to be used when testing compliance.

The MicroPython generic driver for the nRF51/52  API's that we use are shown for the nRF51 and nRF52 in Read the Docs at

https://kookaberry-reference-guide.readthedocs.io/en/latest/nrf51.html

What we are currently trying to achieve , in the first instance, is to add API's into this driver that will  provide similar functions to the start_tx_carrier and start_tx_modulated_carrier   -  we can currently set the tx power and channel number.

If I read your response correctly I can only assume that Nordic does not have any other published information as to how the tx carrier and tx modulated carrier are activated except for the method that is buried in the Zephyr application and the driver for this, which you sent. It is surprising that Nordic has not had this type of request before now.  

We will continue to investigate and see if it is possible to enhance the MicroPython driver to include the additional functions to assist us with pre-compliance and compliance testing

Again, many thanks for your response which was most appreciated

Kind Regards

Julian Dinsdale

[Hieu]

Hi Julian,

Julian Dinsdale said:

Compliance testing seems to require  the actual firmware supplied on the product to be used when testing compliance.

For referencing purpose, could you please guide me to the information about regulations that require the tests to be done with the same firmware that the product is shipped with?

Best regards,

Hieu

[Julian Dinsdale]

Hi

Please see ETSI  300 328 clause 4.2.1 

regards

julian Dinsdale

[Hieu]

Hi Julian,

Do you not think ETSI 300 328 clause 5.3.1 means that a special software may be used to perform continuous carrier mode?

Otherwise, I am struggling a little to find any requirement that the UUT must use the same software as the final product.

Best regards,

Hieu