adjusting RF channel used to transmit.

This previous case is an example of what i am trying to do.Reconfifure the radio parameters.

 nRF52840 BLE/NFC compliance testing, How to Change Channel & which tool to use ? 

 Using example code does not work for me. the DUT has other aspects that need to be EMC compliant, firmware is required to drive these aspects. I also have no access to a serial or UART port on the DUT. So, i cannot simply load example code in (which doesn't complile and run properly anyway!). Additionaly, i dont see this being a valid test platform, even if i did have uart communications on my board. This is not representative of the devices normal operation, so just loading example code in for compliance testing does not seem legitimate?

Having dug through this example i am trying to use some of the functions that the example uses, to make basic adjustments to the physical characteristics of the radio output.

This is for pre-compliance testing. Thus relatively informal.

As per the attached thread. I am starting by trying to simply adjust the channel on which the device transmits. - nothing complex. Just this to start with.

I am trying to do this with the following function. Currently this is run while the device is advertising (possibly part of my problem?) and throws up errors. Beleive the error is softdevice invalid memory access, what must i do to the ble to be able to adjust channel number during operation?


radio_channel_set(NRF_RADIO_MODE_BLE_1MBIT,0);

I can find no obvious set of rules for this function and next to no useful/meaningful documentation for it. But it clearly pretains to what i need to do.

Note: I do not want to pursue some highly abstracted solution. I am on a tight deadline and have tried including the radio_cmd file & other solutions that do not directly call the nrf_radio functions, but i faced endless dependancy issues that i simply dont have time to solve). I just need this function to work when called directly.

Parents
  • Hi Sean,

    We provide mainly two examples that can be used to test the radio HW. The first is the radio test example that access the radio directly and configures it based on user input. The second example is the DTM example which implements the DTM test functions as specified in the Bluetooth Spec. Both examples access the radio registers directly.  When using the Softdevice, radio access will be blocked. All configurations of the radio registers must either be through the Softdevice API or by using Radio Timeslot API

    what must i do to the ble to be able to adjust channel number during operation?

    You can set a channel map with the Softdevice if it's a GAP Central. 

    regards
    Jared 

  • All configurations of the radio registers must either be through the Softdevice API or by using Radio Timeslot API

    Q1: Why? When both the examples you refer to, seemingly do not use the softdevice API? they use functions from the nrf_radio.c file, which seems to directly access the radio registers? Can i not just disable the softdevice, reconfigure the radio, then re-enable the softdevice?

    Q2: Should i run radio test functions,with or without the softdevice enabled?

    As i stated in my original post, i am not in a position to use the example code, i need to modify my existing application to feature radio tests (again, this is pre-compliance testing, so informal). Bespoke boards are not well suited to example code: For starters the code is hilariously un-annotated, so i have no idea what it is actually doing on physical layer, this is a terrible position to be in, in an embedded environment. It assumes i have access to hardware such as uart ports (which i dont). Additionally, the examples never build without hours of adjustments, to both SDK & source code.

    So again, i am not looking to be referred to examples, im on this forum because i've reviewed the examples and cant find what i need, i'm looking for simple written explanations (NOT GENERATED BY DOXYGEN!).

    As before: I am working with the below few lines of code:

     APP_ERROR_CHECK(nrf_sdh_disable_request());        //stop SD to avoid access error
     radio_channel_set(NRF_RADIO_MODE_BLE_1MBIT,1);     //change channel.
     ble_init(false);                                   //re-init ble & stack, arguement allows me to qvoid re-initialising queued write module
                                                        //(no useful documentation as to what this does, but error avoided by not re-initialising)
     ble_adv_start();                                   //Begin avertising.

    Q3: Will this, or will this not, force the peripheral to advertise on channel 1, (or whatever i put into the arguement on line 2)?

    This seems to run but i cant get the RSSI viewer to re-program my dev kit, so cant actually prove it's switched channel

    Furthermore, i have since found below function:

    radio_unmodulated_tx_carrier()
    Q4: This however,  locks up the execution? the LED on the product stops flashing, the button becomes unresponsive. Any thoughts as to why this is happening?

    Again, there is seemingly no documentation detailing any prerequisites for this function. & the examples in which it is called have next to no annotation either.

  • Hi Sean,

    SeanHowsonTB said:
    All configurations of the radio registers must either be through the Softdevice API or by using Radio Timeslot API

    Q1: Why? When both the examples you refer to, seemingly do not use the softdevice API? they use functions from the nrf_radio.c file, which seems to directly access the radio registers? Can i not just disable the softdevice, reconfigure the radio, then re-enable the softdevice?

    It shouldn't be used while simultaneously using the Softdevice.

    No, Disabling the Softdevice, re-configuring the radio and then re-enabling the Softevice will have no effect. Upon being re-enabled the Softdevice will re-configure the radio to its initial state.

    SeanHowsonTB said:

    Q2: Should i run radio test functions,with or without the softdevice enabled?

    As i stated in my original post, i am not in a position to use the example code, i need to modify my existing application to feature radio tests (again, this is pre-compliance testing, so informal). Bespoke boards are not well suited to example code: For starters the code is hilariously un-annotated, so i have no idea what it is actually doing on physical layer, this is a terrible position to be in, in an embedded environment. It assumes i have access to hardware such as uart ports (which i dont). Additionally, the examples never build without hours of adjustments, to both SDK & source code.

    So again, i am not looking to be referred to examples, im on this forum because i've reviewed the examples and cant find what i need, i'm looking for simple written explanations (NOT GENERATED BY DOXYGEN!).

    Without. Radio access is blocked while using Softdevice. 

    SeanHowsonTB said:

    Q3: Will this, or will this not, force the peripheral to advertise on channel 1, (or whatever i put into the arguement on line 2)?

    This seems to run but i cant get the RSSI viewer to re-program my dev kit, so cant actually prove it's switched channel

    It will not have an effect. Setting advertising channels should be done through the channel mask. 

    SeanHowsonTB said:
    Q4: This however,  locks up the execution? the LED on the product stops flashing, the button becomes unresponsive. Any thoughts as to why this is happening?

    Have you checked with a debugger if the program has asserted? 

    regards

    Jared 

Reply
  • Hi Sean,

    SeanHowsonTB said:
    All configurations of the radio registers must either be through the Softdevice API or by using Radio Timeslot API

    Q1: Why? When both the examples you refer to, seemingly do not use the softdevice API? they use functions from the nrf_radio.c file, which seems to directly access the radio registers? Can i not just disable the softdevice, reconfigure the radio, then re-enable the softdevice?

    It shouldn't be used while simultaneously using the Softdevice.

    No, Disabling the Softdevice, re-configuring the radio and then re-enabling the Softevice will have no effect. Upon being re-enabled the Softdevice will re-configure the radio to its initial state.

    SeanHowsonTB said:

    Q2: Should i run radio test functions,with or without the softdevice enabled?

    As i stated in my original post, i am not in a position to use the example code, i need to modify my existing application to feature radio tests (again, this is pre-compliance testing, so informal). Bespoke boards are not well suited to example code: For starters the code is hilariously un-annotated, so i have no idea what it is actually doing on physical layer, this is a terrible position to be in, in an embedded environment. It assumes i have access to hardware such as uart ports (which i dont). Additionally, the examples never build without hours of adjustments, to both SDK & source code.

    So again, i am not looking to be referred to examples, im on this forum because i've reviewed the examples and cant find what i need, i'm looking for simple written explanations (NOT GENERATED BY DOXYGEN!).

    Without. Radio access is blocked while using Softdevice. 

    SeanHowsonTB said:

    Q3: Will this, or will this not, force the peripheral to advertise on channel 1, (or whatever i put into the arguement on line 2)?

    This seems to run but i cant get the RSSI viewer to re-program my dev kit, so cant actually prove it's switched channel

    It will not have an effect. Setting advertising channels should be done through the channel mask. 

    SeanHowsonTB said:
    Q4: This however,  locks up the execution? the LED on the product stops flashing, the button becomes unresponsive. Any thoughts as to why this is happening?

    Have you checked with a debugger if the program has asserted? 

    regards

    Jared 

Children
No Data
Related