NRF52840 802.15.4 CCA question

RE: NRF52840 802.15.4 CCA question

Charlie — Mon, 01 Aug 2022 14:03:09 GMT

Thanks for your updates!

Best regards,

Charlie

RE: NRF52840 802.15.4 CCA question

Libertas — Sun, 31 Jul 2022 14:03:35 GMT

Here are some updates. I did trigger NRF_RADIO_TASK_CCASTART while in RX state. And it seems to work very well. I know that because if I lower the threshold I got CCA busy while I can still receive packets.

Also looking at NRF52840 product specification there is no mention of any potential conflict between CCA and RX.

RE: NRF52840 802.15.4 CCA question

Libertas — Wed, 12 Jan 2022 02:20:28 GMT

Hello Charlie,

Thanks for your compliment. Below are the key features of Hornet Mesh Network (Hub Orchestrated Routing Network).

Initially, it will support Nordic NRF52840 and TI CC2538.
Currently based on 802.15.4 radio. However, as a solid mesh framework, it can be extended to other radio technologies, such as BLE radio and Lora radio, etc.
Hornet keeps many constructs from Zigbee, as long as they work, while fixing all known design flaws of Zigbee.
Hornet defines the same APS layer as Zigbee, with mandatory binding requirements with end-to-end encryption. Each pair of bound devices must share a unique secret link key.
Dynamic router and end-device roles switching, like Thread. It helps to dynamically optimize the network. Unlike Thread, Hornet doesn’t have the limitation of a maximum of 32 routers.
Hornet uses a routing table. Unlike Zigbee, Hornet uses “parent routing”. Each node tracks the parent of every bound device (none if it’s a router). Route discovery mechanism returns parent in the route-reply message. The “source route” field in the NWK header is used to carry parent addresses (at most two entries if both src and dest are child nodes). As a result, the routeing table only contains routers, which is extremely efficient.
Hornet end-device shall be completely radio silent as long as it is not the unicast destination and the parent can be heard periodically, which is different than Thread.
Once joined, the unique 16-bit network address of a node never changes, which is assigned by Hub. It makes binding and routing and management much easier.
X25519 based key exchange is used during device join.
Standard APS API that deals with APS commands and attributes changes among bound device endpoints. In the future, device manufacturers will not need to write any code for more and more generic devices.

We all know Zigbee has phased itself out after 15 years, while BLE and Thread are organized in exactly the same way as Zigbee.

I believe in an Open network stack that is community-driven and inspires open discussion. Also, accessing through IP has never been a problem for IoT. But IoT nodes shall be properly access-controlled and heavily cached with policies dictated by end-users, instead of being directly exposed to the internet.

Also, Hornet is designed to integrate the Lbertas VM with IoT Application engine.

I will talk about the Hornet OS tomorrow.

RE: NRF52840 802.15.4 CCA question

Charlie — Tue, 11 Jan 2022 09:04:48 GMT

Hi Qingjun,

It is very exciting to learn about your project from the slides and website. Thanks for adding support for Nordic MCUs on your platform. TypeScript will definitely make embedded development much easier, really looking forward to seeing the release of your open-source project. It is totally OK if you want to share more information on this Devzone board. We have many active developers who may be interested in your solutions.

Best regards,

Charlie

RE: NRF52840 802.15.4 CCA question

Libertas — Tue, 11 Jan 2022 02:11:03 GMT

Hello Charlie,

Thank you for pointing out nrf_802154_core.c file. I am reading it now.

Yes, you are right. I have been working on our own mesh protocol, which we plan to open-source soon.

It is named Hornet (Hub Orchestrated Routing Network) Mesh. We already have a solid implementation on TI CC2538. I am porting it to Nordic NRF52840 now.

I am managing a huge project, including two brand new operating systems. Mesh network stack is not our core business, nevertheless, I believe we shall make contributions.

Eventually, everybody will be able to write IoT apps in TypeScript that end-users can deploy to IoT devices, including the MCUs, and execute in a way that is both CPU safe and memory safe by design.

Below is the system overview. Hornet Mesh is a small part of it. Nordic MCUs will be supported.

docs.google.com/.../edit

I can share some details on this board if it is OK to do so.

RE: NRF52840 802.15.4 CCA question

Libertas — Tue, 11 Jan 2022 02:10:42 GMT

Hello Charlie,

Thank you for pointing out nrf_802154_core.c file. I am reading it now.

Yes, you are right. I have been working on our own mesh protocol, which we plan to open-source soon.

It is named Hornet (Hub Orchestrated Routing Network) Mesh. We already have a solid implementation on TI CC2538. I am porting it to Nordic NRF52840 now.

I am managing a huge project, including two brand new operating systems. Mesh network stack is not our core business, nevertheless, I believe we shall make contributions.

Eventually, everybody will be able to write IoT apps in TypeScript that end-users can deploy to IoT devices, including the MCUs, and execute in a way that is both CPU safe and memory safe by design.

Below is the system overview. Hornet Mesh is a small part of it. Nordic MCUs will be supported.

docs.google.com/.../edit

I can share some details on this board if it is OK to do so.

RE: NRF52840 802.15.4 CCA question

Charlie — Mon, 10 Jan 2022 12:49:39 GMT

Hi Qinggjun,

IEEE802.15.4 CCA and RX are competitive operations for radio peripheral resources, you can find clues from NCS modules\hal\nordic\drivers\nrf_802154\driver\src\nrf_802154_core.c source codes. nRF5 SDK should have similar files.

I am curious if you are making your own IEEE802.15.4 based customized protocol? Generally, you should avoid maintaining your own protocol unless the existing Thread, Zigbee, or RF4CE, and so on cannot satisfy your needs totally, because it will take huge efforts and resources. Could you share more information about your application so we may be able to provide more help on it?

I also want to remind you that nRF5 SDK-based solution is only under the maintenance stage now and you should move forward to NCS for your new project as soon as possible. Please see the blog nRF Connect SDK and nRF5 SDK statement to learn more details.

Best regards,

Charlie