Interesting. Not clear what it really does. The hardware is an oscilloscope probe on a 3-axis CNC mechanism. That's called a "flying probe", and you can buy one.[1]

Fine. But what does the AI do? It "ingests the project", but what does that mean? Finding all the pins? That's a start. Using a SPICE model to figure out what should be on each pin, and checking? Now that would be impressive. Probably something in between.

The usual use for this sort of thing is that you probe a known-good board to find out what voltages and signals appear where, and then compare with newly manufactured boards. That's a common production check.

There's potential here. If the AI has some concept of what the board under test is doing, and can diagnose problems, that's quite useful.

[1] https://huntron.com/products/access2.htm

It’s hard to imagine anyone wanting this to be real more than I do, but this is nowhere close to being ready to do actual work. Photographing real PCBs is hard, there is no fiducial maths, no actual probing is being done. It's just photos of a photo being piped into an agent. If it actually did what it claims, no reasonable person would exclude it from the demo video.

https://gainsec.com/2026/04/16/autoprober/

I watched the linked in video:

https://videos.files.wordpress.com/gD3kAWlO/autoprober-demo....

But I am not sure what do I see there? Is that some 3D printing?

Can't say I fully understand it but this certainly smells like someone is getting hired off a single github repo as CV

Cool demo, but letting an AI Agent drive a physical probe may have problems. AI is probabilistic, but hardware is precise. If the model miscalculates a pin's position by even 0.1mm, the probe may crush the board. I am curious how the author actually bridges the gap between the Agent’s 'guess' and the sub-millimeter precision needed to avoid damaging hardware?

It's both cool and a bit confusing. Is this an attempt to commoditize flying-probe testing for PCBs? An attempt to use LLMs to reverse-engineer circuits? Both?

It almost feels like it would benefit from being split into two projects. If I'm testing my own PCBs, I probably don't want an agent in charge, at least not routinely. There's just no reason for the added cost, complexity, or non-determinism. And if I'm reversing someone else's design, then going through the effort of building an auto-prober seems like an overkill, especially since a single probe is seldom enough. Even the simplest serial interface will often have one line for clock and another for data, so you're gonna be manually making connections either way.

Would be cool if you could use this (with 2 probes) to build a wiring net for reverse engineering.

> digitally guided fabrication

> New York[1]

[1] https://www.governor.ny.gov/news/keeping-new-yorkers-safe-go...

Guy builds car from stick of gum, paperclip, and an old vehicle

Same guy who made the Flock hacking tool

I figured this was some kind of home-grown prosthetic arm whose wearer could, using AI, draw any artwork online, speak ASL, perform minor surgery on themselves and so much more so long as their supply of tokens lasted.

Perhaps a smidge disappointed when I had a look and discovered it wasn't that :)

Maybe put the probe on a spring loaded linear sensor, and move down until it hits a target offset (could just be read by a simple flag in an optical sensor)-- resulting in hitting a constant target force.

This is amazing! Limitation breeds creativity indeed

How does this only have a single star.

This is genuinely mind blowing.

Wow that's nuts. What a great idea! I wonder how much of this the commercial flying probe machines can do already. Pretty cool to be able to have this on a home scale.

Interesting. Not clear what it really does. The hardware is an oscilloscope probe on a 3-axis CNC mechanism. That's called a "flying probe", and you can buy one.[1]

There's potential here. If the AI has some concept of what the board under test is doing, and can diagnose problems, that's quite useful.

[1] https://huntron.com/products/access2.htm

I think the novel idea here is you jam some hardware together (whatever you like) that can do "physical real world" things with a well understood interface and then spin up Claude with access to it.

The way I'm thinking about it is, it's a _workflow_ innovation?

So you ask for data sheets for all the visible chips and get PDFs in an output directory with minimal user interaction except to flip the board, ask for a basic idea of connectivity, get a stitched high res surface image etc.... which of course are all currently possible, but you can do them potentially with very low effort. There doesn't have to be a _software stack_ ahead of time. You ask Claude to do the thing, it will figure out how to do it, write some code, pull in some OSS and make the thing happen. You can take this project's software or leave it.

You might say "tell me where you think the JTAG headers are" and it will come up with a workflow to do its best at that task (most likely with variable results...), but nonetheless this is not a thing you can ask of any commercial product I am aware of today. With probes, stuff can get interesting.

Of course experienced hardware & reverse engineers already can do all this stuff and have a plethora of workflows for it but I still think it's an interesting POC of a generalisable approach. You can take or leave this particular software stack. Also, the hardware barely matters, you can duct tape whatever to whatever.

From my understanding is you’d probe the board during different operations, process the results and deduct what signals are useful and traffic transmitting across the board (I.E private keys, what protocols are used, debug interfaces, firmware components, chip functions, etc).

feels like the author is hallucinating an instant solution to a problem with scope size of "research team and five years" class

I believe the standard production check is more like you check continuity between known nets, given that you're the manufacturer, you already know where they are exposed, and therefore you can perform those checks before adding any components. Post component checks are a lot more complicated because active components and passive components will modify the visible voltages and characteristics, often to the point where you won't have the same degree of physical insight.

I would assume once machines are set up that this is only really done if you're not confident of your manufacturing line for some reason (eg. maintenance, reconfiguration) or you are pushing limits somewhere, for example, particularly small vias or traces very close to the edge of the board.

To make this useful, you would want two flying probes because otherwise it's not going to be telling you much you don't already know.

I think the novel idea here is you jam some hardware together (whatever you like) that can do "physical real world" things with a well understood interface and then spin up Claude with access to it.

The way I'm thinking about it is, it's a _workflow_ innovation?

It's lower level than that. "It will probe the approved targets and report back." It has enough smarts to find the pins, and maybe it can read the text labels on some ICs, but that's about it. That eliminates much drudgery, though. And probably the job of some tech who did that by hand.

It's both cool and a bit confusing. Is this an attempt to commoditize flying-probe testing for PCBs? An attempt to use LLMs to reverse-engineer circuits? Both?

Would be cool if you could use this (with 2 probes) to build a wiring net for reverse engineering.

Same guy who made the Flock hacking tool

I watched the linked in video:

https://videos.files.wordpress.com/gD3kAWlO/autoprober-demo....

But I am not sure what do I see there? Is that some 3D printing?

I think this is roughly solved. Tell the agent to do all of its calculations in python.

https://gainsec.com/2026/04/16/autoprober/

Can't say I fully understand it but this certainly smells like someone is getting hired off a single github repo as CV

Guy builds car from stick of gum, paperclip, and an old vehicle

Perhaps a smidge disappointed when I had a look and discovered it wasn't that :)

> digitally guided fabrication

> New York[1]

[1] https://www.governor.ny.gov/news/keeping-new-yorkers-safe-go...

Wow that's nuts. What a great idea! I wonder how much of this the commercial flying probe machines can do already. Pretty cool to be able to have this on a home scale.

This is amazing! Limitation breeds creativity indeed

feels like the author is hallucinating an instant solution to a problem with scope size of "research team and five years" class

Could an agent no develop a bespoke correction algorithm for the photos of the photo?

> someone is getting hired off a single github repo as CV

Isn't that a good thing?

Nowadays the former seems to be a requirement for the latter, so I'm inclined to agree with you

How does this only have a single star.

This is genuinely mind blowing.

first release 18hrs ago...

To make this useful, you would want two flying probes because otherwise it's not going to be telling you much you don't already know.

That's a blank board test. This is straightforward given the netlist and Gerber files.[1] It's just a continuity check between known points. Does not require AI.

[1] https://bayareacircuits.com/bare-printed-circuit-board-elect...

I think this is roughly solved. Tell the agent to do all of its calculations in python.

That's a blank board test. This is straightforward given the netlist and Gerber files.[1] It's just a continuity check between known points. Does not require AI.

[1] https://bayareacircuits.com/bare-printed-circuit-board-elect...

first release 18hrs ago...

> someone is getting hired off a single github repo as CV

Isn't that a good thing?

Nowadays the former seems to be a requirement for the latter, so I'm inclined to agree with you

Could an agent no develop a bespoke correction algorithm for the photos of the photo?

Why feed it photos of a photo when you could just feed it the photo that was printed out?

AutoProber

AutoProber is the hardware hacker's flying probe automation stack for giving your agent everything it needs to go from "there's a new target on the plate" to probing individual pins in a safe way.

AutoProber assembly

Demo video: https://gainsec.com/autoprober-demo-mp4/

Flow

Tell the agent to ingest the project.
Connect all the hardware.
Tell the agent to confirm that all parts are functioning.

Top of the AutoProber web dashboard

Have it run homing and then calibration.
Attach the custom probe and microscope header.
Tell the agent that there is a new target on the plate.
It will find where the target is on the plate, then take individual frames, keeping a record of the XYZ while noting pads, pins, chips, and other interesting features.

Detected labels and target features

It will stitch the frames together and annotate the map, including pins and interesting components it identified.

Annotated map view

It will add probe targets to the web dashboard for you to approve or deny.

Probe review dashboard section

It will probe the approved targets and report back.

All hardware can be controlled through the web dashboard, Python scripts, or by the agent itself.

Manual controls and hardware panels

This repo is a self-contained source-available release candidate. It contains the Python control code, dashboard, CAD files, and documentation needed to create your own AutoProber.

Safety Model

This project can move physical hardware. Treat it as a machine-control system, not a normal web app.

The required safety design is:

GRBL Pn:P is ignored. The CNC probe pin is not a trusted endstop.
The independent safety endstop is read from oscilloscope Channel 4.
Channel 4 must be continuously monitored during any motion.
Any Channel 4 trigger, ambiguous voltage, CNC alarm, or real X/Y/Z limit pin is a stop condition.
The agent/operator must stop and report. Recovery motion is not automatic.

Read docs/safety.md and docs/operations.md before running hardware.

Repository Layout

apps/                 Operator-facing scripts and Flask dashboard entrypoint
autoprober/           Reusable Python package for CNC, scope, microscope, logging, safety
dashboard/            Single-page web dashboard
docs/                 Architecture, device references, operations, and safety guidance
cad/                  Printable STL files for the current custom toolhead
config/               Example environment/configuration files
AGENTS.md             Agent/operator safety rules
LICENSE               PolyForm Noncommercial 1.0.0 license and commercial contact
pyproject.toml        Python project metadata
uv.lock               Locked Python dependency resolution

Hardware Stack

The tested project architecture uses:

GRBL-compatible 3018-style CNC controller over USB serial
USB microscope served by mjpg_streamer
Siglent oscilloscope over LAN/SCPI for Channel 4 safety monitoring and Channel 1 measurement
Optical endstop wired to an external 5V supply and oscilloscope Channel 4
Optional network-controlled outlet for lab power control
Current printable custom toolhead parts in cad/

Default runtime assumptions are documented in the device docs. Replace them with your own lab settings before use.

For a shopping-oriented hardware list, see docs/BOM.md.

Reference Parts

These are the specific parts or part classes used for the prototype release. Verify current listings, dimensions, voltage, and connector compatibility before buying.

My build:

Optical End Stop
USB Microscope
SainSmart Genmitsu 3018-PROVer V2
Matter Smart Power Strip, individually controlled AC outlets with 2 USB-A and 2 USB-C ports
Siglent SDS1104X-E Oscilloscope
Dupont wires
Pen spring or similar light compression spring
3D printer for the printable toolhead parts in cad/

Optional / interchangeable:

Universal Oscilloscope Probes
USB power brick, 5V
USB 2.0 pigtail cable

Hardware Architecture

flowchart LR
    Operator[Operator] --> Dashboard[Web Dashboard]
    Dashboard --> Apps[Python Apps]
    Apps --> CNC[GRBL CNC over USB serial]
    Apps --> Microscope[USB Microscope via mjpg-streamer]
    Apps --> Scope[Oscilloscope over LAN / SCPI]
    Apps --> Outlet[Optional LAN Power Outlet]

    Endstop[Optical Endstop] --> ScopeC4[Scope C4 Safety Voltage]
    Pogo[Pogo Measurement] --> ScopeC1[Scope C1 Measurement]
    ScopeC4 --> Apps
    ScopeC1 --> Apps

Runtime Architecture

flowchart TD
    Preflight[Preflight] --> SafetyCheck{Channel 4 clear?}
    SafetyCheck -- no --> Stop[STOP State]
    SafetyCheck -- yes --> Motion[Monitored Motion]
    Motion --> Monitor[EndstopMonitor thread >= 10 Hz]
    Monitor --> C4{C4 clear?}
    C4 -- yes --> Capture[Microscope Capture]
    C4 -- no --> FeedHold[Immediate feed hold]
    FeedHold --> Stop
    Capture --> Stitch[Stitch / Map]
    Stitch --> Review[Manual Probe Review]
    Review --> Approved{Approved target and measured probe offset?}
    Approved -- no --> Stop
    Approved -- yes --> Probe[Bounded probe motion]

STOP State

stateDiagram-v2
    [*] --> Running
    Running --> STOP: C4 triggered / C4 fault / CNC alarm / real limit pin
    STOP --> Report: log voltage, status, action
    Report --> WaitForOperator: no automatic recovery motion
    WaitForOperator --> Running: operator explicitly clears condition

Quick Start

Install dependencies:

uv sync

Start the dashboard on a configured hardware host:

PYTHONPATH=. python3 apps/dashboard.py

The dashboard defaults to port 5000.

Configuration

Start from config/autoprober.example.env. Do not publish lab-specific IPs, hostnames, credentials, calibration files, or captured target images unless you intend to release them.

Important runtime values are configurable:

AUTOPROBER_LOG_PATH: runtime log path
AUTOPROBER_RUNTIME_ROOT: calibration, flat-field, and runtime state directory
AUTOPROBER_MICROSCOPE_SNAPSHOT_URL: microscope snapshot endpoint
AUTOPROBER_SCOPE_HOST / AUTOPROBER_SCOPE_PORT: oscilloscope SCPI endpoint
Dashboard: Flask on port 5000

Do not commit local environment files that contain lab-specific hosts, paths, or target data.

Main Workflows

Run preflight checks.
Verify Channel 4 is clear.
Home and calibrate only when the physical setup is ready.
Capture microscope frames with monitored motion.
Import or generate target map artifacts for review.
Approve probe candidates manually.
Execute any probe motion only after microscope-to-probe offset is measured and stored.

What Is Excluded

This release candidate intentionally excludes:

Trial microscope captures and stitched target images
Uploaded reference images
Local backups and archives
.venv, __pycache__, Playwright artifacts
Runtime logs, calibration cache, flat-field images
Machine-specific SSH/deploy state

See RELEASE_MANIFEST.md for details.

License

This project is source-available under the PolyForm Noncommercial License 1.0.0.

You may use, modify, and share this project for noncommercial purposes.

Commercial use requires a separate paid commercial license.

For commercial licensing, contact: autoprober@gainsecmail.com

Current Limitations

The microscope-to-pogo XY offset must be measured before real probing.
Calibration must not be fabricated; the runtime calibration file should be generated on the machine that will move.
The dashboard is a lab-control tool and should not be exposed to untrusted networks.

Responsible Use

This project is intended for controlled lab work on equipment and targets you are authorized to test. Do not use it to probe, damage, or analyze systems without permission.

Authors

Jon 'GainSec' Gaines