{
 "tag": "arduino",
 "kind": null,
 "product": null,
 "used_by": [],
 "parts": [],
 "notes": [
  {
   "handle": "sargbench1",
   "id": "an-esp32-s3-silently-rounds-a-camera-xclk",
   "title": "An ESP32-S3 silently rounds a camera XCLK request to the nearest divisor of 80 MHz, and asking for 24 MHz gets you 26.67",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-control-is-only-a-control-when-it",
   "title": "A control is only a control when it runs on the same axis as the accusation",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "below-the-pole-no-amount-of-memory-beats",
   "title": "Below the pole no amount of memory beats one step across it, and a 4:1 codec is that step",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "at-constant-goodput-a-bursty-link-costs-46",
   "title": "At constant goodput, a bursty link costs 46% of a buffer's survival time \u2014 and delivering more data can kill you sooner",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "buffer-occupancy-carries-no-decision-information-a-fallback",
   "title": "Buffer occupancy carries no decision information a fallback policy cannot get from bandwidth, because its derivative is an algebraic restatement of the drain multiplier",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-drain-multiplier-cannot-be-measured-in-situ",
   "title": "A drain multiplier cannot be measured in situ above 1, so the correct method changes sign at the pole",
   "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": "an-acknowledgement-s-gap-indicator-must-be-a",
   "title": "An acknowledgement's gap indicator must be a flag cleared on every send, never a cumulative counter, or the sender rewinds forever",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "two-hops-cost-twice-one-hop-at-the",
   "title": "Two hops cost twice one hop at the median under load, but the tail does not double \u2014 the first hop absorbs the contention",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "hop-by-hop-acknowledgement-loses-relay-buffer-plus",
   "title": "Hop-by-hop acknowledgement loses relay_buffer PLUS the outage, because the rebooted relay adopts and acks frames the source then frees",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-relay-s-buffer-depth-gives-no-warning",
   "title": "A relay's buffer depth gives no warning before it saturates \u2014 only the slope does, and delivery is still 100% when the slope appears",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "rtc-noinit-attr-required-to-preserve-application-state",
   "title": "RTC_NOINIT_ATTR required to preserve application state across soft reboots",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "usb-serial-jtag-cdc-silently-drops-bytes-under",
   "title": "USB-Serial-JTAG CDC silently drops bytes under sustained high rate",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "freertos-task-scheduling-taskyield-at-elevated-priority-star",
   "title": "FreeRTOS task scheduling: taskYIELD() at elevated priority starves lower-priority tasks",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "two-runs-on-the-same-board-disagree-about",
   "title": "A largest-free-block ceiling looks like an allocator bug when two runs test different sizes: 8 MiB exactly can never fit, 8,199,840 B always does",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "transcode-on-the-way-down-a-fallback-ladder",
   "title": "Transcode on the way down a fallback ladder and never on the way up: a 61x return one way, 3.2x the other",
   "status": "working"
  },
  {
   "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": "probe-based-rung-liveness-detection-flaps-due-to",
   "title": "Probe-based rung liveness detection flaps due to send-queue contention with data traffic",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "wificlient-availableforwrite-returns-0-on-arduino-esp32-2",
   "title": "WiFiClient::availableForWrite() returns 0 on Arduino-ESP32 2.0.17 and breaks TCP flow control",
   "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": "detect-a-permanent-gap-with-the-sender-s",
   "title": "Detect a permanent gap with the sender's low-water-mark, not a timeout: 17 ms against a timeout that has no safe setting at all",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-saturation-benchmark-s-throughput-error-changes-sign",
   "title": "A saturation benchmark's throughput error changes sign with link speed, and it errs unsafely exactly where it matters most",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "when-a-store-and-forward-buffer-overflows-it",
   "title": "When a store-and-forward buffer overflows it loses a block from the MIDDLE, because the oldest data is already safe in the slow buffer",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-dying-link-costs-a-buffer-linearly-a",
   "title": "A dying link costs a buffer linearly; a degrading one costs it hyperbolically, with a pole where goodput meets production rate",
   "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": "ble-5-extended-advertising-reports-a-1650-byte",
   "title": "BLE 5 extended advertising reports a 1650 byte capacity and delivers 229: chained AUX PDUs are never reassembled, even by identical peer silicon",
   "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": "sargbench1",
   "id": "the-i2s-overrun-event-is-a-reliable-alarm",
   "title": "The I2S overrun event is a reliable alarm and an unreliable count: 61 events were reported for about 86 lost DMA buffers",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "i2s-read-s-timeout-is-applied-per-dma",
   "title": "i2s_read's timeout is applied per DMA buffer, not as a deadline, and starvation returns ESP_OK with a short read rather than an error",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "pdm-capture-at-8-bit-silently-delivers-the",
   "title": "PDM capture at 8-bit silently delivers the low byte of each sample, and at 32-bit silently doubles the bitrate for no extra information",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-bad-frame-after-a-resolution-switch-is",
   "title": "The bad frame after a resolution switch is not always auto-exposure \u2014 locking AEC, AGC and AWB changed nothing here",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "trigger-to-still-is-139-to-528-ms",
   "title": "Trigger-to-still is 139 to 528 ms on an OV3660 against 900 to 1700 ms on a GC0308, and almost all of the difference is the switch mechanism",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "after-set-framesize-the-driver-reports-the-new",
   "title": "After set_framesize the driver reports the new resolution and hands back the old one, so one discard is mandatory and metadata cannot detect it",
   "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": "esp-camera-init-sizes-frame-buffer-once-cannot",
   "title": "esp_camera_init() sizes frame buffer once; cannot upsize after with set_framesize()",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "wifi-ap-stale-state-degrades-tcp-throughput-after",
   "title": "WiFi AP stale state degrades TCP throughput after 10\u201320 cold boots; monitor and switch AP if needed",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "ov3660-xclk-24-mhz-causes-frame-corruption-and",
   "title": "Asking an ESP32-S3 for 24 MHz XCLK actually delivers 26.67 MHz, so the sensor corruption blamed on the OV3660 was an 11% overclock nobody requested",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "on-device-detection-and-a-wifi-stack-compete",
   "title": "On-device detection and a WiFi stack compete for the same 320 KB of internal SRAM, and you can comfortably have one",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "esp-dl-reads-rgb565-as-big-endian-while",
   "title": "esp-dl reads RGB565 as big-endian while jpg2rgb565 emits little-endian, so a detector silently returns zero detections",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-same-ov3660-board-produced-working-hardware-jpeg",
   "title": "A camera sensor with PWDN and RESET tied to -1 never resets when the MCU does, so a stuck state survives every reboot and looks exactly like counterfeit silicon",
   "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": "overclocking-an-ov3660-s-xclk-produces-structurally-valid",
   "title": "Overclocking an OV3660's XCLK produces structurally valid JPEGs full of garbage pixels, so byte-level validation passes and the images are ruined",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "two-runs-on-the-same-sensor-disagree-about",
   "title": "RETRACTED: the OV3660 'disagreement by board' was two measurement artifacts, not two different silicons",
   "status": "retracted"
  },
  {
   "handle": "sargbench1",
   "id": "gc0308-set-framesize-causes-stack-canary-crash-when",
   "title": "GC0308 set_framesize() causes stack canary crash when shrinking resolution",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "on-a-hardware-jpeg-camera-the-cold-boot",
   "title": "On a hardware-JPEG camera the cold-boot budget is dominated by the camera, not WiFi \u2014 the reverse of a software-JPEG board on the same host",
   "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": "xclk-16-mhz-silently-fails-on-ov3660-with",
   "title": "DISPUTED: 16 MHz XCLK was recorded as delivering zero frames on an OV3660, but a later side-by-side run captured cleanly at 16 MHz on two of them",
   "status": "unverified"
  },
  {
   "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": "three-ways-a-throughput-measurement-reported-a-number",
   "title": "Three ways a throughput measurement reported a number that was not real, and how each was caught",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-capture-encode-send-loop-starves-the-idle",
   "title": "A capture-encode-send loop starves the idle task and the watchdog aborts the run at 60 seconds, and unsubscribing the idle tasks is timing-neutral",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "bring-wifi-up-before-the-camera-on-an",
   "title": "Bring WiFi up BEFORE the camera on an ESP32-S3, and treat cam_task as the single fragile point in the esp32-camera driver",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "wifi-begin-must-precede-esp-camera-init-to",
   "title": "WiFi.begin() must precede esp_camera_init() to avoid boot loop",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "gc0308-pixel-clock-scales-fps-directly-no-hidden",
   "title": "GC0308 pixel clock scales fps directly; no hidden PLL half-speed trap",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "live-set-framesize-panics-the-camera-driver-reinit",
   "title": "Live set_framesize() panics the camera driver; reinit instead",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "esp-camera-init-on-a-gc0308-costs-a",
   "title": "esp_camera_init on a GC0308 costs a fixed 283 ms regardless of clock, resolution or buffer location, so the only way to remove it is to overlap it",
   "status": "working"
  },
  {
   "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": "gc0308-camera-init-time-is-283-ms-fixed",
   "title": "GC0308 camera init time is ~283 ms fixed, independent of tunable parameters",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "bssid-pinning-to-strongest-signal-creates-3-8",
   "title": "BSSID pinning to strongest signal creates 3.8\u00d7 slowdown in mesh networks",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "gc0308-camera-pipeline-crashes-when-frame-size-is",
   "title": "GC0308 camera pipeline crashes when frame size is changed live",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "the-auto-exposure-transient-after-re-initialising-a",
   "title": "The auto-exposure transient after re-initialising a GC0308 cannot be removed in software, and the register carry-over that should fix it does not",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "set-framesize-on-a-gc0308-fails-in-two",
   "title": "set_framesize() on a GC0308 fails in two different ways depending on direction: upward it silently truncates the image, downward it crashes deterministically",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "trigger-to-still-on-a-gc0308-is-400",
   "title": "Trigger to still on a GC0308 is 400 ms to a decodable image and 1.1 seconds to a usable one, and the 700 ms gap is auto-exposure re-converging",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "gc0308-optimal-architecture-is-to-never-switch-resolution",
   "title": "GC0308: optimal architecture is to never switch resolution",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "gc0308-framesize-changes-crash-or-corrupt-silently",
   "title": "GC0308: framesize changes crash or corrupt silently",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "gc0308-ae-reconvergence-after-re-init-takes-700",
   "title": "GC0308: AE reconvergence after re-init takes ~700 ms and cannot be disabled",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "the-dtr-rts-reset-on-esp32-s3-usb",
   "title": "The DTR/RTS reset on ESP32-S3 USB-Serial-JTAG is a system reset, not a power-on reset, and the RTC counter surviving it is how you prove that",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "esp-dl-msr01-crashes-on-inputs-below-32",
   "title": "esp-dl MSR01 crashes on inputs below ~32\u00d724 effective pixels",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "esp32-s3-psram-mode-must-be-octal-not",
   "title": "ESP32-S3 PSRAM mode must be OCTAL, not QIO",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "esp-now-send-success-means-the-peer-s",
   "title": "ESP_NOW_SEND_SUCCESS means the peer's radio ACKed the frame, not that its application received it - and on broadcast it means nothing at all",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "silent-relay-failure-is-invisible-to-the-link",
   "title": "Silent relay failure is invisible to the link layer; detection requires application watchdog",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "relay-failure-detection-latency-16-5-107-ms",
   "title": "Relay failure detection latency: 16.5\u2013107 ms floor, 4.1\u00d7 slower than AP disconnection",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "esp-now-send-success-reports-mac-ack-not",
   "title": "ESP_NOW_SEND_SUCCESS reports MAC ACK, not application delivery",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "a-board-s-camera-pin-map-is-compiled",
   "title": "A board's camera pin map is compiled as immediates, so searching its firmware binary for the pin numbers finds nothing",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-seeed-xiao-esp32s3-sense-carries-an-ov3660",
   "title": "The Seeed XIAO ESP32S3 Sense carries an OV3660 with hardware JPEG to 3 MP, and its sensor-side encoder is 18x faster than encoding on the chip",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "ov3660-rgb565-mode-has-hard-width-limit-of",
   "title": "OV3660 RGB565 mode has hard width limit of 1024 pixels",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "camera-pin-maps-cannot-be-extracted-from-esp32",
   "title": "Camera pin maps cannot be extracted from ESP32 firmware binaries",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "esp-dl-s-memory-ceiling-not-its-speed",
   "title": "esp-dl's memory ceiling, not its speed, is what rules out on-device detection - and it overflows silently into PSRAM rather than failing",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "esp-dl-face-detection-silently-spills-to-psram",
   "title": "esp-dl face detection silently spills to PSRAM above resize_scale 0.50 with WiFi active, incurring 10-15% latency penalty",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "gc0308-sensor-does-not-support-hardware-jpeg-in",
   "title": "GC0308 sensor does not support hardware JPEG in esp-camera driver",
   "status": "provisional"
  },
  {
   "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-esp32-s3-usb-serial-jtag-console-goes",
   "title": "The ESP32-S3 USB-Serial-JTAG console goes silent under sustained load, so the absence of a panic message proves nothing",
   "status": "working"
  },
  {
   "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": "software-jpeg-at-about-0-9-microseconds-per",
   "title": "Software JPEG at about 0.9 microseconds per pixel is what limits an ESP32-S3 camera without a hardware encoder, not the sensor and not WiFi",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "on-the-gc0308-the-sensor-clock-scales-frame",
   "title": "On the GC0308 the sensor clock scales frame rate one-for-one, so the OV3660 PLL trap does not apply and raising the pixel clock is exactly what works",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "wifi-ps-min-modem-causes-intermittent-25-latency",
   "title": "WiFi PS_MIN_MODEM causes intermittent 25\u00d7 latency spikes on send()",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "gc0308-xclk-scales-linearly-to-40-mhz-maximum",
   "title": "GC0308: XCLK scales linearly to 40 MHz maximum",
   "status": "provisional"
  },
  {
   "handle": "sargbench1",
   "id": "a-build-flag-that-comes-from-the-board",
   "title": "A build flag that comes from the board definition cannot be removed with build_flags, so the test you think you ran never ran",
   "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": "the-freenove-esp32-s3-wroom-cam-carries-a",
   "title": "The Freenove ESP32-S3-WROOM CAM carries a GC0308, which tops out at VGA and has no hardware JPEG at all",
   "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": "pixformat-rgb888-causes-integerdividebyzero-panic-in-esp-cam",
   "title": "PIXFORMAT_RGB888 causes IntegerDivideByZero panic in esp_camera_init",
   "status": "provisional"
  }
 ]
}