The fix was surgical: rewrite the GetStationList() shim to cache station data. A separate thread would refresh the cache every 500ms via nl80211 async dumps. The HAL call would simply copy from the cache – a 100µs operation. By day 25, the system was stable. The TR-181 parameters synchronized. The web UI showed "Qualcomm Wi-Fi 6E" instead of "Broadcom." Even Axiom's proprietary cloud analytics (via TR-069) accepted the chip's RSSI values.
At the RDK Summit that year, Mira presented a session titled "Bridging the Gap: Non-Native Wi-Fi SoC Integration with RDK-B." The room was packed. Engineers from Juniper, Nokia, and CommScope took notes. rdk-b integration with non-native wi-fi socs
Mira made a call: rewrite the steering logic. She stripped out the Broadcom-specific calls and replaced them with a generic nl80211 RRM interface. For two weeks, she lived inside the 802.11 spec, implementing neighbor reports and BTM requests from scratch. On day eighteen, the gateway booted. Both radios (2.4 GHz and 5 GHz) came up. Clients associated. But after 45 minutes, the Wi-Fi would lock up. No ping, no probe responses. The QCA SoC was alive (LED blinking), but RDK-B had lost its mind. The fix was surgical: rewrite the GetStationList() shim
The lab in Cupertino hummed with a familiar tension. On the bench lay two pieces of silicon that were never meant to talk to each other. One was the brain: a Broadcom BCM3390 system-on-chip (SoC), the native heart of the RDK-B stack. The other was a rebel: a Qualcomm QCA6391 Wi-Fi 6E SoC, plucked from a high-end laptop reference design. The mission, given by a Tier-1 operator named "Axiom Broadband," was simple in ask but monstrous in complexity: integrate the alien Wi-Fi chip into the RDK-B gateway as the sole access point. By day 25, the system was stable