1

I have an IoT application that requires me to send 802.15.4 packets without any higher level protocols. We have a small packet specification implemented in native C so all I need is to add a payload to a packet and send it over the radio (there will never be packet splitting). Our current hardware takes very low level control over the radio interface and (partially) implements 802.15.4 for this purpose, but I am trying to showcase the same functionality on a nRF5340DK using Zephyr.

Looking at the the Zephyr docs I only see support for sending over a BSD Socket or using an offload driver to bypass L2 and talk directly to the radio. I'd rather not implement the whole L2 spec if it already exists in the drivers.

Is there any way for my application to have more direct control of the L2 packets?

Dan
  • 176
  • 1
  • 11

1 Answers1

1

Since this question was asked Zephyr has changed a little. Version 3.2.0 decoupled 802.15.4 from the IP stack allowing exactly what I wanted. There's a test showing this functionality on tests/net/ieee802154/l2/src/ieee802154_test.c and I adapted that into an example at https://github.com/dberliner/zephyr_raw_802154 (the test keeps the IP stack involved which isn't desirable here).

The correct answer prior to Zephyr 3.2.0:

The simple answer to this question is "no." The L2 802.15.4 implementation is 6LoWPAN so it's tied to IPv6. A Nordic developer advised me that their Zigbee implementation takes a similar approach to what I would need but I'd need to reinvent the wheel for my purposes https://github.com/nrfconnect/sdk-nrf/blob/main/subsys/zigbee/osif/zb_nrf_transceiver.c

Dan
  • 176
  • 1
  • 11
  • This has saved a bit of a journey for us! Were you able to find any examples that suited you, we need to do a very similar job with just 'native' 802.15.4 – Richard Pike Nov 15 '22 at 17:07
  • @RichardPike I adapted the linked zb_nrf_tranceiver.c into what I needed and it worked well. A lot of it was just copy and pasting and stripping irrelevant paths (my tx only does non-CCA direct for instance). IIRC the biggest deviation was implementing `net_recv_data` instead of using `NET_L2_INIT` and having the function process the packet and always return -1 to drop. I'll see if I can adapt my stuff into something I can open source in the next week if this is a problem other people are having. – Dan Nov 16 '22 at 18:42
  • thank you for replying, that would be really useful to see if possible. I've got to a packet dropped by NET stack message which ends up coming from `net_recv_data` https://devzone.nordicsemi.com/f/nordic-q-a/93898/nrf_802154_use_raw_api-is-always-being-set-to-1 – Richard Pike Nov 18 '22 at 14:07
  • @RichardPike Zephyr 3.2.0 decoupled the IP stack from 802.15.4 and there's a good example in `tests/net/ieee802154/l2/src/ieee802154_test.c` function `test_raw_packet_sending`. Its a major refactor so my example code wouldn't even work with new versions. You still actually have to build the 802.15.4 packet but you can use the network stack properly to send over the radio. I pieced the following together and it's sending as I want https://github.com/dberliner/zephyr_raw_802154 – Dan Nov 24 '22 at 21:09
  • @Dan I've been playing around with the `test_raw_packet_sending` and seem to get it to work. But I'm having trouble with receiving packets. Did you get that to work? – Nabeel Feb 23 '23 at 22:51