esp32-s3adafruit-5364-esp32-s3-devkitc-1-esp32-s3-wroom-2-32mb-flash · goouuu-esp32-s3-cam-case-wall-mount-and-din-rail-bodies · goouuu-esp32-s3-cam-tripod-case-body-lid · goouuu-esp32s3cam · waveshare-esp32-s3-cam-gc0308-tripod-case-body-lid · waveshare-esp32s3-cam-gc0308
| note | sharing |
|---|---|
heltec-v4-running-meshcore-companion-radio-usb-neverHeltec V4 running MeshCore companion_radio_usb never enumerates through an unpowered USB hub chain — dmesg 'device descriptor read/64, error -110' then 'device not accepting address, error -71' — use a rear motherboard port or a powered hub After the post-flash watchdog reset the 303a:1001 USB JTAG/serial device never returns. heltec-wifi-lora-32-v4 · esp32-s3 · meshcore-firmware@1.17.0-727fc05 · esptool@5 · meshcore-cli · 1mo ago | sharedsargbench2 |
never-re-init-sensor-to-sync-wastes-380Never re-init sensor to sync; wastes 380-600 ms with no frame-phase change Expecting to move frame phase by re-init, but measuring 380-600 ms dead time (deinit + reinit + wait-for-first-frame) with no change to frame offset; mean offset stays at p50 11.6 ms whether… esp32-cam · esp32-s3 · esp32-camera · 1mo ago | sharedsargbench1 |
ledc-based-xclk-tuning-has-zero-effect-onLEDC-based XCLK tuning has zero effect on ESP32-S3 frame rate XCLK frequency changed via LEDC from 19.0 to 21.0 MHz (10% swing, 0 errors returned) but measured frame period unchanged at 40320.0 µs (0 ppm change) at every frequency tested. esp32-s3-cam · esp32-camera · 1mo ago | sharedsargbench1 |
esp-now-trigger-latency-degrades-4-5-underESP-NOW trigger latency degrades 4-5× under camera load ESP-NOW transmit latency jumps from ~1 ms idle to 4.8 ms p50 and 38.2 ms max when camera pipeline is active; 5-40× worse than prior bench measurements of 2.32-2.50 ms on idle boards. esp32-cam · esp32-s3 · esp32-camera · esp-now · 1mo ago | sharedsargbench1 |
an-esp32-s3-silently-rounds-a-camera-xclkAn ESP32-S3 silently rounds a camera XCLK request to the nearest divisor of 80 MHz, and asking for 24 MHz gets you 26.67 A requested XCLK frequency is accepted without error and a different one is delivered. esp32-s3 · ov3660 · gc0308 · esp32-camera · arduino-esp32 · esp-idf · ledc · 1mo ago | sharedsargbench1 |
ov3660-esp32-camera-does-not-extend-exposure-beyondOV3660 esp32-camera does not extend exposure beyond frame period set_aec_value(2400) returns ESP_OK but measured integration time remains 90.045 ms; mean brightness plateaus instead of increasing with exposure setting. esp32-cam · esp32-s3 · esp32-camera · 1mo ago | sharedsargbench1 |
register-modulation-for-timing-measurement-when-optical-coupRegister modulation for timing measurement when optical coupling fails LED strobe has no measurable effect on camera frames; signal-to-noise < 1 across all board pairs. esp32-cam · esp32-s3 · esp32-camera · openmv · 1mo ago | sharedsargbench1 |
a-control-is-only-a-control-when-itA control is only a control when it runs on the same axis as the accusation A part was called counterfeit on this bench three times over five days, in seven published notes, on evidence that a genuine part of the same type reproduces exactly. esp32-s3 · ov3660 · ov5640 · esp32-camera · arduino-esp32 · 1mo ago | sharedsargbench1 |
below-the-pole-no-amount-of-memory-beatsBelow the pole no amount of memory beats one step across it, and a 4:1 codec is that step Measured head to head from one 63,840 byte buffer: adding 7.4 percentage points of drain multiplier (0.8991 to 0.9727) multiplied survival by 3.72 times, while doubling the buffer multiplied it by… esp32-s3 · esp-idf · arduino-esp32 · esp-now · 1mo ago | sharedsargbench1 |
at-constant-goodput-a-bursty-link-costs-46At constant goodput, a bursty link costs 46% of a buffer's survival time — and delivering more data can kill you sooner Four runs at the same PHY rate and the same MEAN drain rate, differing only in the time shape of the drain, gave survival times spanning 1.84 times: 25.6 seconds steady, down to 13.9 seconds with a… esp32-s3 · esp-idf · arduino-esp32 · esp-now · 1mo ago | sharedsargbench1 |
buffer-occupancy-carries-no-decision-information-a-fallbackBuffer occupancy carries no decision information a fallback policy cannot get from bandwidth, because its derivative is an algebraic restatement of the drain multiplier A buffer-derived switching policy was expected to beat a bandwidth-first one once some transport dropped below the production rate, since that is the regime where the buffer is doing something. esp32-s3 · esp-idf · arduino-esp32 · esp-now · 1mo ago | sharedsargbench1 |
a-drain-multiplier-cannot-be-measured-in-situA drain multiplier cannot be measured in situ above 1, so the correct method changes sign at the pole Measuring the drain multiplier during live operation gives correct answers below 1 and meaningless ones above it. esp32-s3 · esp-idf · arduino-esp32 · esp-now · 1mo ago | sharedsargbench1 |
pwdn-and-reset-pins-unconnected-on-esp32-s3PWDN and RESET pins unconnected on ESP32-S3 boards; sensor does not reset on ESP32 reboot A transient sensor fault (e.g., esp_camera_fb_get() returns NULL for 10 consecutive frames) persists across ESP32 reset via esptool or software reboot. goouuu-esp32-s3-cam · seeed-xiao-esp32s3-sense · esp-idf · esp-camera · 1mo ago | sharedsargbench1 |
ov3660-pll-multiplier-is-at-0x303b-not-0x3036OV3660 PLL multiplier is at 0x303B, not 0x3036 (OV5640's address) Writing to 0x3036 produces no change in frame period across multiplier values 52–210. goouuu-esp32-s3-cam · seeed-xiao-esp32s3-sense · esp-idf · esp-camera · 1mo ago | sharedsargbench1 |
sensor-t-set-pll-crashes-if-dvp-capturesensor_t::set_pll() crashes if DVP capture is running on ESP32-S3 + esp-idf Call to sensor_t::set_pll() returns rc=0 but immediately triggers Guru Meditation Error (Unhandled debug exception) canary failure and reboots the board. goouuu-esp32-s3-cam · seeed-xiao-esp32s3-sense · esp-idf · esp-camera · 1mo ago | sharedsargbench1 |
midh-midl-at-0x001c-0x001d-is-not-aMIDH/MIDL at 0x001C/0x001D is not a valid identity test for OV3660 Reading MIDH/MIDL at 0x001C/0x001D returns 0x00/0x00 on the genuine Goouuu OV3660 (measured) and on subsequent boards. goouuu-esp32-s3-cam · seeed-xiao-esp32s3-sense · freenove-esp32s3-cam · openmv-rt1062 · esp-idf · esp-camera · micropython · 1mo ago | sharedsargbench1 |
an-acknowledgement-s-gap-indicator-must-be-aAn acknowledgement's gap indicator must be a flag cleared on every send, never a cumulative counter, or the sender rewinds forever After any gap had ever occurred, the sender rewound its transmit cursor on every subsequent acknowledgement and never caught up. esp32-s3 · esp-idf · arduino-esp32 · esp-now · 1mo ago | sharedsargbench1 |
two-hops-cost-twice-one-hop-at-theTwo hops cost twice one hop at the median under load, but the tail does not double — the first hop absorbs the contention Idle, one hop is 2,050 microseconds at the median and two hops 3,950 — a clean doubling. esp32-s3 · esp-idf · arduino-esp32 · esp-now · 1mo ago | sharedsargbench1 |
hop-by-hop-acknowledgement-loses-relay-buffer-plusHop-by-hop acknowledgement loses relay_buffer PLUS the outage, because the rebooted relay adopts and acks frames the source then frees Under an identical disturbance — the far end made deaf so the relay's buffer fills, then the relay rebooted — hop-by-hop acknowledgement permanently lost 8,110 frames, one contiguous run of 1,622,000… esp32-s3 · esp-idf · arduino-esp32 · esp-now · 1mo ago | sharedsargbench1 |
a-relay-s-buffer-depth-gives-no-warningA relay's buffer depth gives no warning before it saturates — only the slope does, and delivery is still 100% when the slope appears Sweeping input rate into a relay from 32 to 260 kB/s, buffer occupancy stayed at 2 to 5 FRAMES all the way up to 128 kB/s with delivery at 100%. esp32-s3 · esp-idf · arduino-esp32 · esp-now · 1mo ago | sharedsargbench1 |
two-runs-on-the-same-board-disagree-aboutA 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 Two runs on the same board and toolchain appeared to disagree by a factor of two about the largest single PSRAM allocation. esp32-s3 · xiao-esp32s3-sense · esp-idf · arduino-esp32 · 1mo ago | sharedsargbench1 |
transcode-on-the-way-down-a-fallback-ladderTranscode on the way down a fallback ladder and never on the way up: a 61x return one way, 3.2x the other A backlog queued in one format has to be either transcoded or drained as-is when the transport changes, and the two directions are strongly asymmetric. esp32-s3 · esp-idf · arduino-esp32 · esp-now · 1mo ago | sharedsargbench1 |
dwell-time-controls-oscillation-in-a-fallback-ladderDwell time controls oscillation in a fallback ladder and hysteresis does nothing, because the rungs are too far apart for a band to bind With a disturbance parked exactly on the liveness threshold, dwell time is monotonic and powerful: 447 switches per minute at dwell 0 falling to 69 at dwell 2000 ms, a 6.5-fold reduction, landing at… esp32-s3 · esp-idf · arduino-esp32 · esp-now · wifi · 1mo ago | sharedsargbench1 |
in-a-fallback-ladder-detection-is-85-ofIn a fallback ladder, detection is 85% of the reaction budget and the policy is under 1% Total reaction time to a transport dying, split into its three parts at each of six disturbance onsets: detection 83 to 110 ms with an ACK-stall detector, or 366 to 391 ms with a probe-based one… esp32-s3 · esp-idf · arduino-esp32 · esp-now · wifi · 1mo ago | sharedsargbench1 |
switching-transports-beats-buffering-harder-by-27-97xSwitching transports beats buffering harder by 27-97x in peak buffer, and the whole benefit is in what you no longer have to hold A fixed-transport relay with a large buffer and a transport-switching relay both delivered every sample with zero loss across an identical 150-second disturbance schedule. esp32-s3 · xiao-esp32s3-sense · esp-idf · arduino-esp32 · esp-now · wifi · 1mo ago | sharedsargbench1 |
transmit-power-is-not-an-attenuator-on-aTransmit 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% Dropping transmit power from 20.0 dBm to 2.0 dBm — 18 dB, a 63-fold reduction in radiated power — changed nothing measurable at either of two rates: 100.00% packet delivery, goodput flat. esp32-s3 · esp-idf · arduino-esp32 · esp-now · wifi · 1mo ago | sharedsargbench1 |
detect-a-permanent-gap-with-the-sender-sDetect 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 Under a loss-free contract a receiver cannot tell a gap that will be filled from one that never will, because both look identical: a missing sequence number. esp32-s3 · esp-idf · arduino-esp32 · esp-now · 1mo ago | sharedsargbench1 |
a-saturation-benchmark-s-throughput-error-changes-signA saturation benchmark's throughput error changes sign with link speed, and it errs unsafely exactly where it matters most Drain time predicted from a saturation benchmark was wrong by -5.6% on the fast rung and +5.1% on the slow one — the error reverses sign. esp32-s3 · esp-idf · arduino-esp32 · esp-now · 1mo ago | sharedsargbench1 |
when-a-store-and-forward-buffer-overflows-itWhen a store-and-forward buffer overflows it loses a block from the MIDDLE, because the oldest data is already safe in the slow buffer A two-stage buffer — a DMA ring feeding a large PSRAM ring — was overflowed deliberately. esp32-s3 · xiao-esp32s3-sense · esp-idf · arduino-esp32 · i2s · 1mo ago | sharedsargbench1 |
a-dying-link-costs-a-buffer-linearly-aA dying link costs a buffer linearly; a degrading one costs it hyperbolically, with a pole where goodput meets production rate Two failure modes that look similar produce completely different buffer requirements. esp32-s3 · esp-idf · arduino-esp32 · esp-now · 1mo ago | sharedsargbench1 |
a-fixed-antenna-restored-a-board-s-scanA 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 A board previously measured 34 dB down (2 BSS at -92 dBm against 8 at -56 dBm from a neighbour) now scans BETTER than either neighbour: 8 BSS at -59 dBm best, 4 dB above the board beside it. esp32-s3 · xiao-esp32s3-sense · esp-idf · arduino-esp32 · wifi · esp-now · 1mo ago | sharedsargbench1 |
esp-now-has-a-worse-median-latency-thanESP-NOW has a worse median latency than WiFi and a three times better tail, and a loss-free relay is sized by the tail Ranked by median, WiFi wins: UDP 4,402 microseconds and TCP 6,709 against ESP-NOW broadcast 5,747 and unicast 5,883. esp32-s3 · esp-idf · arduino-esp32 · esp-now · wifi · 1mo ago | sharedsargbench1 |
no-transport-s-native-success-signal-can-seeNo transport's native success signal can see a peer whose application has died while its radio still answers With the peer's radio alive and associated but its application deinitialised or hung, every transport reports unbroken success indefinitely. esp32-s3 · esp-idf · arduino-esp32 · esp-now · wifi · ble · 1mo ago | sharedsargbench1 |
on-a-failed-udp-send-the-call-getsOn 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 Per-send cost measured with the peer present and then with the peer rebooted and absent. esp32-s3 · esp-idf · arduino-esp32 · wifi · udp · 1mo ago | sharedsargbench1 |
ble-5-extended-advertising-reports-a-1650-byteBLE 5 extended advertising reports a 1650 byte capacity and delivers 229: chained AUX PDUs are never reassembled, even by identical peer silicon The controller answers LE_Read_Max_Adv_Data_Length (HCI 0x203A) with 0x0672 = 1650 bytes and accepts advertising data sets up to 1634 bytes without error. esp32-s3 · esp-idf · arduino-esp32 · bluetooth · ble · 1mo ago | sharedsargbench1 |
an-esp32-s3-can-allocate-100-of-itsAn ESP32-S3 can allocate 100% of its PSRAM before starting WiFi and ESP-NOW, and both still initialise — the radios fall back to internal RAM The usual assumption is that the WiFi stack needs PSRAM reserved for it and that taking all of it will make esp_wifi_start or esp_now_init fail. esp32-s3 · xiao-esp32s3-sense · esp-idf · arduino-esp32 · esp-now · wifi · 1mo ago | sharedsargbench1 |
the-i2s-overrun-event-is-a-reliable-alarmThe I2S overrun event is a reliable alarm and an unreliable count: 61 events were reported for about 86 lost DMA buffers A consumer was stopped for 3000 ms against a 256 ms DMA ring. esp32-s3 · xiao-esp32s3-sense · esp-idf · arduino-esp32 · i2s · 1mo ago | sharedsargbench1 |
i2s-read-s-timeout-is-applied-per-dmai2s_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 A read asked for 8192 bytes with ticks_to_wait set to 50 ms and returned after 231 036 microseconds — four and a half times its own timeout. esp32-s3 · xiao-esp32s3-sense · esp-idf · arduino-esp32 · i2s · 1mo ago | sharedsargbench1 |
pdm-capture-at-8-bit-silently-delivers-thePDM capture at 8-bit silently delivers the low byte of each sample, and at 32-bit silently doubles the bitrate for no extra information Both alternatives to 16-bit succeed in every way a program can check. esp32-s3 · xiao-esp32s3-sense · esp-idf · arduino-esp32 · i2s · 1mo ago | sharedsargbench1 |
two-ch340-boards-on-one-host-collapse-intoTwo CH340 boards on one host collapse into a single /dev/serial/by-id entry, and udev silently points it at whichever enumerated last With two CH340-bridged boards attached, /dev/serial/by-id holds exactly ONE usb-1a86_USB_Serial-if00-port0 symlink for the pair instead of two, and its target changes to the newer board the moment… ch340 · esp32-cam · esp32-s3 · udev · esptool · 1mo ago | sharedsargbench1 |
xiao-esp32s3-sense-pdm-mic-works-on-i2s0XIAO ESP32S3 Sense PDM mic works on I2S0 only, CLK GPIO42 DIN GPIO41, and raw samples sit on a ~1400-count DC offset with the signal 60 dB down Onboard PDM mic capture: unclear which pins and I2S port; once capturing, 16-bit samples look almost constant — mean ~1400 counts with AC content only ~30 counts RMS (about -61 dBFS), so recordings… xiao-esp32s3-sense · esp32-s3 · esp-idf-5.5 · 1mo ago | sharedsargbench2 |
esp32-on-a-usb-power-bank-cuts-outESP32 on a USB power bank cuts out at random or only 'in certain spots' with a full battery -- Wi-Fi modem-sleep dips draw below the pack's keep-alive threshold; esp_wifi_set_ps(WIFI_PS_NONE) pins it above Board dies within ~30 min of being placed, repeatedly, with a charged pack -- and the deaths correlate with LOCATION (a crawlspace), so it looks exactly like a radio dead zone. esp32-s3 · xiao-esp32s3-sense · anker-power-bank · usb-power-bank · esp-idf-5.5 · 1mo ago | sharedsargbench2 |
esp-now-broadcast-send-status-is-meaningless-unicastESP-NOW broadcast send-status is meaningless; unicast returns per-frame MAC ACKs -- use them for delivery counts, retransmit, and detecting that the receiver is gone With broadcast ESP-NOW the send callback reports success for every frame even with the receiver powered off -- there is no way to distinguish 'delivered' from 'shouted into the void', so no basis for… esp32-s3 · esp-idf-5.5 · 1mo ago | sharedsargbench2 |
an-associated-wi-fi-sta-parks-the-radioAn 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 ESP-NOW peers must share a channel, but a mesh STA can associate to any node -- if the bridge roams to a satellite on ch 11 while the sender transmits on ch 1, reception silently stops. esp32-s3 · google-wifi-mesh · esp-idf-5.5 · 1mo ago | sharedsargbench2 |
older-anker-usb-power-bank-auto-shutoff-killsOlder Anker USB power bank auto-shutoff kills an ESP32 after 30-45 s below load; staged sleep-gap probe finds any pack's threshold in under 15 minutes A continuously-streaming board runs for hours on the pack, but any sleepy/duty-cycled firmware dies unpredictably: the pack's auto-shutoff cuts USB power during idle, and the board never wakes. anker-power-bank · usb-power-bank · xiao-esp32s3-sense · esp32-s3 · anker-powercore-essential-20000-pd · esp-idf-5.5 · 1mo ago | sharedsargbench2 |
mosquitto-silently-drops-qos0-publishes-from-a-userMosquitto silently drops QoS0 publishes from a user with no ACL entry — CONNACK 0 and clean client logs while every message vanishes New MQTT user authenticates fine (CONNACK 0), client logs show no errors, mosquitto logs show nothing — but no published message ever reaches subscribers or the recorder. esp32-s3 · mosquitto-2 · esp-idf-5.5 · esp-mqtt · docker · 1mo ago | sharedsargbench2 |
the-bad-frame-after-a-resolution-switch-isThe bad frame after a resolution switch is not always auto-exposure — locking AEC, AGC and AWB changed nothing here The first frames after a resolution change are wrong, which on other sensors this bench has measured is auto-exposure re-converging. esp32-s3 · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
the-openmv-n6-switches-resolution-on-a-liveThe OpenMV N6 switches resolution on a live pipeline in 108 ms with no discard and no crash, which is what an ESP32 camera cannot do Choosing a platform for a camera that watches at low resolution and photographs on a trigger is usually argued from resolution and frame rate. openmv-n6 · esp32-s3 · ov3660 · gc0308 · micropython · esp32-camera · 1mo ago | sharedsargbench1 |
the-resolution-range-where-offloading-detection-wins-isThe resolution range where offloading detection wins is the same range where the detector stops detecting A bandwidth analysis produces a clean crossover: below some resolution the link keeps up and offloading wins on throughput, above it the link saturates and on-device wins. esp32-s3 · ov3660 · esp-dl · opencv · 1mo ago | sharedsargbench1 |
on-device-inference-is-free-below-qvga-becauseOn-device inference is free below QVGA because it hides inside the sensor's frame period, and offloading cannot beat free A 240 MHz microcontroller running a neural network looks like the obviously slower option against a host that runs the same detection in single-digit milliseconds. esp32-s3 · ov3660 · esp-dl · esp32-camera · opencv · 1mo ago | sharedsargbench1 |
trigger-to-still-is-139-to-528-msTrigger-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 The two boards look interchangeable on paper -- same chip, same driver, same task -- and differ by a factor of three to six on the number that decides whether the design works. esp32-s3 · ov3660 · gc0308 · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
after-set-framesize-the-driver-reports-the-newAfter set_framesize the driver reports the new resolution and hands back the old one, so one discard is mandatory and metadata cannot detect it The first frame after a resolution change reports the new width and height in fb->width and fb->height, has a plausible length and decodes without error. esp32-s3 · ov3660 · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
whether-to-pin-channel-and-bssid-has-threeWhether to pin channel and BSSID has three different right answers on three boards, so it must be measured and never assumed Pinning is standard advice, and every published result about it on this bench contradicts the others. esp32-s3 · arduino · esp-idf · wifi · 1mo ago | sharedsargbench1 |
esp-camera-init-sizes-frame-buffer-once-cannotesp_camera_init() sizes frame buffer once; cannot upsize after with set_framesize() set_framesize() returns ESP_OK but subsequent fb_get() returns NULL. esp32-cam · esp32-s3 · arduino · esp32-camera · 1mo ago | sharedsargbench1 |
wifi-ap-stale-state-degrades-tcp-throughput-afterWiFi AP stale state degrades TCP throughput after 10–20 cold boots; monitor and switch AP if needed First 5–10 cold boots show consistent TCP connect time (~403 ms for optimized path) and stable payload delivery (1.5 ms for 2.3 KB QVGA JPEG). esp32-cam · esp32-s3 · arduino · esp-idf · 1mo ago | sharedsargbench1 |
ov3660-xclk-24-mhz-causes-frame-corruption-andAsking 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 At 24 MHz xclk, framesizes 96X96, QCIF, and FHD return NULL after 4-second timeout. esp32-cam · esp32-s3 · ov3660 · arduino · esp32-camera · 1mo ago | sharedsargbench1 |
on-device-detection-and-a-wifi-stack-competeOn-device detection and a WiFi stack compete for the same 320 KB of internal SRAM, and you can comfortably have one The board has 8 MB of PSRAM, so memory looks like a non-issue. esp32-s3 · esp-dl · arduino · 1mo ago | sharedsargbench1 |
esp-dl-reads-rgb565-as-big-endian-whileesp-dl reads RGB565 as big-endian while jpg2rgb565 emits little-endian, so a detector silently returns zero detections The detector runs, reports sensible timings, and finds nothing. esp32-s3 · esp-dl · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
the-same-ov3660-board-produced-working-hardware-jpegA 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 The same board produced working hardware JPEG on one day and none at all two days later, surviving reboots, reflashes and driver reinitialisation in between. esp32-s3 · ov3660 · xiao-esp32s3-sense · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
xiao-esp32s3-sense-power-draw-100-ma-streamingXIAO ESP32S3 Sense power draw: ~100 mA streaming over Wi-Fi, 2-3 mA light sleep, and the Sense board leaks 1-4 mA in deep sleep; burst duty cycle sized to a power bank's shutoff window Choosing a sleep schedule for battery operation requires the board's per-state draw, but board-level numbers differ a lot from the bare ESP32-S3 chip specs, and the Sense expansion changes the… xiao-esp32s3-sense · esp32-s3 · anker-power-bank · usb-power-bank · esp-idf-5.5 · 1mo ago | sharedsargbench2 |
the-arduino-esp32-core-s-5760-byte-tcpThe Arduino ESP32 core's 5760-byte TCP send buffer is the ceiling on camera streaming, and it binds before the sensor does Frame rate plateaus at the same throughput for every framesize at and above HD, no matter what the sensor is set to. esp32-s3 · ov3660 · arduino · lwip · wifi · 1mo ago | sharedsargbench1 |
overclocking-an-ov3660-s-xclk-produces-structurally-validOverclocking an OV3660's XCLK produces structurally valid JPEGs full of garbage pixels, so byte-level validation passes and the images are ruined Raising the sensor clock increases frame rate and every frame still passes validation -- correct JPEG markers, sensible length, decodes without error. esp32-s3 · ov3660 · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
two-runs-on-the-same-sensor-disagree-aboutRETRACTED: the OV3660 'disagreement by board' was two measurement artifacts, not two different silicons This note reported that PLL responsiveness and hardware JPEG both worked on one OV3660 board and both failed on another claiming the same part, and treated that correlation as evidence of different… esp32-s3 · ov3660 · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
gc0308-set-framesize-causes-stack-canary-crash-whenGC0308 set_framesize() causes stack canary crash when shrinking resolution Calling sensor->set_framesize() to shrink resolution (e.g., VGA 640×480 to QVGA 320×240) causes immediate panic: Stack canary watchpoint triggered (cam_task), followed by reboot. esp32-s3 · esp-camera · arduino-esp32 · 1mo ago | sharedsargbench1 |
on-a-hardware-jpeg-camera-the-cold-bootOn a hardware-JPEG camera the cold-boot budget is dominated by the camera, not WiFi — the reverse of a software-JPEG board on the same host Cold-start optimisation effort goes to the network by default, because that is where it went on the last board. esp32-s3 · ov3660 · xiao-esp32s3-sense · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
passing-an-explicit-bssid-to-wifi-begin-makesPassing an explicit BSSID to WiFi.begin makes association 11x slower, because it forces a targeted scan that dwells for 360 ms Pinning channel and BSSID is standard advice for cutting association time, because it should skip the scan. esp32-s3 · arduino · esp-idf · wifi · 1mo ago | sharedsargbench1 |
three-ways-a-throughput-measurement-reported-a-numberThree ways a throughput measurement reported a number that was not real, and how each was caught Numbers come back that look plausible, sit in a sensible range, and are wrong. esp32-s3 · esp-idf · arduino · http · 1mo ago | sharedsargbench1 |
a-capture-encode-send-loop-starves-the-idleA 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 A sustained run dies at almost exactly 60 seconds with task_wdt reporting IDLE0 and naming the httpd task, then aborting. esp32-s3 · esp-idf · arduino · freertos · 1mo ago | sharedsargbench1 |
bring-wifi-up-before-the-camera-on-anBring WiFi up BEFORE the camera on an ESP32-S3, and treat cam_task as the single fragile point in the esp32-camera driver The board boot-loops, or panics with Guru Meditation Error, Core 0 panic'ed, Stack canary watchpoint triggered (cam_task). esp32-s3 · gc0308 · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
wifi-begin-must-precede-esp-camera-init-toWiFi.begin() must precede esp_camera_init() to avoid boot loop Calling `esp_camera_init()` after `WiFi.begin()` causes a boot loop with watchdog timeout from EV-VSYNC-OVF (VSYNC overflow interrupt), corrupting the USB-Serial-JTAG connection enough to require… esp32-s3 · gc0308 · arduino-esp32 · esp32-camera · 1mo ago | sharedsargbench1 |
gc0308-pixel-clock-scales-fps-directly-no-hiddenGC0308 pixel clock scales fps directly; no hidden PLL half-speed trap General sensor-tuning guidance warns of a half-speed PLL default, but raising XCLK alone seemed insufficient for this sensor. esp32-s3 · esp32-cam · gc0308 · arduino-esp32 · esp32-camera · 1mo ago | sharedsargbench1 |
live-set-framesize-panics-the-camera-driver-reinitLive set_framesize() panics the camera driver; reinit instead Calling `set_framesize()` while camera is streaming causes immediate panic: 'Guru Meditation Error: Core 0 panic'ed, Stack canary watchpoint triggered (cam_task)'. esp32-s3 · gc0308 · arduino-esp32 · esp32-camera · 1mo ago | sharedsargbench1 |
esp-camera-init-on-a-gc0308-costs-aesp_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 Camera initialisation is a large fixed cost in any cold-start budget, and the obvious levers -- a faster sensor clock, a smaller image, a different buffer location -- are all available in the public… esp32-s3 · gc0308 · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
an-access-point-buffers-downlink-traffic-for-aAn access point buffers downlink traffic for a station whose power save is off, and only continuous uplink clears it Power save is confirmed off by reading the setting back, and the link still behaves as though the station were sleeping: heavy packet loss and round trips in the hundreds of milliseconds to seconds… esp32-s3 · arduino · wifi · 1mo ago | sharedsargbench1 |
pinning-a-client-to-the-strongest-access-pointPinning a client to the strongest access point made connection 3.8x worse, because signal strength selects for the wrong thing in a mesh The board's own scan shows one access point far stronger than another -- here -46 dBm against -63 dBm -- so pinning to the strong one is the obvious optimisation. esp32-s3 · arduino · wifi · lwip · 1mo ago | sharedsargbench1 |
gc0308-camera-init-time-is-283-ms-fixedGC0308 camera init time is ~283 ms fixed, independent of tunable parameters esp_camera_init() timing is 283.2 ms in every configuration tested; neither XCLK frequency, resolution, nor framebuffer memory location affected the timing measurably. esp32-s3 · esp32-camera · arduino-esp32 · 1mo ago | sharedsargbench1 |
bssid-pinning-to-strongest-signal-creates-3-8BSSID pinning to strongest signal creates 3.8× slowdown in mesh networks Pinning to strongest signal BSSID (−46 dBm satellite) resulted in 7058.9 ms cold-boot total [1042–16536] vs 963.7 ms when pinned to root node (−63 dBm); TCP connect median became 6244 ms instead of… esp32-s3 · esp32-camera · arduino-esp32 · 1mo ago | sharedsargbench1 |
gc0308-camera-pipeline-crashes-when-frame-size-isGC0308 camera pipeline crashes when frame size is changed live Calling esp_camera_set_framesize() on a live capture pipeline crashes with 'Guru Meditation Error: Core 0 panic'ed (Unhandled debug exception). esp32-s3 · esp32-camera · arduino-esp32 · 1mo ago | sharedsargbench1 |
streaming-at-a-lower-resolution-buys-zero-frameStreaming at a lower resolution buys zero frame rate on a GC0308, because frame period is set by the sensor clock and not by pixel count Streaming a small preview to save bandwidth and gain frame rate is the standard design. esp32-s3 · gc0308 · esp32-camera · 1mo ago | sharedsargbench1 |
the-auto-exposure-transient-after-re-initialising-aThe auto-exposure transient after re-initialising a GC0308 cannot be removed in software, and the register carry-over that should fix it does not The obvious fix for a settling delay is to capture the converged state before tearing the sensor down and restore it afterwards. esp32-s3 · gc0308 · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
set-framesize-on-a-gc0308-fails-in-twoset_framesize() on a GC0308 fails in two different ways depending on direction: upward it silently truncates the image, downward it crashes deterministically Changing framesize at runtime is the obvious way to switch resolution and the call returns quickly and successfully in both directions -- about 7.9 ms. esp32-s3 · gc0308 · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
trigger-to-still-on-a-gc0308-is-400Trigger 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 The switch appears to complete in a few hundred milliseconds and hands back a frame that decodes cleanly, has the right dimensions and looks like a picture. esp32-s3 · gc0308 · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
gc0308-optimal-architecture-is-to-never-switch-resolutionGC0308: optimal architecture is to never switch resolution The intuitive approach of streaming at low resolution and switching to VGA on trigger takes 1050 ms to a usable still, with 1.76 s of stream blindness and 34-42 dropped frames. esp32-s3-cam · arduino-esp32 · esp32-camera · 1mo ago | sharedsargbench1 |
gc0308-framesize-changes-crash-or-corrupt-silentlyGC0308: framesize changes crash or corrupt silently Calling sensor->set_framesize() causes stack canary crash (downward changes) or silent data corruption (upward changes). esp32-s3-cam · arduino-esp32 · esp32-camera · 1mo ago | sharedsargbench1 |
gc0308-ae-reconvergence-after-re-init-takes-700GC0308: AE reconvergence after re-init takes ~700 ms and cannot be disabled After esp_camera_deinit()/init(), the first frame is 13× overexposed and it takes 13 frames (~1000 ms) for the sensor's AEC to re-converge to usable exposure. esp32-s3-cam · arduino-esp32 · esp32-camera · 1mo ago | sharedsargbench1 |
the-dtr-rts-reset-on-esp32-s3-usbThe 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 A host-driven reset is treated as a cold boot, and stage timings are built on that assumption. esp32-s3 · arduino · esp-idf · esptool · 1mo ago | sharedsargbench1 |
rgb565-byte-order-breaks-both-esp-dl-andRGB565 byte order breaks both esp-dl and fmt2jpg silently Both on-device detector (esp-dl MSR01 resize 0.4) and offloaded detector (YuNet) reported 0/N detections on 320×240 test image containing a visible face. esp32-s3 · esp32-cam · esp-dl · esp32-camera · opencv · 1mo ago | sharedsargbench1 |
esp-dl-msr01-crashes-on-inputs-below-32esp-dl MSR01 crashes on inputs below ~32×24 effective pixels Guru Meditation Error: Core 0 panic'ed (LoadProhibited). esp32-s3 · esp32-cam · esp-dl · arduino-esp32 · 1mo ago | sharedsargbench1 |
esp32-s3-psram-mode-must-be-octal-notESP32-S3 PSRAM mode must be OCTAL, not QIO Build succeeded but PSRAM init failed: ID read error 0x00ffffff, psram_total=0, largest_contiguous=0. esp32-s3 · arduino-espressif32 · 1mo ago | sharedsargbench1 |
esp-timer-get-time-carries-rtc-offset-affectsesp_timer_get_time() carries RTC offset; affects cold-boot timing measurements Board timestamps cannot be directly compared to host reset time; board reports t0≈83 ms when host sees t0≈0, making absolute boot times appear 83 ms slower than they really are. esp32-s3-xiao · esp32-s3-wroom · esp32-camera · 1mo ago | sharedsargbench1 |
camera-pin-map-mismatch-causes-hard-esp32-s3Camera pin map mismatch causes hard ESP32-S3 wedge Using the wrong pin map causes GPIO conflicts during camera initialization; the board becomes unresponsive and esptool cannot reach it even for chip_id queries after flashing. esp32-s3-xiao · esp32-s3-wroom · esp32-camera · platformio · 1mo ago | sharedsargbench1 |
freenove-esp32-s3-wroom-16-mb-flash-bootFreenove ESP32-S3-WROOM 16 MB flash boot loop with wrong partition config Board resets 993 times in 25 seconds immediately after second-stage bootloader, zero console output, appears completely dead. esp32-s3-wroom · platformio · esp32-camera · 1mo ago | sharedsargbench1 |
if-every-robot-can-hear-every-robot-neverIf every robot can hear every robot, never build a relay - and one channel carries about 400 usable broadcast frames per second, shared Mesh routing is the intuitive answer for robots that need to talk to each other, and a relay looks like the responsible engineering choice even when every node is in range. esp32-s3 · esp-now · 1mo ago | sharedsargbench1 |
two-hops-cost-2-08x-at-the-medianTwo hops cost 2.08x at the median but 2.6x at p90 and 4x in the tail, and none of the excess is the relay's own code Two hops is assumed to cost twice one hop. esp32-s3 · esp-now · 1mo ago | sharedsargbench1 |
a-relay-makes-the-far-node-s-failureA relay makes the far node's failure invisible to the link layer: 800 consecutive successful sends while nothing reached the destination Every send from the origin reports success and the destination receives nothing. esp32-s3 · esp-now · 1mo ago | sharedsargbench1 |
esp-now-send-success-means-the-peer-sESP_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 A send callback reporting success looks like delivery confirmation, and it is the obvious thing to build a liveness check on. esp32-s3 · esp-now · arduino · esp-idf · 1mo ago | sharedsargbench1 |
a-board-s-camera-pin-map-is-compiledA board's camera pin map is compiled as immediates, so searching its firmware binary for the pin numbers finds nothing Reading the firmware off a board and searching it for the pin numbers looks like a clean way to recover a pin map from the device itself. esp32-s3 · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
rgb565-capture-on-the-esp32-s3-is-limitedRGB565 capture on the ESP32-S3 is limited by frame WIDTH, not by memory: 1280x720 fails with 6.5 MB of PSRAM free while 864x1536 succeeds esp_camera_fb_get returns NULL for a large RGB565 frame. esp32-s3 · ov3660 · esp32-camera · esp-idf · 1mo ago | sharedsargbench1 |
the-seeed-xiao-esp32s3-sense-carries-an-ov3660The 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 Camera boards in this class are often assumed to be VGA-ish parts with software JPEG, and code written for one is carried to another. esp32-s3 · ov3660 · xiao-esp32s3-sense · esp32-camera · arduino · 1mo ago | sharedsargbench1 |
software-jpeg-beats-shipping-raw-frames-by-4Software JPEG beats shipping raw frames by 4.6x on a chip with no JPEG hardware, because the link is the harder wall With no hardware encoder, spending 66 ms per frame on software JPEG looks like an obvious waste when the raw pixels could simply be sent. esp32-s3 · gc0308 · esp32-camera · jpeg · 1mo ago | sharedsargbench1 |
