• State Not Answered
  • Replies 7 replies
  • Subscribers 75 subscribers
  • Views 1558 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 282308
Options

NRF52840 802.15.4 CCA question

Libertas

I would appreciate your feedback on the 802.15.4 CCA implementation on NRF52840.

1. Is it possible to perform CCA without disrupting the RF reception?

2. If it is possible, I need to invoke NRF_RADIO_TASK_CCASTART on "RX" state. I assume I can use NRF_RADIO_SHORT_CCAIDLE_STOP_MASK to transition from RX to RXIDLE.

But can I combine NRF_RADIO_SHORT_CCAIDLE_TXEN_MASK to automatically transition from RX_IDLE to TX_IDLE?

3. I know I can instead handle CCAIDLE  from IRQ handler but I am wondering if it can be more automated?

Thanks

Q

Parents
  • 0

    Hello Charlie,

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

    1. Initially, it will support Nordic NRF52840 and TI CC2538.

    2. 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.
    3. Hornet keeps many constructs from Zigbee, as long as they work, while fixing all known design flaws of Zigbee.
    4. 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.
    5. 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.

    6. 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.

    7. 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.
    8. 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.
    9. X25519 based key exchange is used during device join.
    10. 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.

Reply
  • 0

    Hello Charlie,

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

    1. Initially, it will support Nordic NRF52840 and TI CC2538.

    2. 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.
    3. Hornet keeps many constructs from Zigbee, as long as they work, while fixing all known design flaws of Zigbee.
    4. 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.
    5. 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.

    6. 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.

    7. 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.
    8. 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.
    9. X25519 based key exchange is used during device join.
    10. 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.

Children
No Data
Related
Terms of service