nrf52840 Bluetooth and 802.15.4 multiprotocol example project

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

lee yong jun — Wed, 24 Jul 2019 06:49:49 GMT

hello liam

do you finish your 802.15.4 multiprotocol project?

also, i am developing ble and 802.15.4 with Zboss.

can you give me your status ?

thanks a lot

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

jan154 — Thu, 14 Mar 2019 11:48:16 GMT

Hi Liam,

for my diploma I am working on pretty much the same topic. Would it be possible to share the final version of your ble_802154 project for usage as a kind of template? That would help me a lot.

Thanks in advance and best regards, Jan

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Liam — Wed, 31 Oct 2018 14:16:44 GMT

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.

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

mrono — Wed, 31 Oct 2018 13:02:28 GMT

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()

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Liam — Wed, 31 Oct 2018 12:03:02 GMT

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

devzone.nordicsemi.com/.../ble_5F00_802154_5F00_dynamic_5F00_nus.zip

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Edvin — Wed, 31 Oct 2018 11:53:08 GMT

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

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Liam — Wed, 31 Oct 2018 11:11:15 GMT

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

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Edvin — Thu, 18 Oct 2018 13:11:05 GMT

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

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Liam — Thu, 18 Oct 2018 08:45:22 GMT

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

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Edvin — Thu, 18 Oct 2018 07:50:02 GMT

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

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Liam — Wed, 17 Oct 2018 15:23:19 GMT

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

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Edvin — Wed, 17 Oct 2018 14:17:35 GMT

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

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Liam — Wed, 17 Oct 2018 13:25:22 GMT

I've had a go at getting this working today.

Starting with my timeslots BLE template, I have combined it with my 802.15.4 example. I have compiled it and have got it to run.

When I call sys_init (of system abstraction layer in the 802.15.4) I get an error:

<error> app: SOFTDEVICE: INVALID ADDRESS MEMORY ACCESS

The reported address is 0x2000.

Any ideas? I have not really got past initialisation. Do I have to use the system abstraction layer to use 802.15.4?

kind regards

Liam

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Edvin — Mon, 15 Oct 2018 12:15:36 GMT

That is correct. From NRF_RADIO_CALLBACK_SIGNAL_TYPE_START you have control of the radio, and NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 is the callback called before the BLE event, and this is where you should gracefully shut down what you are doing in order to pass the radio over to the SoftDevice.

"Do I need to worry about the state of the IEEE stack between timeslots"?

This depends on how it is set up. I haven't looked too much into the 802.15.4 stack. By the look of the SDK15.2.0\examples\802.15.4\wireless_uart example, it looks like the state of this would be saved, and doesn't need to be set up at every timeslot. I guess you will find out quite fast whether or not it is saved between the timeslots.

You can initialize the IEEE at any time, but when you require the radio, it must either be in a timeslot, or before you use the softdevice.

Best regards,

Edvin

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Liam — Fri, 12 Oct 2018 13:16:35 GMT

Hi Edvin,

I've done a bit of work on this now.

I have converted our existing code to use the 802.15.4 Stack API present in SDK15.2. Apart from a problem with seeing a coordinator beacon payload this now works as a endpoint and connects to our existing 802.15.4 coordinator.

Secondly, using the BLE template from SDK15.2 I have implemented the timeslot API. I think this is working. A LED on the DK is being switched on and off by cases NRF_RADIO_CALLBACK_SIGNAL_TYPE_START and NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 in nrf_radio_signal_callback_return_param_t.

So I now want to merge the two. So could you confirm that on NRF_RADIO_CALLBACK_SIGNAL_TYPE_START I should start calling the IEEE 15.4 handler and stop on NRF_RADIO_CALLBACK_SIGNAL_TYPE_TIMER0 .

Do I need to worry about the state of the IEEE stack between timeslots i.e. is it preserved? Do I have to restore the radio state (channel, power etc) at any point or does the timeslot API take care of it?

When should I initialise the IEEE stack?

Sorry for all the questions; I just want to make sure I'm taking the right approach.

kind regards

Liam

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Edvin — Tue, 09 Oct 2018 07:43:10 GMT

Hello Liam,

Yes indeed. That is in fact the method that is used in our multiprotocol examples (where BLE is one of the protocols). The reason for this is that the BLE stack is a very time sensitive protocol, and hence, it will get 1st priority, and the other protocols will run in the timeslots in between. Unfortunately, we don't have an example doing exactly this already, but the TimeSlot API should be quite easy to use, so you should be able to do what you request.

Best regards,

Edvin

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Liam — Mon, 08 Oct 2018 18:58:40 GMT

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

RE: nrf52840 Bluetooth and 802.15.4 multiprotocol example project

Edvin — Thu, 04 Oct 2018 14:48:55 GMT

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