nRF52833 Direct Test Mode

[Bryan]

NCS 2.4.0

OS: Windows 10

We are preparing our system for regulatory testing (FCC) on our nRF52833-based device.  So we want to use the "direct test mode" sample.

We wanted to start by running on the nRF52833 DK, but when we try to compile under NCS 2.4.0 we get the build error...

ir/src/dtm_hw.c.obj -MF CMakeFiles\app.dir\src\dtm_hw.c.obj.d -o CMakeFiles/app.dir/src/dtm_hw.c.obj -c ../src/dtm_hw.c
In file included from C:\Users\Bryan\ncs\v2.4.2\zephyr\include\zephyr\toolchain.h:50,
from C:\Users\Bryan\ncs\v2.4.2\zephyr\include\zephyr\sys\time_units.h:10,
from C:\Users\Bryan\ncs\v2.4.2\zephyr\include\zephyr\sys\util.h:582,
from C:\Users\Bryan\ncs\v2.4.2\zephyr\include\zephyr\devicetree.h:21,
from c:\users\bryan\ncs\v2.4.2\zephyr\modules\hal_nordic\nrfx\nrfx_config.h:10,
from C:\Users\Bryan\ncs\v2.4.2\modules\hal\nordic\nrfx\nrfx.h:37,
from C:\Users\Bryan\ncs\v2.4.2\modules\hal\nordic\nrfx\hal\nrf_radio.h:37,
from c:\Virtuix\nordic\myapps\direct_test_mode\src\dtm_hw.h:13,
from c:\Virtuix\nordic\myapps\direct_test_mode\src\dtm_hw.c:9:
C:\Users\Bryan\ncs\v2.4.2\zephyr\include\zephyr\toolchain\gcc.h:81:36: error: static assertion failed: "You must set the dfe-antenna-num property in the radio node to enable antenna switching."

OK.  So we deleted the nRF52833 DK build configuration, created an overlay file based on what was done for the nRF5340 that includes the dfe-antenna-num property, and created a new nRF52833 DK build configuration.   This builds and is flashed into the nRF52833 DK successfully, but the Direct Test Mode app fails to connect.

We do not know where to go from here.  The DTM on the nRF52833 DK used to work way back on NCS 1.9.1 because we used it to do some initial antenna testing.  Can someone explain what we are doing wrong?  Thanks!

direct_test_mode_ncs_2.4.0.zip

[Simonr]

Hi Bryan

I reproduced this on my end as well and this seems to be a bug/conflict with the DTM sample in the later versions of the nRF Connect SDK unfortunately. I will report it internally as I'd assume that this works on any DK even though it isn't specifically supported in the documentation (meaning it haven't been tested and verified properly for the nRF52833 DK). I'm guessing this bug was introduced when we added support for AOA/AOD in the DTM sample.

You can try setting the following in the overlay file which is what we use for other nRF52833 DK samples using Direction Finding features, I'm guessing the GPIOs used aren't the same for the nRF5340 property you copied.:

&radio {
	status = "okay";
	/* This is a number of antennas that are available on antenna matrix
	 * designed by Nordic. For more information see README.rst.
	 */
	dfe-antenna-num = <12>;
	/* This is a setting that enables antenna 12 (in antenna matrix designed
	 * by Nordic) for Rx PDU. For more information see README.rst.
	 */
	dfe-pdu-antenna = <0x0>;

	/* These are GPIO pin numbers that are provided to
	 * Radio peripheral. The pins will be acquired by Radio to
	 * drive antenna switching when AoA is enabled.
	 * Pin numbers are selected to drive switches on antenna matrix
	 * desinged by Nordic. For more information see README.rst.
	 */
	dfegpio0-gpios = <&gpio0 3 0>;
	dfegpio1-gpios = <&gpio0 4 0>;
	dfegpio2-gpios = <&gpio0 28 0>;
	dfegpio3-gpios = <&gpio0 29 0>;
};

Alternatively you can try setting DIRECTION_FINDING_SUPPORTED define to 0 in the application if you don't need Direction Finding support.

I will report back to you when I hear back from the devs. I also have this .hex file that runs on the nRF52833 DK with the DTM app you can use which is confirmed to work with the DTM app for you (this does not support Direction Finding or antenna switching inherently). Hopefully that's helpful.

direct_test_mode_pca10100.hex

Best regards,

Simon

[Bryan]

Thank you for the response.  We do not need direction finding support.  This is only intended for regulatory (FCC) testing.  

I implemented your suggestions, but this did not help.  However, the hex file you sent does work.  

I will wait to hear your feedback from the dev team, confirm it on the DK and then implement on our production board.  

[Simonr]

Hi

The .hex file I sent you should be sufficient for DTM testing. It's also worth noting that we recommend to use the radio_test sample instead of DTM to do FCC testing/certification. You get better control over the radio with this sample than with the DTM sample.

I will keep you updated of any updates in the internal ticket, but can't guarantee that it will be resolved any time soon.

Best regards,

Simon

[Bryan]

Thanks for the help.  I switched to the "radio test" sample and have everything working on our nRF52833-based board. 

Does Nordic have a link somewhere that says "this is the sample you should use for FCC/regulatory testing" that I missed?   I saw the "direct test mode" app in nRF Connect for Desktop and assumed that was the correct thing to use.  

[Simonr]

Hi Bryan

Glad to hear that. The DTM is mainly developed for Bluetooth compliance testing (it runs within the BLE specification), while the radio test sample is better suited for general RF testing as it gives you more control over the radio peripheral as a whole. It's only described as the DTM sample enabling functions described in the Bluetooth core specification, while the radio test sample demonstrates how to use the 2.4GHz short-range radio in a more generic setup (or specifically for BLE).

I totally understand the confusion, and you did not miss a link anywhere.

Best regards,

Simon