Migrating ble_app_proximity example from SDK 17.1.0 to SDK 3.0.1

I have been using the SDK example ble_app_proximity to flash my demo boards nRF52840 to do some RF PHY testing on Bluetooth advertising.

It was very easy in this example to change the BLE advertising interval as well as the TX transmit power.

It was easy using the SEGGER IDE to re-build the example and flash the board.

Moving to the new SDK 2.x and 3.x, this example ble_app_proximity is no longer part of the nRF SDK.

Is there an equivalent simple example in the SDK 2.0, or SDK3.0 ?  

OS: Windows 10 and 11

HW: nRF52840DK, nRF5340DK

Regards

JM Gayet

  • Hi Edvin,

    I found the issue. The build was failing because the path of one file was longer than 250 characters. I did rename the project name and the build went through.

    I was building the dtm project using the latest SDK v3.1.0. After flashing the dtm image to the board, my CMW100 tester is able t control the nRF54l15DK board in Direct Test Mode.

    Therefore, I have one last question regarding the direct_test_mode example.

    Can you find out where I can change the default TX transmit power in the project? 

    I like the board to transmit more than 0 dBm, which is the default transmit power, but +4 dBm.

    As there is no Bluetooth stack in this project I can't use the the directive CONFIG_BT_CTLR_TX_PWR_PLUS_4=y in the prj.conf.

    I know a way to do it using the customize 2wire command but I will prefer a simple way to change in the project the default TX transmit power.

     

    note: One thing I don't really like on the nRF54L15DK and nRF5340DK is when you plug them on the PC USB port you get 2 COM ports with the nRF54L15 and 3 with the nRF5340 and you never know which port is the valid UART port for the DTM. Details, details...

    Thank for your help

    Regards

    JM Gayet

  • gayetprimo said:
    note: One thing I don't really like on the nRF54L15DK and nRF5340DK is when you plug them on the PC USB port you get 2 COM ports with the nRF54L15 and 3 with the nRF5340 and you never know which port is the valid UART port for the DTM. Details, details...

    Yes, it is a bit annoying. But in fact, they are connected to different UART instances. But the way these COM ports are populated by the OS is no consistent, so I "always" open the wrong COM port on the first try. If you don't remember which port it is, open both, and close the one that doesn't respond.

    gayetprimo said:
    I found the issue. The build was failing because the path of one file was longer than 250 characters. I did rename the project name and the build went through.

    Ah, yes. It is a bit unfortunate that this is a limitation, but the log should say when this occurs. Note that you don't need to move the entire nRF Connect SDK, but you can move the application that you are working on closer to C:\, in order to shorten the path. 

    gayetprimo said:
    I like the board to transmit more than 0 dBm, which is the default transmit power, but +4 dBm.

    If you look in NCS\nrf\samples\bluetooth\direct_test_mode\src\dtm.c, line 452, in static_struct dtm_instance{}:

    dtm_inst = {
    	.state = STATE_UNINITIALIZED,
    	.packet_hdr_plen = NRF_RADIO_PREAMBLE_LENGTH_8BIT,
    	.address = DTM_RADIO_ADDRESS,
    	.timer = NRFX_TIMER_INSTANCE(DEFAULT_TIMER_INSTANCE),
    #if NRF52_ERRATA_172_PRESENT
    	.anomaly_timer = NRFX_TIMER_INSTANCE(ANOMALY_172_TIMER_INSTANCE),
    #endif /* NRF52_ERRATA_172_PRESENT */
    	.radio_mode = NRF_RADIO_MODE_BLE_1MBIT,
    	.txpower = 0,
    #if CONFIG_FEM
    	.fem.tx_power_control = FEM_USE_DEFAULT_TX_POWER_CONTROL,
    #endif
    };

    Line 10 in that snippet is where you can change the default TX power setting. 

    Alternatively, I see that there is an API: dtm_set_txpower() that is defined in the same file. 

    Best regards,

    Edvin

  • Hello Edvin,

    I did find out browsing in the dtm.c example that changing the .txpower in the dtm_inst structure was setiting up the default TX transmit power for the   DUT.

    I tried a value of +4 and it works for the DK nRF54I15, nRF52840 and the nRF9160 used in nRF52 mode. Therefore with the DK nRF5340 it did not work I could not open the COM port with the UART. I have to set back the .txpower to 0 and then the dtm FW was working. I believe when you set the .txpower=4 for the nRF5340, the FW crashes as the maximum transmit power for that board is +3dBm.

    So far so good. I am good with the direct_test_mode and got everything I need.

    Now I need to go back to the Advertising mode and continue the Bluetooth LE classes in the Nordic Academy to better understand how to handle the interrupt and  threading. 

    I have started a new app where I like to change on the fly the Advertising Interval by pressing on the different Button0,1,2,3. Like changing the advertising interval to 20 ms when pressing Button0, 100 ms pressing the button1, 500 ms pressing button2 and 1 s for pressing button3.

    I have open another ticket: Bluetooth LE nRF52840 - Switch BLE Advertising Interval and your colleague Tesc gave me a short answer.

    I need to go back to school now.

    Thank for your great support.

    Best Regards

    JM Gayet

  • I agree with tesc' answer. The issue is probably that you are trying to start the advertising from an interrupt. Another option is to use the interrupt to set a flag, and later read that flag from your main()-loop.

    Best regards,

    Edvin

Related