Skip to content

The Lab

Experiments, notes, and works in progress

The Lab is where Didur Labs documents experiments, prototypes, technical investigations, and ideas still under development. Not every experiment becomes a product, but every experiment produces useful knowledge.

  • Build log
  • Engineering note
  • Prototype update
  • Failure analysis
  • Bench test
  • Teardown
  • CAD experiment
  • Firmware experiment
  • Home Assistant integration
  • AI agent research
  • Hardware comparison
  • Bench testIn progress

    ESP32-S3 Deep-Sleep Current on the Bench

    Measuring real-world deep-sleep current on a few ESP32-S3 modules to see which are actually viable for battery-powered sensors.

    Read notes →

    Datasheet deep-sleep numbers and bench reality are rarely the same thing. Regulators, onboard LEDs, and USB-to-serial chips often dominate the current budget long before the SoC does.

    The current setup logs sleep current across a handful of common modules under the same firmware and wake schedule. Early observations line up with the usual advice—board-level components matter more than the chip—but the intent is to have our own numbers rather than repeat folklore.

    Next step is to strip the power LEDs and idle peripherals on the worst offenders and re-measure. No conclusions yet; this note exists mostly to record method so the results are comparable later.

  • AI agent researchOngoing

    Scoping Local LLM Camera Event Summaries

    Testing how small, locally hosted models handle turning camera object-detection events into short, useful notifications.

    Read notes →

    The goal is a summary that reads like a sentence a person would send, not a dump of bounding-box labels. The interesting constraint is doing it locally, on modest hardware, without shipping footage to a cloud service.

    So far the most reliable results come from keeping the model’s job narrow: it summarizes structured detection data plus a little context, rather than interpreting raw frames. Tightly scoped prompts beat clever open-ended ones for consistency.

    Open questions: how to handle strings of related events without spamming, and where the quality-versus-latency line sits on local hardware. This is research, not a shipped feature.

  • CAD experimentOngoing

    Parametric Gridfinity Holders for Bench Instruments

    A parametric Fusion approach for generating Gridfinity holders that fit specific tools and instruments without redrawing from scratch.

    Read notes →

    Gridfinity solves the grid, but each tool still needs its own pocket. Modeling every holder by hand does not scale, so this experiment is about a parametric model where a few measurements produce a printable holder.

    The current model handles simple prismatic tools well. Odd shapes—things with cables, curves, or awkward centers of gravity—still need manual attention, which is fine; the point is to remove the repetitive cases, not every case.

    Ongoing as new tools arrive. Each one is a test of whether the parametric model covers it or needs another input.

  • Engineering notePaused

    Probing an Undocumented RS-485 Bus

    Notes from reverse-engineering the serial chatter on a piece of older equipment with no available protocol documentation.

    Read notes →

    The equipment clearly talks over RS-485, but nobody has the protocol. This is a patient listening exercise: capture traffic, look for framing and polling patterns, and correlate messages with physical actions.

    Progress so far is partial. Some periodic frames look like status polling, and a few appear to correlate with state changes, but plenty is still unexplained. Reverse engineering rewards patience over cleverness.

    Paused pending more capture time on the equipment. Recording here mainly so the partial findings and captures are not lost before the work resumes.

  • Failure analysisConcluded

    A Relay Board That Ran Too Hot

    A prototype relay board ran warmer than expected. Short write-up of what went wrong and what changed.

    Read notes →

    A prototype controller’s relay section got hot enough under sustained load to be a concern. Worth documenting, because the failure was ordinary and avoidable—exactly the kind that repeats if it is not written down.

    The causes were unremarkable: trace widths sized for average rather than sustained current, relays packed too close for airflow, and no thermal margin for a warm enclosure. Nothing exotic, just optimistic assumptions.

    The fix for the next revision is wider traces and copper pours on the switched paths, more spacing between relays, and derating parts for the enclosure’s real temperature rather than open bench air. Concluded, and folded into the checklist for future boards.

These entries are intentionally informal and in-progress. They document method and reasoning as much as results—so the useful knowledge survives even when an experiment does not become a product.