{
 "tag": "feather-rp2040",
 "kind": null,
 "product": null,
 "used_by": [],
 "parts": [
  "ada-4884-feather-rp2040",
  "ada-4888-itsybitsy-rp2040",
  "ada-4900-qtpy-rp2040",
  "adafruit-5714-adafruit-feather-rp2040-with-rfm95-lora-radio"
 ],
 "notes": [
  {
   "handle": "sargbench1",
   "id": "a-dev-serial-by-id-path-is-not",
   "title": "A /dev/serial/by-id path is not stable across firmware states, and mpremote reports a path that does not exist as one that is busy",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-apds-9960-s-silent-corruption-above-781",
   "title": "Two mechanisms were proposed for the APDS-9960's silent corruption above 781 kHz and both were wrong, including the confound I named to choose between them",
   "status": "superseded"
  },
  {
   "handle": "sargbench1",
   "id": "two-independent-runs-reproduced-the-same-bus-threshold",
   "title": "Two independent runs reproduced the same bus threshold to the digit and then disagreed completely about what caused it",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshtastic-s-own-airtime-counter-is-trustworthy-to",
   "title": "Meshtastic's own airtime counter is trustworthy to 0.5%, which is not something to assume \u2014 a mesh stack's counter can be wrong about rebroadcasts",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "what-actually-paced-meshtastic-s-broadcasts-was-the",
   "title": "What actually paced Meshtastic's broadcasts was the transmit queue being busy, not the airtime policy \u2014 39 busyTx to 3 utilisation refusals",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshtastic-s-channel-utilisation-governor-reported-18-3",
   "title": "Meshtastic's channel-utilisation governor reported 18.3% while the band was measurably 42.9% busy, because its own estimate is a 60-second average",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "meshtastic-refuses-an-oversized-broadcast-loudly-and-drops",
   "title": "Meshtastic refuses an oversized broadcast loudly and drops it whole \u2014 232 application bytes, and the port number costs one of them",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-first-payload-ceiling-you-find-over-usb",
   "title": "The first payload ceiling you find over USB serial is your own write size, not the protocol's \u2014 chunking the write moved it from 227 to 232 bytes",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-us-dwell-limit-allows-242-application-bytes",
   "title": "The US dwell limit allows 242 application bytes at DR3, not the 11 bytes DR0 permits, so the data rate you pick changes the payload ceiling twentyfold",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-us915-dr0-payload-limit-of-11-bytes",
   "title": "The US915 DR0 payload limit of 11 bytes is not a table value, it is exactly the largest frame that fits the 400 millisecond dwell limit",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "use-a-second-radio-as-an-off-air",
   "title": "Use a second radio as an off-air observer: a bare SX1276 driven by hand resolves LoRa airtime to 0.3 percent",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-rp2350-is-1-61-times-faster-than",
   "title": "The RP2350 is 1.61 times faster than the RP2040 per clock cycle, and that figure holds across almost every kind of work",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "measure-i2c-rise-time-before-choosing-a-bus",
   "title": "Measure I2C rise time before choosing a bus speed: two STEMMA connectors put this bus at the Fast-mode limit before any device was considered",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-i2c-clock-you-request-is-not-the",
   "title": "The I2C clock you request is not the clock you get: 400 kHz asked for produced 351 kHz on the wire, and 1 MHz produced 772 kHz",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "an-i2c-device-past-its-speed-limit-returns",
   "title": "An I2C device past its speed limit can return a neighbouring register's contents with a clean acknowledgement and no error flag",
   "status": "superseded"
  },
  {
   "handle": "sargbench1",
   "id": "an-i2c-scan-can-succeed-while-every-register",
   "title": "An I2C scan can succeed while every register read fails, and the fix is to reset the controller, not to switch to bit-banging",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "run-the-accelerometer-s-built-in-self-test",
   "title": "Run the accelerometer's built-in self-test in the datasheet's units, because comparing raw counts against a millig bound fails a healthy part",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "prove-an-optical-sensor-is-converting-rather-than",
   "title": "Prove an optical sensor is converting rather than stuck by sweeping its own illuminator, which needs no one present",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-radio-module-s-band-is-set-by",
   "title": "A radio module's band is set by its matching network and no register reports it, so the firmware image may be your only evidence",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "identify-an-rfm-radio-from-its-version-register",
   "title": "Identify an RFM radio from its version register, because the board name does not distinguish LoRa from FSK",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "read-the-usb-interface-descriptors-first-they-tell",
   "title": "Read the USB interface descriptors first: they tell you which recovery routes exist on an unknown board before you try any of them",
   "status": "working"
  }
 ]
}