chsh-sk-ncs-nrf70-fw-stats-parser

Parses nRF70 firmware stats binary blobs to diagnose Wi-Fi disconnects and RPU lockups.

1|Updated Jan 30, 2026
One-click install
npx skills add https://github.com/chshzh/claude --skill chsh-sk-ncs-nrf70-fw-stats-parser-chshzh
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: chsh-sk-ncs-nrf70-fw-stats-parser
Source: https://github.com/chshzh/claude/tree/main/skills/chsh-sk-ncs-nrf70-fw-stats-parser
Command: npx skills add https://github.com/chshzh/claude --skill chsh-sk-ncs-nrf70-fw-stats-parser-chshzh

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Diagnosing Wi-Fi disconnects on nRF7002 devices is hard because supplicant logs lack device-side ground truth. This Skill parses the rpu_sys_fw_stats binary blob to expose PHY, LMAC, and UMAC counters that reveal the real cause of disconnects. ## Core Features & Use Cases - Binary blob parsing: Runs the nrf70_fw_stats_parser.py script against the correct host_rpu_sys_if.h header to decode little-endian packed firmware stats. - Disconnect diagnosis: Interprets key counters like rssi_avg, OFDM/DSSS CRC fail rates, tx_timeout, and rpu_hw_lockup_count to distinguish congestion, weak signal, and radio lockups. - Reason code mapping: Maps IEEE 802.11 reason codes (6, 34, 1) to device-side evidence and determines whether the AP or the device initiated the disconnect. - Use Case: A customer reports repeated reason-34 low-ACK disconnects on an nRF7002DK. Parse the captured stats blob, find rssi_avg of -48 dBm ruling out range, 10.7% OFDM CRC failures indicating congestion, and rpu_hw_lockup_count of 1 confirming a radio stall. ## Quick Start Ask the AI to parse the attached nRF70 firmware stats .bin file and diagnose why the device keeps disconnecting from the AP.

Frequently Asked Questions about chsh-sk-ncs-nrf70-fw-stats-parser

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I parse an nRF70 firmware stats binary blob?

Run the nrf70_fw_stats_parser.py script with the host_rpu_sys_if.h header from the nrf_wifi module and the .bin blob as arguments. The parser reads struct layouts from the header, so the header must match the firmware that produced the blob.

How to diagnose Wi-Fi disconnect reason 34 on nRF7002?

Reason 34 (DISASSOC_LOW_ACK) means the AP got no ACKs and kicked the station. Check rssi_avg to rule out weak signal, OFDM CRC fail percentage and tx_timeout for congestion, and rpu_hw_lockup_count for radio stalls.

Which header file should I use for nRF70 stats parsing?

Use host_rpu_sys_if.h from the nrf_wifi module path in your NCS installation matching the running firmware. Do not use the nrf71 driver header, since it is a different chip with different struct offsets and produces silently wrong values.

Why are the UMAC control path stats values wrong in the parser output?

The control-path section (cmd_* and event_* counters) has incorrect struct alignment in the parser, producing garbage values like huge cmd_set_wiphy counts. PHY, LMAC, and UMAC TX/RX sections parse correctly; ignore the control-path block.

Can a single stats blob prove what caused a past disconnect?

No, counters are cumulative since the last boot or RPU reset, not per-event. A post-hoc blob is only consistent with a cause, not proof. Capture stats again right after the next event and diff the counters that moved.