IEEE 802.15.4 API SDK 17.00

[Elia_pell]

Dear all,

I'm currently implementing the 802.15.4 stack using the precompiled library inside SDK 17.00. I'm trying to send data every tot (10/20/30) ms. What I currently found is that if the time is too small (less than 15 ms), the entire application go in fatal error here:

Is this normal? Is this limitation due to the implementation of the entire stack? Could I manage to increase the throughput using the nrf-IEEE-802.15.4 radio driver inside SDK for Thread and Zigbee or the behaviour will be pretty the same?

Thanks to everyone,

Elia

[Edvin]

Hello Elia,

Based on your screenshot it doesn't look like DEBUG is defined in your preprocessor definitions. Can you try to add it, and see where this app_error is coming from?

Perhaps the timeout is too short compared to the prescaler.

That being said, 802.15.4 is not built for throughput. The driver will listen for activity on the given channel. If it detects activity right before it will start to transmit, it can't interrupt it, so it is not necessarily better to use the drivers from the T&Z SDK. But look into where your error is coming from. Perhaps it is not related to the radio driver at all.

Best regards,

Edvin

[Elia_pell]

Hi Edvin,

I add the DEBUG preprocessor definition and what I manage to obtain is this:

As you can see from the picture, the routine (timer_acquisition_event_handler) in which I call mcps_data_req is correctly called only 6 time: it is like I can't be able to push in the queue more than 2 packet. Moreover the packet (5) is correctly sent (I used the iEEE802.15.4 Sniffer), but in that case the mcps_data_conf primitive in which I print "Packet correctly sent" it is not called. This behaviour is pretty randomic, but no more than 100 connections ever happen (before the fatal error).

Any suggestion? Is there a way to control is the queue is empty?

[Edvin]

Where is "packet correctly send" being printed?

I would say that either way, you should wait for the previous packet to be successfully sent before you send the next packet. If the previous packet was not sent correctly, or if you get an error, try sending it again after a while. 

I don't know if I would recommend this radio driver for something commercial. The Thread and Zigbee 802154 driver is more thoroughly tested, and also maintained more properly. It is at least worth looking into. 

Best regards,

Edvin

[Elia_pell]

Dear Edvin,

I follow your advise and I found that delay between tx and rx with IEEE 802.15.4 MAC library from SDK 17.00 is not exceptional for this use. So I will dive into the IEEE 802.15.4 radio driver. Any advise on how I can create a SES project from zero?

Elia

[Edvin]

A SES project for your application, or project for the radio driver?

I assume you mean for your application.

If you intend to use the radio drivers, I think you can just start with that example. The alternative is to start with the example:

SDK\examples\peripheral\template_project, and then add the radio drivers. If you intend to use the softdevice as well (for Bluetooth low energy), then you should start with SDK\examples\ble_peripheral\ble_app_template

Do not attempt to create a project from scratch. It is probably possible, but a lot of unnecessary work. I have never tried myself, and I never will try creating a SES project from scratch.

Best regards,

Edvin