It’s finally here! I finally got around to mounting and testing it.

About 3 months ago I started this as a side project, another HAT for the BugBuster app. Some of you might remember the earlier posts about the Logic Analyzer, this time it’s a Power Analyzer.

I've now started to fully test the performance of the AFE and I could not be happier, it reaches 50nA of noise at 1ksps and we get 115nA of noise at 64ksps, also the thermal impact of noise is marginal and this is with a 5V output so i expect lower noise at lower outputs.

The device has been build for IOT and AI development, it offers an MCP to allow Claude to interface with the hardware so it can iterate on your IOT device measuring the consumption with a fantastic resolution and is all fully opensource.

Main features so far:

• Analog autoranging across 51Ω, 2Ω, and 0.05Ω shunts with ~500 ns response
• 115 kHz bandwidth with full 24-bit resolution
• Dual-ADC sampling, so no gaps while the fine ADC switches ranges
• Measured ~0.5 µA accuracy and 0.2 nA resolution at 8 ksps, or ~2 µA accuracy at full speed (still waiting to validate properly in a standards lab atm validated against 7 1/2 digits keysight meter)
• Temperature-based calibration, plus SMU-style calibration with programmable voltage/current (7-bit each)
• Output voltage sensing with optional sense wires
• Onboard display for control and health monitoring
• 12-channel flag system (trigger up to 5 V) or 4 channels up to ±12 V
• Onboard DSP pipeline for FFT and power metrics
• Integrated PSU: 1.8 V to 20 V, up to 2.5 A continuous

I’m fully aware there are commercial tools out there that would absolutely destroy this thing. That wasn’t really the point, this was an experiment. I’m very comfortable with digital design, but precision analog is a different beast entirely, and I learned a lot in the past month. When you start chasing low leakage, everything matters. Touch the wrong trace once and you’ve got a nice extra 300 nA offset for free.

As with my previous projects, this is fully open source (hardware + software). I’ve had people ask if I’d sell boards, but I’m sticking to sharing the files instead. If you want to build one, feel free to reach out, I’m happy to help with BOM quirks or bring-up.

Repo:https://github.com/lollokara/BugBuster

It's all for free and AGPL licensed so feel free to do whatever you'd like with it.

PCBs were provided for free by JLCPCB using the JLCONE app, and I could not be happier with the quality of them.

Ever wanted to be able to check your low power device current consumption on the go? Yeah me neither. Hence why I created an app for it.

Is still very rough but it gives you an idea. It’s using the ESP32P4 module with an ESP32-C6 embedded in it, the commands stack goes thru BLE (Controlled by the main board with ESP32-S3) while the WiFi bridge (C6) is reserved for the streaming. I’m quite surprised by the amount of data the IPad can handle (gen 3 iPad Pro is quite old for today’s standards).

The screen and WiFi bridge is operated by the C6 while the P4 does data crunching ingesting 512000 24Bit samples each second and processing them using the build in DSP before decimating them and sending them out to the end device.
Via USB it supports up to 256KSps while via WiFi we reach 32Ksps. Decimated data gets "partially" reconstructed at the endpoint.

The different colors in the current trace are due to the ranges, orange is the coarse range and blue is the fine range. Is a dual sampling system so no data is lost during autoranging.

Noisefloor of the device is +- 0.5 uA with 1nA resolution and I’m quite happy with it. It’s been an experiment so far.
The purpose of it is to embed it in the MCP toolsets that the BugBuster system has to allow AI agents to close the loop on real hardware and perform low power measurements, this is quite useful if you want the agent to be able to iterate on some firmware work to optimize consumption.

It’s all fully open source and open hardware https://github.com/lollokara/BugBuster
This has been my personal side project and I’m not selling it, if you’d like files are in the repo I can help with supplying the components.
PCBs were provided for free by JLCPCB using the JLCONE app, and I could not be happier with the quality of them.

Ever wanted to be able to check your low power device current consumption on the go? Yeah me neither.
Hence why I created an app for it.

Is still very rough but it gives you an idea. It’s using the ESP32P4 module with an ESP32-C6 embedded in it, the commands stack goes thru BLE while the WiFi bridge is reserved for the streaming. I’m quite surprised by the amount of data the IPad can handle (gen 3 iPad Pro is quite old for today’s standards).

The different colors in the current trace are due to the ranges, orange is the coarse range and blue is the fine range. Is a dual sampling system so no data is lost during autoranging.

Noisefloor of the device is +- 0.5 uA with 1nA resolution and I’m quite happy with it. It’s been an experiment so far.
The purpose of it is to embed it in the MCP toolsets that the BugBuster system has to allow AI agents to close the loop on real hardware and perform low power measurements, this is quite useful if you want the agent to be able to iterate on some firmware work to optimize consumption.

It’s all fully open source and open hardware https://github.com/lollokara/BugBuster
This has been my personal side project and I’m not selling it, if you’d like files are in the repo I can help with supplying the components.
PCBs were provided for free by JLCPCB using the JLCONE app, and I could not be happier with the quality of them.

It’s finally here! I finally got around to mounting and testing it.

About a month ago I started this as a side project, another HAT for the BugBuster app. Some of you might remember the earlier posts about the Logic Analyzer, this time it’s a Power Analyzer.

Main features so far:

• Analog autoranging across 51Ω, 2Ω, and 0.05Ω shunts with ~500 ns response
• 115 kHz bandwidth with full 24-bit resolution
• Dual-ADC sampling, so no gaps while the fine ADC switches ranges
• Measured ~0.5 µA accuracy and 0.2 nA resolution at 8 ksps, or ~2 µA accuracy at full speed (still waiting to validate properly in a standards lab atm validated against 7 1/2 digits keysight meter)
• Temperature-based calibration, plus SMU-style calibration with programmable voltage/current (7-bit each)
• Output voltage sensing with optional sense wires
• Onboard display for control and health monitoring
• 12-channel flag system (trigger up to 5 V) or 4 channels up to ±12 V
• Onboard DSP pipeline for FFT and power metrics
• Integrated PSU: 1.8 V to 20 V, up to 2.5 A continuous

I’m fully aware there are commercial tools out there that would absolutely destroy this thing. That wasn’t really the point, this was an experiment. I’m very comfortable with digital design, but precision analog is a different beast entirely, and I learned a lot in the past month. When you start chasing low leakage, everything matters. Touch the wrong trace once and you’ve got a nice extra 300 nA offset for free.

The system is built around the ESP32-P4. I spent quite a while looking for something that could handle the data throughput, and this ended up being a good fit. One core handles acquisition, the other does packetization and USB transfer. The onboard C6 (that comes with the module) drives the display, so the P4 stays fully dedicated.

As with my previous projects, this is fully open source (hardware + software). I’ve had people ask if I’d sell boards, but I’m sticking to sharing the files instead. If you want to build one, feel free to reach out, I’m happy to help with BOM quirks or bring-up.

Repo:https://github.com/lollokara/BugBuster
The HAT PCBs where provided by JLC PCB for free to show their support for the opensource community.

Hello boys and girls 👋

Long story short: I went to the dumpster to throw out some electronics… and left carrying home a fiber laser someone had chucked in the trash pile. The guy running the place was more than happy to see it go, so I didn't hang around to let him reconsider straight into the car it went.

Got it home, cracked it open, but had no docs, nothing. I dug around online and found some docs hinting at an RS-232 interface, but no matter what I threw at it, the thing stayed dead silent.

So I went the hardcore route:

•  Dumped the firmware straight off the MCU via JTAG
•  Decompiled it
•  Reconstructed the UART protocol from the disassembly

…and now I technically have "control" over it. Air quotes very much intended, because nothing actually works yet.

Here's the wall I've hit: a status request ($4) comes back as status 32 (0x20), which the V2 docs say is a Housekeeping supply error — except this laser doesn't even have that hardware. 🤨 So it's clearly something else masquerading behind that code.

The catch: that status byte is decoded from a packet coming off the onboard Altera FPGA, and reversing that is a whole different beast than the MCU was.

So I'm throwing this to the hive mind: is anyone here up for helping me decode this slab of black magic and aluminum? This is genuinely my last-ditch effort before I give up and strip it for parts.

All my work + sources so far are here if anyone wants to poke at it:
👉 https://github.com/lollokara/Laserone

Cheers, and thanks again!

Hello boys and girls 👋

Long story short: I went to the dumpster to throw out some electronics… and left carrying home a fiber laser someone had chucked in the trash pile. The guy running the place was more than happy to see it go, so I didn't hang around to let him reconsider straight into the car it went.

Got it home, cracked it open, but had no docs, nothing. I dug around online and found some docs hinting at an RS-232 interface, but no matter what I threw at it, the thing stayed dead silent.

So I went the hardcore route:

•  Dumped the firmware straight off the MCU via JTAG
•  Decompiled it
•  Reconstructed the UART protocol from the disassembly

…and now I technically have "control" over it. Air quotes very much intended, because nothing actually works yet.

Here's the wall I've hit: a status request ($4) comes back as status 32 (0x20), which the V2 docs say is a Housekeeping supply error — except this laser doesn't even have that hardware. 🤨 So it's clearly something else masquerading behind that code.

The catch: that status byte is decoded from a packet coming off the onboard Altera FPGA, and reversing that is a whole different beast than the MCU was.

So I'm throwing this to the hive mind: is anyone here up for helping me decode this slab of black magic and aluminum? This is genuinely my last-ditch effort before I give up and strip it for parts.

All my work + sources so far are here if anyone wants to poke at it:
👉 https://github.com/lollokara/Laserone

Cheers, and thanks again!

Hello boys and girls, long story short I’ve gone to the dumpster to get rid of some electronics and found this beauty in the trash pile, now, interestingly enough the guy managing the place was happy with me taking it so I haven’t wasted any time and proceeded to get the damn thing in the car.

I’ve opened it up, I have 0 documentation on the thing, found some docs online that steered me in a direction of how to use the RS232 on the thing but was not able to get any response, decided to go the hardcore route and dumped the firmware of the MCU via JTAG, decompiled it and reconstructed the uart protocol now I have “control over it” and every function is not working cause I have an error (I believe), the status request $4 comes back with status 32 (0x20) that according to the V2 documentation is a HouseKeeping supply error that this laser does not have (?!) so must be something else, problem is that the error is decoded from a packet that comes from the Altera FPGA onboard and reversing that would not be as easy.
So I’m asking if anyone here is willing to help me in understanding this piece of black magic and aluminum.

This is my last effort before stripping the thing to parts…
UPDATE:
Thanks for all the support, i was able to find few issues with it, i'm still not able to operate the damn thing but i'm getting closer and closer.
Here all the sources so far. https://github.com/lollokara/Laserone

Thanks for all the support !

I've been building a power analyzer HAT for BugBuster, an open bench instrument I've been working on that already does logic analysis, SWD debug, ADC/DAC, and GPIO over USB. (the whole thing is completely open source and hardware)

The HAT adds dedicated power profiling, 80nA to 2.5A with seamless hardware autorange. The existing MCP server already let AI assistants drive the rest of the tool, so wiring the new HAT into that made sense.

Last week I used it to debug a sleep current regression in an nRF52 project. Device was supposed to draw ~4µA in sleep and was drawing 340µA instead. Classic "something didn't turn off" situation. Normally I'd spend 20 minutes on it manually, toggling peripherals, reading registers, re-flashing, remeasuring and iterate.

The entire scope of this series of HATs and devices is to allow the AI to be able to close the loop with the hardware, giving the model a way to measure and interface with actual hardware.

I has GPIOs that can toggled by firmware right before the sleep call, wired into one of BugBuster's flag inputs. Those get timestamped and correlated to the current trace sample index. So the AI could see exactly where the firmware thought it went to sleep vs where the current actually dropped.

One good prompt later Claude was able to pinpoint the issue to an incorrect settings over some GPIOs that were left initializated hence the high consumption.

The on hardware side: three 24-bit ADAQ7769-1 sigma-delta ADCs reading a 51R/2R/50mR shunt ladder, the analog chain is build for 110Khz bandwith at max resolution or 290Khz at reduced resolution. Analog comparators handle the range switching, no firmware latency involved, one fine one coarse ADC run on the shunt network so you don't lose samples due to a ranging operation, from deep sleep through a TX burst in one capture. An ESP32-P4 on the HAT runs power/energy DSP on-device so the AI gets a useful summary rather than raw 250k samples/sec.

The AI could go from capture to marker analysis to register readout to fix in one sequence without me being the middleman between tools.

Still needs some work, i'm ordering the PCBs this week. Hopefully no major issues arise.
Project is fully available here https://github.com/lollokara/BugBuster

AI Disclaimer, yes AI was used to develop parts of this, I would not call it a vibecoded tool, I've put my fare share of efforts in it. I'm a solo dev and this is not my full time job, is something I've developed because I see AI as an accelerator for human progress, but having an accelerator running in open loop can only result in drifting.

I've been building a power analyzer HAT for BugBuster, an open bench instrument (fully open source, hardware included) that already does logic analysis, SWD debug, ADC/DAC, and GPIO over USB.

The HAT adds dedicated power profiling: 80nA to 2.5A with seamless hardware autorange. The existing MCP server already lets AI assistants drive the rest of the tool, so wiring the new HAT into that made sense. The whole point of the ecosystem is to let the AI close the loop with actual hardware, not just generate code in a vacuum.

The P4 is the brain of the HAT. Dual-core 400MHz with 32MB PSRAM makes it genuinely useful for this kind of work. Three 24-bit ADAQ7769-1 sigma-delta ADCs feed into it over two dedicated SPI buses at up to 250kSPS. The PSRAM acts as a deep ring buffer so you never drop samples even when the DSP pipeline is busy. The P4 runs all the power and energy math on-device: instantaneous power, accumulated energy in mWh, min/max/mean/RMS, and a rolling FFT spectrum. What goes out over USB-HS to the PC is already processed data, not a raw sample flood. An ESP32-C6 on the same HAT handles the display and wireless side.

On the analog side: 51R/2R/50mR shunt ladder with analog comparators handling range switching, no firmware latency involved. One fine and one coarse ADC run on the shunt network simultaneously so you never lose samples during a range transition. The analog chain is built for 110kHz bandwidth at full resolution or 290kHz at reduced.

Last week I used it to debug a sleep current regression in an nRF52 project. Device was supposed to draw ~4µA in sleep and was pulling 340µA. The HAT has GPIO flag inputs you toggle from firmware right before a sleep call. Those get timestamped and correlated to the current trace sample index, so the AI can see exactly where the firmware thought it went to sleep vs where the current actually dropped. One prompt later Claude pinpointed GPIOs left initialized in a driven state. Fixed in a minute.

Still some work to do. Ordering the PCBs this week.

Project is fully available here: https://github.com/lollokara/BugBuster

AI disclaimer: yes, AI was used to develop parts of this. I wouldn't call it vibecoded though. I'm a solo dev, this isn't my full time job, I built it because I think AI is a genuine accelerator but an accelerator running open loop just drifts. It's not for sale either. If you want one, all the production files are in the repo.

Hey everyone,

I'm currently expanding the ecosystem of tools for a universal debugger I'm building ( https://github.com/lollokara/BugBuster ), and I think a dedicated power analysis tool would be a great addition.

To give you some context, here is my current setup:

• 10KSps 24-bit Delta-Sigma frontend ADC
• Current sense amplifier with a 2.7MHz bandwidth (low-pass filtered to 100KHz before entering the ADC)
• ESP32 using DSP to compress the data and extract information

The proposed upgrade: I'm thinking about building a new system around the following components:

• ADAQ7767-1 (1MSps, 24-bit ADC)
• ESP32-P4 (to handle the heavier processing)
• AD8411 Current Sense Amp

Before I pull the trigger on this design, I wanted to ask the community:

1. Does the 1MSps sample rate actually add valuable information for practical power analysis and profiling, or is it just going to generate excess data for me to crunch?
2. Do any of you have experience building something similar, or are there existing tools out there you'd recommend I look at for inspiration?

I've been working on BugBuster, an open-source, open-hardware bench instrument aimed at embedded development. Hardware files, firmware, desktop app, and Python library are all public.

I just finished the HAT, and here is what it currently does:

Hardware

RP2040 HAT (sits on top of the mainboard):

• 4-channel logic analyzer, PIO-driven, up to 100MHz, RLE compression, streams over a dedicated vendor-bulk USB endpoint.
• CMSIS-DAP SWD probe, dedicated 3-pin connector (SWDIO / SWCLK / TRACE), works with OpenOCD and pyOCD out of the box.
• 2× adjustable power rails (VADJ3 / VADJ4) + VLOGIC rail with auto-calibration.
• 8× WS2812B status LEDs.

ESP32-S3 mainboard (16 MB flash, 8 MB PSRAM):

• AD74416H quad-channel ADC/DAC, each channel independently configurable as voltage input, voltage output, current input, current output, RTD, digital IO.
• USB-PD via HUSB238, negotiates up to 20 V from the upstream port, exposes selected PDO over BBP and HTTP.
• 12 IO terminals with MUX, level-shifter (OE + DIR), and per-channel e-fuse protection.
• External I2C + SPI bus engine, Python/MCP can script scans and transfers directly over the IO terminals.
• PCA9535 IO expander for rail enables and fault monitoring.

Connectivity and Software

• Custom wire protocol (BBP v5) over USB-CDC0 — 59 commands covering every subsystem.
• HTTP REST API for WiFi-attached use (most features; LA bulk data is USB-only).
• Tauri + Leptos (Rust/WASM) desktop app — per-feature tabs, USB and HTTP transports, MAC-keyed pairing cache.
• Python library (bugbuster) with both USB and HTTP transports, plus a full FreeRTOS-style IO ownership model (claim/release per-channel).
• MCP server with 59 tools — Claude or any MCP-compatible agent can directly control the instrument, script I2C scans, capture logic traces, and set rail voltages.
• MicroPython on-device scripting — embedded MP runtime on ESP32-S3, HTTP eval/logs endpoints, VS Code-style web workbench in the on-device UI.
• mDNS discovery (bugbuster-<mac>.local) + WebSocket streaming endpoint.
• OTA firmware and SPIFFS updates with SHA-256 verification and rollback support.
• 420+ automated tests (unit + device simulator).

The target user is someone who regularly needs to probe I2C/SPI buses, capture logic traces, power a DUT from an adjustable rail, and occasionally poke at SWD, all from one USB connection.

The HAT PCBs were provided by JLCPCB for free to show their support for the open-source community.

I've been working on BugBuster, an open-source, open-hardware bench instrument aimed at embedded development. Hardware files, firmware, desktop app, and Python library are all public.

I just finished the HAT, and here is what it currently does:

Hardware

RP2040 HAT (sits on top of the mainboard):

• 4-channel logic analyzer, PIO-driven, up to 100MHz, RLE compression, streams over a dedicated vendor-bulk USB endpoint.
• CMSIS-DAP SWD probe, dedicated 3-pin connector (SWDIO / SWCLK / TRACE), works with OpenOCD and pyOCD out of the box.
• 2× adjustable power rails (VADJ3 / VADJ4) + VLOGIC rail with auto-calibration.
• 8× WS2812B status LEDs.

ESP32-S3 mainboard (16 MB flash, 8 MB PSRAM):

• AD74416H quad-channel ADC/DAC, each channel independently configurable as voltage input, voltage output, current input, current output, RTD, digital IO.
• USB-PD via HUSB238, negotiates up to 20 V from the upstream port, exposes selected PDO over BBP and HTTP.
• 12 IO terminals with MUX, level-shifter (OE + DIR), and per-channel e-fuse protection.
• External I2C + SPI bus engine, Python/MCP can script scans and transfers directly over the IO terminals.
• PCA9535 IO expander for rail enables and fault monitoring.

Connectivity and Software

• Custom wire protocol (BBP v5) over USB-CDC0 — 59 commands covering every subsystem.
• HTTP REST API for WiFi-attached use (most features; LA bulk data is USB-only).
• Tauri + Leptos (Rust/WASM) desktop app — per-feature tabs, USB and HTTP transports, MAC-keyed pairing cache.
• Python library (bugbuster) with both USB and HTTP transports, plus a full FreeRTOS-style IO ownership model (claim/release per-channel).
• MCP server with 59 tools — Claude or any MCP-compatible agent can directly control the instrument, script I2C scans, capture logic traces, and set rail voltages.
• MicroPython on-device scripting — embedded MP runtime on ESP32-S3, HTTP eval/logs endpoints, VS Code-style web workbench in the on-device UI.
• mDNS discovery (bugbuster-<mac>.local) + WebSocket streaming endpoint.
• OTA firmware and SPIFFS updates with SHA-256 verification and rollback support.
• 420+ automated tests (unit + device simulator).

The target user is someone who regularly needs to probe I2C/SPI buses, capture logic traces, power a DUT from an adjustable rail, and occasionally poke at SWD, all from one USB connection.

The HAT PCBs were provided by JLCPCB for free to show their support for the open-source community.

I've been building a bench instrument HAT that runs on an RP2040 and wanted to share some of the RP2040-specific things I learned, since they might help others working on similar projects.

  What the HAT does:

  - 4-channel logic analyzer driven by PIO1 (up to 1 MHz capture, RLE compression, streams over a vendor-bulk USB endpoint)

  - CMSIS-DAP SWD probe using PIO0 on a dedicated 3-pin connector 

  - Power rails with auto-calibration, IO level-shifting, e-fuse protection

  - SMP affinity: LA/USB tasks pinned to different cores via vTaskCoreAffinitySet to avoid USB starvation

  Tricky bits I ran into:

  1. TinyUSB abort_done hardware bug: the RP2040 SIE has a bug where calling tud_vendor_n_write_clear() more than 10 times without a pending transfer hangs. Routine cleanup has to go through a soft reset path instead.

  2. CMSIS-DAP driver stealing LA endpoints: fixed by patching bInterfaceSubClass/bInterfaceProtocol to 0xFF/0xFF on the LA interface in tud_descriptor_configuration_cb().

  3. Cross-core USB calls: TinyUSB is single-threaded; any endpoint rearm from Core 1 has to be deferred via a flag and processed on Core 0's USB thread.

Everything is open source (firmware, ESP32 bridge, Tauri desktop app, Python lib, PCB files). https://github.com/lollokara/BugBuster

The HAT PCBs where provided by JLC PCB for free to show their support for the opensource community.

Finally sharing the PCB for the HAT that just passed all tests, an open-source, open-hardware bench instrument stack I've been building.

The HAT (RP2040) sits on an ESP32-S3 mainboard and exposes:

• 4-channel logic analyzer (PIO-driven, up to 100 MHz, RLE compression, vendor-bulk USB)
• CMSIS-DAP SWD probe (dedicated 3-pin connector)
• 3 Adjustable power rails (VADJ (0V - 36V) x2 , VLOGIC (1V8-5V)) with auto-calibration
• 12 IO terminals with level-shifting and e-fuse protection

Everything communicates over BBP v5, a custom wire protocol over USB-CDC. The desktop app is Tauri + Leptos (Rust/WASM), and there's a Python library + MCP server for scripting.

PCB files, firmware (RP2040 + ESP32-S3), desktop app, and Python lib are all open source. https://github.com/lollokara/BugBuster

The HAT PCBs where provided by JLC PCB for free to show their support for the opensource community.

Took me a while but no flash is safe

Ordered these a few weeks ago and honestly expected the usual first-spin disasters. Instead after hand-placing components and a reflow session everything came up clean on first power-on which is a rare event, so I had to share.

The board is built around an ESP32-S3 as the main controller, talking over SPI to an AD74416H (4-channel 24-bit ADC/(IV)DAC combo, honestly the heart of the whole thing) and five ADGS2414D octal SPST switches that form a 40-point MUX fabric. A DS4424 handles fine iDAC trimming of the 3 output rails, a HUSB238 negotiates USB-PD, and a PCA9535 expands the I²C-controlled GPIOs. Four e-fuses sit in the power path for output protection.

The whole point of the design is to expose all of this as an MCP server and as Python API so AI assistants or scripts can autonomously probe, drive, and debug real hardware, measure voltages and currents, sweep outputs, capture ADC waveforms without a human in the loop for each step. Since handing an AI real control over hardware is a bit nervewracking, there are hard guardrails baked into the firmware and Python API, you can define a board profile for the DUT and it physically can't exceed the defined voltage limits or drive the wrong outputs.

There's also an optional RP2040 HAT that adds a 125 MHz logic analyzer and CMSIS-DAP probe.

Surprised it worked without any bodge wires, I'm now starting to polish the tools and firmware for it.

Full schematics, firmware, and build instructions: https://github.com/lollokara/BugBuster