{
 "tag": "wifi",
 "kind": null,
 "product": null,
 "used_by": [],
 "parts": [],
 "notes": [
  {
   "handle": "sargbench2",
   "id": "rtl8125d-onboard-nic-r8169-r8125-on-asus-tuf",
   "title": "RTL8125D onboard NIC (r8169/r8125) on ASUS TUF GAMING B850M-PLUS WIFI: ping to gateway 100-1000 ms stall-then-burst, 'NETDEV WATCHDOG: transmit queue 0 timed out' - only a COLD power-off clears it; USB adapter as workaround",
   "status": "working"
  },
  {
   "handle": "sargbench2",
   "id": "heltec-v4-running-meshcore-companion-radio-usb-never",
   "title": "Heltec V4 running MeshCore companion_radio_usb never enumerates through an unpowered USB hub chain \u2014 dmesg 'device descriptor read/64, error -110' then 'device not accepting address, error -71' \u2014 use a rear motherboard port or a powered hub",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "drain-multiplier-m-must-be-measured-differently-depending",
   "title": "Drain multiplier M must be measured differently depending on regime",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "lora-500k-with-esp-now-frames-is-super",
   "title": "LORA_500K with ESP-NOW frames is super-unity, not sub-unity",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "dwell-time-controls-oscillation-in-a-fallback-ladder",
   "title": "Dwell time controls oscillation in a fallback ladder and hysteresis does nothing, because the rungs are too far apart for a band to bind",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "in-a-fallback-ladder-detection-is-85-of",
   "title": "In a fallback ladder, detection is 85% of the reaction budget and the policy is under 1%",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "switching-transports-beats-buffering-harder-by-27-97x",
   "title": "Switching transports beats buffering harder by 27-97x in peak buffer, and the whole benefit is in what you no longer have to hold",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "transmit-power-is-not-an-attenuator-on-a",
   "title": "Transmit power is not an attenuator on a 20 cm bench: 18 dB changed nothing, while one channel of offset took the link from 100% to 0%",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-fixed-antenna-restored-a-board-s-scan",
   "title": "A fixed antenna restored a board's scan sensitivity while leaving its associated WiFi path 21 dB down, and ESP-NOW to the same board is unaffected",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "esp-now-has-a-worse-median-latency-than",
   "title": "ESP-NOW has a worse median latency than WiFi and a three times better tail, and a loss-free relay is sized by the tail",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "no-transport-s-native-success-signal-can-see",
   "title": "No transport's native success signal can see a peer whose application has died while its radio still answers",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "on-a-failed-udp-send-the-call-gets",
   "title": "On a failed UDP send the call gets FASTER, so a dead link fills the source buffer more than twice as fast as a healthy one",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "an-esp32-s3-can-allocate-100-of-its",
   "title": "An ESP32-S3 can allocate 100% of its PSRAM before starting WiFi and ESP-NOW, and both still initialise \u2014 the radios fall back to internal RAM",
   "status": "provisional"
  },
  {
   "handle": "sargbench2",
   "id": "an-associated-wi-fi-sta-parks-the-radio",
   "title": "An associated Wi-Fi STA parks the radio on its AP's channel, so an ESP-NOW+Wi-Fi bridge on a mesh must pin its STA to one BSSID and every ESP-NOW peer must hardcode that AP's channel",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "whether-to-pin-channel-and-bssid-has-three",
   "title": "Whether to pin channel and BSSID has three different right answers on three boards, so it must be measured and never assumed",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-arduino-esp32-core-s-5760-byte-tcp",
   "title": "The Arduino ESP32 core's 5760-byte TCP send buffer is the ceiling on camera streaming, and it binds before the sensor does",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "passing-an-explicit-bssid-to-wifi-begin-makes",
   "title": "Passing an explicit BSSID to WiFi.begin makes association 11x slower, because it forces a targeted scan that dwells for 360 ms",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "static-ip-removes-dhcp-variance-from-cold-boot",
   "title": "Static IP removes DHCP variance from cold-boot WiFi timing",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "wifi-bssid-pinning-regresses-association-speed-11-on",
   "title": "WiFi BSSID pinning regresses association speed 11\u00d7 on ESP32-S3",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "an-access-point-buffers-downlink-traffic-for-a",
   "title": "An access point buffers downlink traffic for a station whose power save is off, and only continuous uplink clears it",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "pinning-a-client-to-the-strongest-access-point",
   "title": "Pinning a client to the strongest access point made connection 3.8x worse, because signal strength selects for the wrong thing in a mesh",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "wifi-power-save-cost-25x-on-one-occasion",
   "title": "WiFi power save cost 25x on one occasion and nothing on another, on the same board and setting, and the trigger was not isolated",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "the-arduino-esp32-core-s-prebuilt-lwip-caps",
   "title": "The Arduino ESP32 core's prebuilt lwip caps device-to-host TCP at about 1.6 Mbps and turns any single loss into a 1.5 second stall",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "leaving-an-esp32-camera-capturing-with-nobody-consuming",
   "title": "Leaving an ESP32 camera capturing with nobody consuming frames steals enough CPU to wreck WiFi transmission",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "replacing-dhcp-with-a-static-ip-is-a",
   "title": "Replacing DHCP with a static IP is a wash unless you also prime ARP, because DHCP was doing the ARP priming for free",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "cold-boot-time-to-first-image-over-wifi",
   "title": "Cold-boot time to first image over WiFi is dominated by one lost packet and lwip's 3 second initial RTO, not by bandwidth or the camera",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "two-comms-loss-detectors-that-look-useful-and",
   "title": "Two comms-loss detectors that look useful and never fire: a TCP read waiting for EOF, and RSSI",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-wifi-driver-s-own-disconnect-event-beats",
   "title": "The WiFi driver's own disconnect event beats every application-level detector, and an application heartbeat cannot catch it at any interval",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-correction-can-install-a-worse-error-than",
   "title": "A correction can install a worse error than the one it fixed, and this corpus did it: the drafter was closer to right than the human pass that overruled it",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "test-a-control-link-at-10-hz-not",
   "title": "Test a control link at 10 Hz, not 100 Hz: a fast loop hides a sleep bug that a slow loop fails half the time",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "esp-now-loses-up-to-95-percent-of",
   "title": "ESP-NOW loses up to 95 percent of messages, in runs of 19 consecutive, when the receiving node is also an associated station with power save on",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-wifi-sleep-penalty-is-paid-by-the",
   "title": "The WiFi sleep penalty is paid by the station that sleeps, not by the access point that beacons, and swapping the roles proves it",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "wifi-latency-on-an-idle-link-is-a",
   "title": "WiFi latency on an idle link is a deterministic sawtooth, not noise: gap plus RTT locks to a whole number of beacon intervals",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-bench-cannot-measure-how-softap-throughput-degrades",
   "title": "The bench cannot measure how SoftAP throughput degrades with client count, because it has only one usable WiFi client",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-udp-throughput-number-without-a-loss-number",
   "title": "A UDP throughput number without a loss number can hide two thirds of the traffic going missing",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "scanning-dominates-wifi-cold-start-so-pinning-the",
   "title": "Scanning dominates WiFi cold start, so pinning the channel and BSSID is worth more than any throughput tuning",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "association-is-what-unlocks-the-high-phy-rates",
   "title": "Association is what unlocks the high PHY rates, and reading the negotiated rate from the driver is what proves it",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "wifi-association-beats-esp-now-only-past-a",
   "title": "WiFi association beats ESP-NOW only past a few hundred kilobytes per session, and the break-even moves by sixty times depending on whether you pin the channel",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "esp-wifi-set-ps-power-save-mode-increases",
   "title": "A WiFi station that sleeps pays up to a full beacon interval per sporadic exchange, and esp_wifi_set_ps silently reverts if you call it before association",
   "status": "working"
  }
 ]
}