NiusZigbee 0.12.0 - CC2530 v0.7 MAC-level ACK + retransmit

With v0.6's CSMA-CA, the SDCC transceiver firmware now implements both halves
of TI's MAC channel-access and reliability.

CC2530 firmware v0.7

• MAC-level ACK + retransmit. When a unicast frame requests an acknowledgement
  (FCF.AR), the firmware waits for the matching ACK (same DSN, CRC-valid) and, if it
  does not arrive, retransmits the whole frame (re-running CSMA-CA) up to
  macMaxFrameRetries (3) - like the official Z-Stack MAC. A lost unicast can now
  recover at the MAC instead of relying on the slower host APS retransmit, and
  TXSTAT reports the acked result.
• No dropped RX while waiting: a frame received during the ACK window that is
  not our ACK is forwarded to the host as a normal RX_FRAME.
• Only ack-requested frames are affected; broadcasts keep prior behavior.

Verification status (honest)

• Builds with SDCC 4.5 (FW_VER 0.7).
• On-air checked: a v0.7 node joins a coordinator and exchanges traffic cleanly
  (mic=0 rpl=0), so the ACK-wait and forward-non-ACK paths run without breaking
  the link.
• The retransmit-on-loss branch is implemented and build-verified but not yet
  triggered under a forced loss; a forced-loss measurement and a multi-hop
  delivery/congestion comparison vs v0.5 and ZNP are the next quantitative steps.

Reflash the CC2530 with examples/CC2530_FlashFirmware after updating.

NiusZigbee 0.11.0 - CC2530 v0.6 unslotted CSMA-CA

Closes a real on-air gap of the SDCC transceiver versus TI's MAC: the CC2530
firmware now does IEEE 802.15.4 unslotted CSMA-CA on the transmit path.

CC2530 firmware v0.6

• On a busy channel, radio_tx waits a random exponential backoff (BE 3..5,
  up to the standard backoff count) and retries with a widening window, instead of
  v0.5's immediate retry-on-busy. This spreads contending transmitters rather than
  colliding - the channel-access discipline ZNP/TI's MAC uses.
• Built on the proven radio_tx_once() (hardware STXONCCA) plus a software
  xorshift PRNG seeded per node from the IEEE address - no radio-register reads
  in the TX path. Non-CCA TX keeps the legacy behavior.
• On-air verified: a v0.6 CC2530 scans, transmits, receives, and joins a
  coordinator. Builds with SDCC 4.5; cc2530_radio_fw.h regenerated (+ a
  genhdr.py helper).

The host-side stack, the ZNP backend, and the SDCC default backend are unchanged.
A full multi-hop delivery/congestion comparison vs v0.5 and a ZNP node is the next
quantitative step toward measurably surpassing the official firmware.

Reflash the CC2530 with examples/CC2530_FlashFirmware after updating.

NiusZigbee 0.10.0 - CC2530 Z-Stack ZNP backend (hardware-verified)

Adds and hardware-verifies the second module backend: drive a CC2530 running TI
Z-Stack ZNP over the Monitor-and-Test (MT) API, alongside the default native
host stack on the raw-802.15.4 SDCC firmware.

Highlights

• CC2530ZnpRadio host driver (src/modules/cc2530znp/): MT transport
  (SOF/LEN/CMD0/CMD1/DATA/FCS, SREQ->SRSP + AREQ indications), reset/ping/version,
  device info, NV config, ZDO startup, AF endpoint register + data request,
  permit-join, and dispatch of AF incoming + ZDO state-change + AF data-confirm.
• Verified on real Z-Stack 2.7.2 (board1): SYS_PING capabilities 0x0779,
  SYS_VERSION = Z-Stack 2.7.2. Framing also covered by the CC2530Znp_Mt
  self-test; bring-up by CC2530Znp_Info.
• Docs for obtaining TI's prebuilt image, the required CFG strapping
  (P2.0/P0.4 -> GND for UART + flow control), the serial-bootloader startup
  window, and flashing via the built-in CCDebugger.

The native SDCC backend remains the default. The TI ZNP firmware image is TI's
and is obtained from the TI Z-Stack package (not redistributed here).

NiusZigbee 0.9.0 - 100% multi-hop reliability + Phase 2 integration

Reliability + integration release on top of 0.8.0's feature completion. All changes
bench-verified on the 4-board, 3-hop NWK-secured line (board1 J-Link + three DFU
boards). See docs/VERIFIED_BEHAVIOR.md for the raw status lines.

Reliability: 100% multi-hop delivery

• Two-tier end-device route repair. On an APS stall the end device now
  re-discovers the route (paced AODV RREQ) while keeping its short address and
  outgoing frame counter stable, and only falls back to a full re-scan/re-join
  after a persistent stall. The previous re-scan-on-stall reset the frame counter,
  which the coordinator replay-rejected - a churn storm that turned a transient
  stall permanent. A clean line now reaches aps[q=30 ok=30 drop=0] = 100% with
  ~0.6 retransmits/frame (was ~4.3) and no replay storm.

Phase 2: integration on air

• APS fragmentation works end to end over multi-hop. A 120 B ASDU is
  fragmented into blocks, routed over three hops, and reassembled by the
  coordinator (-DNIUS_ZIGBEE_FRAGTEST=1). Fixes a real bug: the APS extended-
  header FCF bit was 0x08 (collides with the delivery-mode field) so fragments
  were spec-non-compliant, and ZigbeeAps::parseDataFrame rejected ext-header
  frames outright - fragmentation could never be received on air. The bit is now
  0x80 and the parser accepts ext-header unicast data (exposes firstBlock/blockNumber).
• Binding-driven indirect transmit. The end device installs a source binding
  and sends a ZCL Toggle resolved through ZigbeeBindingTable (bind-then-control),
  toggling the coordinator's LED across the mesh (-DNIUS_ZIGBEE_BINDTEST=1).
• Broadcast transaction table reassessed: redundant on this stack because NWK
  security's replay check already drops duplicate rebroadcasts at every relay.

Notes

• For a clean multi-hop bring-up build with -DNIUS_ZIGBEE_IGNORE_SAVED=1.
• No CC2530 firmware change in this release (still v0.5).

NiusZigbee 0.8.0 - Zigbee PRO feature completion

This release completes the remaining partially-done features of the host-side
Zigbee 3.0 stack, bringing the Zigbee PRO surface to feature-complete. All 46
example sketches compile clean against the ArduinoNRF nRF52840 core; each new
piece ships an expanded single-board self-test.

Highlights

• Green Power proxy + GP cluster (0x0021). ZigbeeGpProxy tunnels an
  overheard battery-less device into the mesh; ZigbeeGreenPowerCluster
  build/parses GP Notification / Commissioning Notification / Pairing and
  commissions + decrypts at the sink.
• Per-joiner secure join via install codes. ZigbeeTcLinkKeyStore derives a
  unique link key per joiner IEEE and wraps the Transport-Key under it. Also
  fixes a real interop bug: install-code CRC is now stored little-endian per
  spec (verified against the canonical reference vector
  83FED3...C3B5 -> 66B6900981E1EE3CA4206B6B861C02BB).
• Touchlink / Green Power over real inter-PAN MAC frames.
  ZigbeeMac::buildInterPanFrame/parseInterPanFrame + CC2530Radio::sendInterPan()
  (extended source addressing, broadcast/unicast).
• Key rotation hardening. NWK-security replay identity is now
  (source IEEE, key sequence), so a freshly rotated key resyncs instead of the
  post-rekey replay churn.
• PAN-ID conflict + channel-change manager. ZigbeeNetworkManager detects a
  conflict from heard beacons, selects a fresh PAN ID, and applies EPID-scoped,
  freshness-checked PAN-ID/channel updates.
• Sleepy-device frame-pending bit (CC2530 firmware v0.5). New SET_PENDING
  command drives FRMCTRL1.PENDING_OR; CC2530Radio::setFramePending() wires it
  to the indirect queue. Opt-in; non-sleepy behavior unchanged.

Verification status

Compile-verified (all 46 examples) and exercised by single-board self-tests.
The new over-the-air paths (touchlink/GP inter-PAN exchange, install-code
join, key-rotation switch, beacon-driven PAN-ID/channel change, and the sleepy
frame-pending auto-ACK) are pending multi-board bench verification. The CC2530
v0.5 firmware is SDCC build-verified; reflash modules with CC2530_FlashFirmware
to use the frame-pending feature.

See docs/STACK_ROADMAP.md for per-item status.

NiusZigbee 0.7.7

Docs: the README now reflects the full Zigbee 3.0 stack and the verified multi-board topologies (3-hop line at 100% delivery, self-healing 2x2 mesh, mesh + Green Power, source-route OTA), plus nice!nano (S140) board support. No code changes.

Install via Arduino Library Manager as NiusZigbee.

NiusZigbee 0.7.6

Multi-hop reliability: 3-hop line now 100% APS delivery (was ~87%).

• APS end-to-end retransmits 3->8, MAC retries/hop 3->5, and the periodic Mgmt_Lqi mapping query is skipped on the multi-hop test topologies (it added contention without surviving the extra hops).
• HW-verified on the 4-board 3-hop line (incl. a nice!nano): 15/15 delivered, drop=0 (was ~7/8).

Install via Arduino Library Manager as NiusZigbee.

NiusZigbee 0.7.5

Source-route OTA — concentrator origination, verified end to end.

• The end device sends an NWK Route Record up to the coordinator (each relay appends itself); the coordinator learns the full path, reverses it, and originates a source-routed data frame back down; the relays forward it by the subframe's relay list and the destination delivers it.
• HW-verified on the 4-board 3-hop line (incl. a nice!nano): ROUTE RECORD ... path A->dst: 0x0001 0x0031 -> SRCROUTE tx -> relays -> SRCROUTE delivered from 0x0000 "SR-ping".

This completes the four requested multi-board verifications: 3-hop line (0.7.2), 2x2 mesh + route repair (0.7.3), mesh + Green Power (0.7.4), and source-route OTA (0.7.5). Install via Arduino Library Manager as NiusZigbee.

NiusZigbee 0.7.4

Mesh + Green Power coexisting — verified on 5 boards.

• -DNIUS_ZIGBEE_GP_SINK=1: the coordinator also acts as a Green Power sink - it commissions a battery-less GPD and toggles its LED on each secured Green Power frame, while running the mesh on the same radio/channel. Non-GP frames fall through to the mesh callbacks.
• CC2530_GreenPowerLink -DGP_CHANNEL lets the GPD ride the mesh channel.
• HW-verified: coordinator A ran the 4-node mesh (D's APS/Device_annce/Mgmt_Lqi over its route-repaired path) AND sank a 5th board's GPD toggles (LED alternating, counter advancing, zero decrypt failures).

This completes the three requested multi-board topologies: 3-hop line (0.7.2), 2x2 mesh + route repair (0.7.3), mesh + Green Power (0.7.4). Install via Arduino Library Manager as NiusZigbee.

NiusZigbee 0.7.3

2x2 mesh topology + end-device route repair — self-healing verified on 4 boards.

• -DNIUS_ZIGBEE_MESH_TOPO=1: A coordinator + B,C redundant routers + D end device (reuses the depth-filter join from the line topology).
• End-device route repair: an end device that stops getting APS deliveries through to the coordinator drops its parent and re-scans for a new one - previously only routers detected parent loss.
• HW-verified on 4 boards: D joined B; silencing B made D self-heal onto C (address moved from B's pool to C's pool) with APS delivery resuming, C now relaying (fwd=56).

Install via Arduino Library Manager as NiusZigbee.