This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Hi,

 For a number of upcoming projects we require 802.15.4 and BLE dynamic multiprotocol support. We need to select a SoC to implement this.

 We like the look of the nrf52840 and see multiprotocol  should be possible using the nRF-IEEE-802.15.4-radio-driver. 

 A number of people have already asked about this but is there an example showing this working yet? Or if someone has got it working would firstly say they've done it and then, maybe, let us have the code ( or even binary ) please?

 We have just had Silicon Labs pull 802.15.4 support from their modules that we were just about to design in so time is critical for us. We don't have the time to learn an API and get to grips with new hardware/software and the inevitable debugging to get to the point deciding to use the nrf52840. If we can prove multiprotocol works we will almost certainly use the nrf52840.

kind regards

Liam

Parents
  • Hello Liam,

    I don't think we have any examples using the "pure" 802.15.4 driver with BLE, but we have several examples in our Thread and Zigbee SDK using multiprotocol BLE and Thread or ZigBee (which uses the 802.15.4 driver), so yes. It is possible to use the BLE stack (softdevice) together with the softdevice. I know you are not looking for API right now, but we have something called the TimeSlot API, which requests timeslots where you can use the radio as you like, in between the BLE radio events. 

    Thread/ZigBee SDK multiprotocol example:

    ThreadSDK\examples\multiprotocol\ble_thread

    ThreadSDK\examples\multiprotocol\ble_zigbee

    The TimeSlot API is described here. (It is described for SDK11, which is kind of old, but it works on the new SDKs as well, without modifications).

    Best regards,

    Edvin

  • Hi Edvin,

    Thank you for the reply.

     I've had a look at the Thread and Zigbee SDK. It provides a 802.15.4 radio driver module which seems to provide "raw" access to the 802.15.4 radio but not a "proper" 802.15.4 stack. Most comments on 802.15.4 multiprotocol suggest to use this. To me there would appear to be a considerable amount of work to get the radio driver to the point where it would associate with a 802.15.4 coordinator.

    There seems to be a full 802.15.4 stack provided in SDK 15. It also provides Bluetooth. So would it be possible to use the TimeSlot API to request slots from the Bluetooth side and run the 802.15.4 within them?

    regards

    Liam

  • Hello,

    The sys_init function uses the parameters from your IDE settings. I don't know what IDE you use, but in Segger Embedded Studio, it looks like this:

    In Keil it is found under project settings->Target->Read/Write Memory Areas.

    If you look at the project files for BLE vs. non BLE examples, that is, examples using the softdevice or not, there are different settings. The exact settings depends on your BLE application, but take these project settings from one of the BLE examples for the nRF52840, and copy them into your project. If you need to adjust these, it should be printed in the log (NRF_LOG) when the application starts.

    Best regards,

    Edvin

  • Hi Edvin,

    I am using Segger.

    I based my project on the SDK15 ble_template so the IDE settings are as there were originally set in this . As a test I transferred the values from the IEEE15.4 example and it stopped working altogether. Beyond that I do not know what settings to try.

    Can you confirm that multi protocol will actually work. I've found another post

    https://devzone.nordicsemi.com/f/nordic-q-a/36814/nrf52840-multiprotocol-ble-802-15-4-without-zboss/141729#141729

    It says "The 802.15.4 implementation in the regular SDK do not have the dynamic multiprotocol support that the Thread and Zigbee solutions have." 

    Its the regular SDK that I am trying to use.

    kind regards

    Liam

  • Hello Liam,

    You are right. I spoke to Jørgen, who answered the ticket that you linked.

    The 802.15.4 library in the SDK is an external library, which doesn't have API for integration with timeslots. The driver on GitHub is something that we wrote in Nordic, and it is made to support TimeSlot API.

    Another reason that the library in the SDK will not work is that it uses the same peripherals as the softdevice use, TIMER0 and RTC0, so they don't cooperate.

    Worth mentioning:

    The driver on github is also the drivers that are used in the Thread and ZigBee stacks, so it is well tested.

    So you are correct. You can't use the library from the SDK with TimeSlot API. You must use the drivers on GitHub if you want to use it in parallel with BLE.

    Best regards,

    Edvin

  • Hi Edvin,

    Thank you for confirming I can't use the SDK.

    I want to connect to an existing 802.15.4 coordinator using the github driver. Does this mean I have to write a partial MAC layer to do the associating? That is write code to do a beacon request, analyse the beacons and then do the association. I don't have to write a complete MAC stack; just enough to connect to my beaconless coordinators in the modes they use.

     It seems to be that the somewhere in the thread library the association cpde already exists. Is there anyway that it could be leveraged out and exposed?

    kind regards

    Liam

  • Yes. The 802.15.4 IEEE driver is independent of the MAC layer, so you have to write this. 

    You can see if you can reuse anything from the Thread SDK:

    nRF5_SDK_for_Thread_and_Zigbee_2.0.0_29775ac\external\nRF-IEEE-802.15.4-radio-driver\src\mac_features.

    BR,

    Edvin

Reply Children
  • Hi Edwin,

     I'm having a problem getting this to work.

    Firstly I got the single phy IEEE15.4 Radio Driver examples working.

    I then modified the ble_zigbee_dynamic_light_switch_nus by stripping out any zigbee code. 

    I added the Radio Driver source files in. I've setup as described in the Radio Driver Wiki (i.e. RAAL_SOFTDEVICE defined, nrf_raal_softdevice.c added etc ). I used nrf_802154_clock_sdk.c, nrf_802154_lp_timer_nodrv.c. The nrf_802154_config,h files I left as is.

    I call nrf_802154_init after setting up Bluetooth.

        err_code = ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST);
        APP_ERROR_CHECK(err_code);
    
    	/* Initialize loging system and GPIOs. */
        log_init();
        timer_init();
        leds_buttons_init();
      
        /* Bluetooth initialization. */
        ble_stack_init();
        gap_params_init();
        gatt_init();
        services_init();
        advertising_init();
        conn_params_init();
    	
        printf("Initialise 802.15.4 ...");
        nrf_802154_init();
    
        nrf_802154_channel_set(11);
        nrf_802154_receive();
        printf("Done\n");
    	
    	while (1)
    	{
    	    if (!m_tx_in_progress)
    	    {
    			printf("Send ");
    			m_tx_in_progress = nrf_802154_transmit(message, sizeof(message), true);
    			if (!m_tx_in_progress) 
    				printf("Fail\n");
    	    }	
    	}

    My understanding is the nrf_802154_init sets up the arbiter.

    Running shows the bluetooth is working but it only sends a few 802.15.4 packets and then stops. nrf_raal_softdevice_soc_evt_handler is no longer being called.

    Can you help please? I can post the project if required.

    kind regards

    Liam

  • Hello Liam,

    If you could send the project, that would be great. If I can't figure it out, I could send it to someone who has worked with the 802.15.4 radio driver, which will probably know what is going on.

    Best regards,

    Edvin

  • Thanks Edvin,

     I think thats best. Zip of project attached. Output should be placed within SDK as below

    nRF5_SDK_for_Thread_and_Zigbee_2.0.0_29775ac\examples\multiprotocol\ble_802154_dynamic_nus

    kind regards

    Liam

    ble_802154_dynamic_nus.zip

  • Is the nrf_raal_softdevice_soc_evt_handler ever called?

    I seem to recall that I had to register the SOC_OBSERVER separately. IIRC that was not done by the nrf802154_init()

  • You are right. Whilst it was called it was only a couple of times.

    Registering the SOC_OBSERVER in main() fixed it and I am sending IEEE packets. Checking with a scope shows gaps in the stream where the bluetooth is active.

    Might I suggest that the registration is mentioned in the Wiki.

    Thank for your help Edvin and mrono.

Related