---
title: "Home I-V Curve Tester"
date: "2026-07-19"
canonical: "https://raytally.com/en/ideas/2026-07-19-tech-note-making-your-own-v-i-plots-at-home/"
generator: "RayTally · dev-prompt-v4"
signal:
  query: "Tech note: making your own V-I plots at home"
  observed_at: "2026-07-19T01:33:02.331Z"
sources:
  - url: "https://lcamtuf.substack.com/p/tech-note-making-your-own-v-i-plots"
    boundary: "Published at 2026-07-17T00:00:00.000Z. Observed at 2026-07-19T01:33:02.331Z."
  - url: "https://files.digilent.com/manuals/WaveForms/3.24.3/tracer.html"
    boundary: "No publication timestamp is present in the source record."
  - url: "https://wicg.github.io/serial/"
    boundary: "Published at 2026-06-02T00:00:00.000Z."
  - url: "https://www.tek.com/en/documents/product-article/keithley-low-level-measurements-handbook---7th-edition"
    boundary: "No publication timestamp is present in the source record."
notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief."
---

[Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-07-19-tech-note-making-your-own-v-i-plots-at-home/)

Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting.

You are a senior product engineer. Turn the product idea below into a locally runnable MVP.

## Idea

Home I-V Curve Tester
Connect a component to a low-voltage home test box to view its I-V curve in real time, with knee-point detection and warnings about possible wiring errors.

## Product concept

An electronics hobbyist connects a diode, resistor, or solar cell to a low-voltage acquisition box and selects a safe test range; the web app then plots the voltage-current curve in real time. As the trace is generated, it marks knees, polarity, and possible wiring faults. After the test, ambient temperature, a component photo, and the measurements are packaged into an experiment record. When the same component is tested again, users can compare the curves directly instead of keeping only a screenshot.

## Why now (backed by facts)

During the July 17-19 Hacker News observation window, this technical note on making V-I curves at home received 64 points, 10 comments, and ranked 16th. This was only one concentrated discussion, but it surfaced the home-experiment moment where real curves are hard to capture and the manual workflow is fragmented.

## Direction (model inference, not independently verified)

Target user: People learning electronics at home, screening loose components, or checking solar-cell degradation would open it just after wiring a breadboard to confirm polarity and the conduction region. They would also use historical curves after swapping a component, changing a circuit, or retesting later to judge whether a change comes from the component, temperature, or wiring.

Minimal entry point: Start with two-terminal components such as diodes, LEDs, and small solar cells: limited-voltage sweeps, live I-V plots, polarity guidance, overcurrent shutdown, and two-curve overlays. The acquisition box sends timestamped voltage, current, and temperature data over USB serial; supported browsers can read from and write to serial devices directly through the Web Serial API.

The strongest case against: The hard part is not drawing sample points as a line, but making the excitation range, current limiting, calibration, contact resistance, and temperature conditions reliable enough to trust. Without clear confidence bounds, a low-cost box’s fault warnings can easily mistake poor probe contact, ADC noise, or self-heating drift for component failure. Its measurement range also limits the devices and operating regions it can cover, so the boundary between an educational demonstration and a measurement instrument must be explicit.

These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty.

## Punching above weight (model inference)

Open-source the acquisition-box firmware and communication protocol, along with several reproducible experiment datasets. Publish measured-curve pages for components of the same model on GitHub, electronics maker forums, and component-review articles. Keep a hardware list and importable data with every public record, encouraging people who already have an Arduino, breadboard, and bench supply to reproduce and share tests.

## Competitors & gaps (model inference)

- Digilent Analog Discovery + WaveForms Curve Tracer: It already measures diodes and transistors, exports data, and saves a current trace as a reference curve. The opportunity is not to redraw the plot, but to organize temperature, component photos, wiring diagnostics, and repeated measurements into a home-lab record.
- Keithley SourceMeter / I-V Tracer: SMUs can source and measure voltage and current simultaneously and are the standard professional approach to I-V characterization. A home product can only trade laboratory-grade capability for simpler wiring and record-keeping within low-voltage, limited-accuracy, clearly protected operating ranges; it cannot claim to replace laboratory instruments.
- Multimeter + Bench Power Supply + SCPI Scripts: Bench multimeters, laboratory power supplies, and SCPI scripts can produce real curves, but setup, instrument control, temperature-drift handling, and data organization are fragmented. The opportunity is to bring those steps into fixed hardware and a repeatable test workflow.

## How it makes money (model inference)

Sell a low-voltage acquisition box with a calibration component and connection protection as a one-time purchase. Basic web plotting and local storage are free; cross-device sync, batch comparison, and report export are available by annual subscription.

## Source context

Theme: Home I-V curve testing
Trigger Hacker News post (original English): Tech note: making your own V-I plots at home
Heat at capture: ~64 points, 10 comments (point-in-time values)

Points and comments are a historical snapshot from the moment of capture and drift over time. They only explain “why now”; do not present them as precise market numbers.

## Sources

- Tech note: making your own V-I plots at home (https://lcamtuf.substack.com/p/tech-note-making-your-own-v-i-plots)
- WaveForms Curve Tracer (https://files.digilent.com/manuals/WaveForms/3.24.3/tracer.html)
- Web Serial API (https://wicg.github.io/serial/)
- Keithley Low Level Measurements Handbook - 7th Edition (https://www.tek.com/en/documents/product-article/keithley-low-level-measurements-handbook---7th-edition)

## Deliverables

- Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery.
- Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary.
- Do not show unverified market numbers in the UI or API.
- Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge.
- If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code.
- If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype.
- When done, explain what changed, how to run it, and how to verify it.
- Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.
