atomic14

Hacking a Cheap PIR Night Light Into Something Actually Useful

Sat, 11 Apr 2026 00:00:00 +0000

I’ve been picking up a whole bunch of these motion sensitive night lights and, let’s just say, they haven’t been great. The range is poor, the battery life is nowhere near the advertised “charge it four times a year”, and the timeout is so short it’s not even enough time to get to the toilet.

I thought it might be interesting to crack one open and see if I could improve it.

I’ve got both flavours — round ones and oval ones — and internally they’re basically identical, so whatever I do to one should work for both. (Those are affiliate links — if you pick a pair up through them, I get a few pennies at no extra cost to you.)

The Plan

I’ve got a drawer full of these nice little RC-WL0516 microwave radar sensors. They’re much more sensitive than a PIR, they see through plastic, and you can tweak the sensitivity and timeout with a couple of passives. The idea is to rip the original motion sensing front end out of one of these night lights and drop the radar module in instead.

Cracking One Open

The top just pops off with a bit of a squeeze. Inside, there’s a PIR sensor, an eight pin mystery chip with all the identifying marks sanded off, a light dependent resistor, and some charging circuitry.

Popping the single screw out releases the board. Underneath is a tiny 350 mAh lithium cell — and no sign of a protection board on it, which is always reassuring.

With the board out, the layout is pretty clear. PIR sensor dead centre, ring of LEDs around it, mystery chip off to one side next to the LDR, and the charging circuitry tucked down by the micro USB port.

Doing a Big Clive

Time to do my best Big Clive impression and reverse engineer the circuit. It’s a single layer board, so it’s all quite tractable — the positive side of every LED is tied straight to battery plus, and the negative side goes through the mystery chip down to battery minus.

The PIR plus and PIR minus pins go straight into the mystery chip. The LDR is part of a potential divider with R5 feeding another pin on the chip, with a decoupling cap on the rail. Over on the charging side there’s a TP4054 with a 3.3k programming resistor — that’s about 300 mA of charge current — and an LED to show the state. That’s it. Highly optimised BOM, one big mystery IC doing all the work.

What’s interesting is there’s no current limiting on the LEDs. Nothing at all. The chip is clearly driving them directly, and presumably there’s some limit built in to the chip itself.

How Much Current?

Before doing anything else, I wanted to know how hard this thing is actually driving the LEDs. Desolder the battery, hook the pads up to a bench supply with the current limit set to 100 mA, and trigger the PIR.

68 mA. So there is some built-in limiting on the mystery chip after all. This mystery IC is doing a lot of heavy lifting.

Playing with the Radar Module

These RC-WL0516 modules are lovely. They have pads for a light dependent resistor so they only trigger in the dark, and a space to solder on a capacitor to extend the timeout.

I wired one up on a breadboard, hung an LED off the output through a current limit resistor, and fed it 5 V.

Stand still, the LED goes off. Move, it comes back on. The default timeout is about three seconds. As I mentioned, three seconds is nowhere near enough time to get to the toilet, so I soldered a 0.22 µF capacitor to the CTM pad to extend it.

Much better. I also wired up an LDR so it only triggers in the dark, and confirmed the motion detection works really nicely — much more sensitive than the original PIR ever was.

The Modification

Here’s the plan. Strip the PIR sensor, the mystery chip, and its supporting passives off the original board. Sit the radar module on top where there’s a nice flat empty space. Drive the LEDs through a current limiting resistor and a small MOSFET controlled by the radar module’s output pin. Power everything from the existing battery pads.

Microscope out, and with a bit of soldering the whole thing came together more neatly than I expected. I took the opportunity to upgrade the battery too — swapping the tiny 350 mAh cell for a much more generous 820 mAh one.

The board slides back into its case, the battery tucks in alongside, the USB port still lines up with the hole in the shell, the screw goes back in, the diffuser clips in, and… good as new. You’d never know anything had happened.

Does It Actually Work?

Stuck it on the stairs, turned the lights off, and waited. Walk past — it lights up. Stand still — it goes out after a sensible amount of time. Sensitivity is miles better than it was, the battery should last a lot longer, and the timeout is long enough to be useful.

It works. Now I just need to do the rest of them…

If you want to see the whole thing in motion — the teardown, the reverse engineering, the soldering, and the moment it finally lights up on the stairs — go and watch it on YouTube. Likes and subscribes are always appreciated.

I learned to solve a Rubik's cube and it was incredibly disappointing

Sun, 05 Apr 2026 00:00:00 +0000

I recently decided to learn how to solve the Rubik’s cube. As a self-confessed geek, it felt like something I should be able to do.

I found a pretty good website that breaks it down into eight steps, from “the Daisy” all the way through to “Finish Him!”. I memorised the moves. Pretty soon I could solve it without looking at the website.

It was incredibly disappointing.

I was just mechanically following “algorithms” I’d memorised. No skill, no insight. Pattern match, apply algorithm, repeat.

So I thought, this can’t be how speed cubers do it. Steps 1-3 are painfully tedious. There must be a faster way.

This led me to F2L, solving the first two layers simultaneously. The first resource I found suggested memorising 42 algorithms - my response - yeah, I’m not doign that…

Then I found a few suggestions on solving F2L “intuitively”, which sounded more my style. Maybe this approach would actually involve some thinking.

It’s definitely faster and requires a bit more brainpower, but ultimately? Still pattern matching. I wanted to understand why the algorithms work, not just memorise better ones.

Frustrated, I did what everyone does now. I asked ChatGPT.

After the obligatory “That’s a brilliant insight!” it gave me this analogy:

Beginner: following GPS directions
Intermediate: memorised routes
Advanced: understand the map
Expert: improvise new routes instantly

I keep coming back to this because it maps so well onto the junior-to-senior engineer journey.

You start out following instructions. At some point you start pattern matching. This problem looks like that problem I solved last year. Eventually the memorised playbook isn’t enough and you start synthesising new solutions from first principles. You develop taste. Judgment. The ability to look at a system you’ve never seen and know where the problems are going to be.

That last part is what I find interesting about coding agents right now. They’re very good at levels one and two. Following instructions, applying known patterns at scale, faster and more consistently (well, most of the time…) than any person could.

And sometimes watching an agent churn out code gives me that same Rubik’s cube feeling. It works. It passes the tests. But I’m just sitting here approving it. What am I even doing here?

But then you hit a problem where the agent can’t see what you see. It solves the ticket but puts the logic in the wrong place. It writes code that works today but will be a nightmare in six months. And you remember what you’re doing here. That’s the difference between mechanically producing a solution and deeply understanding the solution.

For now, experienced engineers are the ones providing the taste and judgment that makes the difference between code that works and code that works well.

I’m never going to be a speed cuber. But maybe, with the help of agents, I might end up being a speed coder…

Why Won't My Board Reset?

Sat, 04 Apr 2026 00:00:00 +0000

I’ve got a slightly annoying problem with one of my dev boards. The reset button does absolutely nothing.

These are the boards I got made by PCBWay — they did the PCBs and they came out really nice. I did the assembly myself. But somewhere along the way, something went wrong on one of them.

A Tale of Two Boards

I loaded both boards with a fast blink sketch to make the problem obvious. On the working board, hitting the reset button stops the flashing immediately — exactly what you’d expect. On the broken board? Nothing. The LED just keeps happily blinking away.

This is more than just a minor annoyance. To get an ESP32 into programming mode, you hold down the boot button and then press reset. Without a working reset button, I’m constantly having to unplug and re-plug the USB cable. Not ideal.

Checking the Schematic and PCB

First things first — let’s make sure the design is actually correct.

The schematic looks fine: the reset switch is connected to the EN (enable) pin through the standard RC circuit — a resistor and a capacitor. Nothing unusual there.

The PCB layout checks out too. Tracing the path from the reset switch down to ground, up through the RC network, and all the way to the EN pin — everything is routed correctly.

So the design isn’t the problem. Time to get the multimeter out.

Buzzing Out the Circuit

I started probing the connections on the board. The EN pin to the resistor — good. EN pin to the capacitor — good. The trace from the RC network to the switch — also good.

Then I put the probes across the switch itself and pressed the button.

Nothing. No continuity at all.

The boot button on the same board? Works perfectly. But the reset button is completely dead.

Under the Microscope

Time for a closer look. Under the microscope, the soldering on the ESP32’s EN pin looks fine — which the continuity test already confirmed. The RC components look good too.

The button itself? It looks solidly soldered. Visually, I couldn’t see any obvious problems. Comparing it with the boot button, the boot button’s joints were a bit shinier, but nothing that would explain a total failure.

It’s funny how boards look under the microscope — from a distance, this board looks perfectly clean, but zoom in and there’s all sorts of hairs and disgusting stuff.

Reflow and Test

With no obvious visual fault, I decided to reflow the solder joints on the reset button. Applied some flux, heated up each joint, and could feel solid connections on both sides of the switch.

Buzzed it out again. Still nothing. The button clicks mechanically, but there’s no electrical continuity when pressed.

At this point, it’s clear: the button itself is the problem.

The Fix: Just Add Alcohol

Looking more closely, the inside of the button seemed to be full of flux residue. On a whim, I soaked the board in IPA (isopropyl alcohol) to try and clean it out.

After a good soak, I probed the button again — and it worked perfectly. Every press gave clean, reliable continuity.

Plugging the board back in, the blink sketch was running. Hit the reset button and… the flashing stopped. Success!

Lesson Learned

The whole problem was flux residue inside the tactile switch, preventing the internal contacts from making a clean connection. The solder joints were fine, the traces were fine, the schematic was fine — it was just a dirty button.

A remarkably simple fix in the end. A bit of cleaning was all it needed.

The lesson? Use more alcohol — that’s the conclusion I’m taking from this…

Is SOT666 Really Standard?

Sun, 15 Mar 2026 00:00:00 +0000

Is SOT666 Really Standard? Spoiler: Not Really

I’ve been investigating some quality assurance failures on my ESP32 rainbow boards and tracked a few issues down to a USBLC6 ESD protection IC in a SOT666 package. Under the microscope, it looked like the footprint didn’t quite match the package — like it had missed alignment and hadn’t soldered on properly.

I fixed the immediate problem by reflowing the solder and pushing the device into place. But this should be automatic — the pick and place machine puts the component down and solder tension should pull it into alignment. So I started wondering: is the footprint actually correct?

The Problem: Footprint vs Datasheet

Opening up the schematic in KiCad, the USBLC6 is assigned a SOT666 footprint. That’s the correct package — so far so good.

But when I compared the KiCad footprint against the recommended footprint in the USBLC6 datasheet, things looked pretty different.

The KiCad footprint for SOT666 is completely different from the footprint in the datasheet — even though they’re both supposed to be SOT666.

So Is KiCad Wrong?

Maybe. But it’s not that simple.

If you Google “SOT666” you’ll find all sorts of different footprints from different manufacturers. Here’s how they stack up:

Nexperia’s SOT666 definition — looks very similar to KiCad’s version. In fact, I think KiCad’s footprint is based on this one.
ST’s USBLC6 datasheet — has its own recommended footprint with quite different dimensions.
Diodes Incorporated’s SOT666 — yet another completely different suggested pad layout.

So you’ve got a “standard” package name — SOT666 — but every manufacturer seems to have their own opinion about what the footprint should look like.

Checking EasyEDA for Comparison

I thought it might be instructive to check another EDA package. In EasyEDA, the SOT666 footprint for the USBLC6-2P6 is different again:

Pad width (PW1): 0.3 mm — this actually matches the ST datasheet
Pad length (PL1): 0.85 mm — the ST datasheet says 0.99 mm, so still different

Three different tools, three different footprints, all for the same “standard” package. Not exactly confidence-inspiring.

The Lesson: Always Follow the Datasheet

The basic conclusion is that although these packages share the same name, the footprints are not really standardised. Everything is randomly different.

The advice: look in the datasheet and use what’s in the datasheet. Don’t rely on the standard package names because they might not quite match up with your specific component.

Creating a Custom Footprint in KiCad

Fortunately, it’s really easy to create footprints in KiCad. Using the footprint wizard with the SOIC template, I just needed to plug in the values from the ST datasheet:

Pad count: 6 (two rows of 3)
Pitch: 0.5 mm
Pad width: 0.3 mm
Pad length: 0.99 mm
Row spacing: 1.61 mm (0.62 mm gap + 0.99 mm pad length)

A quick sanity check with the ruler confirmed everything matched the datasheet — the 0.62 mm gap between rows and 2.6 mm overall dimensions were spot on.

Updating the PCB

It took a bit of finagling — I had to make some traces slightly thinner so they didn’t collide — but the new footprint dropped into the design nicely.

The 3D preview looks good. Obviously the proof of the pudding will be the next production run, but it matches the datasheet now — so fingers crossed it will eliminate this class of QA errors.

Wrapping Up

If you’re designing PCBs, don’t assume that a standard package name means a standard footprint. Always cross-reference with your specific component’s datasheet. It only takes a few minutes to create a custom footprint in KiCad, and it could save you from chasing down mysterious assembly failures.

MAX30102 $3 Heart Rate Monitor

Sun, 15 Mar 2026 00:00:00 +0000

Building a Heart Rate Monitor with an ESP32-C3 and MAX30102

You know how it is. You buy one cute little module from AliExpress and then think “it looks lonely, I’ll get another”. Before you know it, you’ve got a drawer full of cute little modules. So it’s time to put one of them to work.

The ESP32-C3 Board

I’ve got a bunch of these tiny ESP32-C3 boards kicking around. Let’s take a look at one under the microscope.

The brains of the operation is an ESP32-C3 with built-in flash — four megabytes of it, which is pretty decent.

There’s a 3.3 volt regulator on board, and the soldering looks nicely done. It’s a pretty clean, well-designed little board. The antenna is a ceramic one on the side — though I’ve read a few people saying that on these tiny compact boards you don’t get much Wi-Fi signal due to the antenna placement being a bit too close to the buttons and other components. So we’ll avoid Wi-Fi for this project.

The MAX30102 Heart Rate and Blood Oxygen Sensor

For the actual sensor, I’m using a MAX30102 module — a heart rate and blood oxygen monitoring board that I picked up in a recent AliExpress order.

The board has a 3.3 volt boost regulator and a 1.8 volt regulator. Some people have reported finding a 2.8 volt regulator instead of 1.8 on some boards — it’s worth checking yours is correct. Mine was fine.

How the Sensor Works

The really interesting part is the sensor itself. Under the microscope you can see:

Two LEDs behind a window — a red LED and an infrared LED
A photodetector with a bunch of DSP processing built in

The outputs from this device are just the value of the red channel and the value of the infrared channel. You stick your finger on top and it detects pulse rate using the red LED and blood oxygen levels using the infrared LED.

When you power it up, you can easily see the red LED. If you cover it up and move the lights away, you can even see a slight glow from the infrared LED — the camera on the microscope picks it up nicely.

Wiring It Up

The wiring is pretty simple — it’s just I2C plus power:

const byte oxiInt = 2; // pin connected to MAX30102 INT
const int SENSOR_I2C_SDA_PIN = 5;
const int SENSOR_I2C_SCL_PIN = 6;

Pin 6 → SCL
Pin 5 → SDA
Pin 2 → Interrupt (tells us when data is ready)
5V → Vin (the board has its own 3.3V regulator)
GND → GND

A quick I2C scan confirms everything is connected properly — two devices show up: the I2C display and the heart rate monitor.

The Code

The main loop reads samples from the MAX30102 into a ring buffer, then runs the heart rate and SpO2 algorithms once the buffer is full:

void loop() {
  float n_spo2, ratio, correl;
  int8_t ch_spo2_valid;
  int32_t n_heart_rate;
  int8_t ch_hr_valid;

  // Read UPDATE_STEP new samples into the ring buffer
  for(int32_t n = 0; n < UPDATE_STEP; ++n) {
    readNextSampleIntoRing(data_ready_timeout_us);
  }

  // Need a full buffer before we can calculate
  if(sample_count < BUFFER_SIZE) return;
  buildOrderedWindow();

  // Calculate heart rate and SpO2
  rf_heart_rate_and_oxygen_saturation(
    ordered_ir_buffer, BUFFER_SIZE, ordered_red_buffer,
    &n_spo2, &ch_spo2_valid,
    &n_heart_rate, &ch_hr_valid,
    &ratio, &correl);

  // Median filter smooths out noisy readings
  hr_filter.push(ch_hr_valid ? n_heart_rate : INVALID_HR);
  spo2_filter.push(ch_spo2_valid ? n_spo2 : INVALID_SPO2);

  updateDisplay(filtered_heart_rate, (int32_t)filtered_spo2);
}

The display code is pretty straightforward — just show the heart rate and oxygen percentage on the tiny OLED, or dashes if we don’t have a valid reading:

static void updateDisplay(int32_t hr, int32_t spo2) {
  u8g2.clearBuffer();
  u8g2.setFont(u8g2_font_10x20_mr);
  u8g2.setCursor(0, 19);
  if (hr >= 30 && hr <= 250) {
    u8g2.printf("HR: %d", (int)hr);
  } else {
    u8g2.print("HR: --");
  }
  u8g2.setCursor(0, 39);
  if (spo2 >= 0 && spo2 <= 100) {
    u8g2.printf("O2: %d%%", (int)spo2);
  } else {
    u8g2.print("O2: --");
  }
  u8g2.sendBuffer();
}

There’s also a nice touch — the on-board LED flashes in time with your heartbeat.

Getting Readings

With the sketch uploaded and the OLED display showing results, it’s time to test.

It can be a bit finicky about finger placement — you need to keep it very still. But once it settles, it starts producing results: heart rate and SpO2 percentage.

Comparing to a Commercial Device

The real test — how does it compare to a proper pulse oximeter?

With both running side by side:

Heart rate: around 70 BPM on the ESP32-C3, matching the commercial monitor
Blood oxygen: 99% on both devices

Not bad at all. The main challenge is keeping your finger positioned accurately without squishing it on — it’s quite easy to lose the reading. But when you get a good contact, the results match up well.

Wrapping Up

The full code is on GitHub. Grab yourself one of these ESP32-C3 modules, a MAX30102 sensor, and a little OLED display, and you can build something equivalent to a commercial pulse oximeter for very little money. It’s a fun project — why not try it out?

I Made My ESP32-S3 Faster by Optimizing for SIZE — Not Speed

Fri, 06 Mar 2026 00:00:00 +0000

Optimizing ESP32-S3 Performance: Why Smaller Code Can Ran Faster

I’ve been tuning the performance of some code recently on an ESP32-S3 project,

There was a slightly counter-intuitive result that might surprise some people: optimizing for code size produced faster runtime performance than optimizing for performance.

There’s a full video here - but you can skim this post for most of the information.

The Benchmark

This is just some code that I pulled out of my latest project. It’s not an official piece of benchmarking code. So your mileage will definitely vary and you shohld do your own tests on your own code.

I kept my test case was deliberately simple and pulled out the most performance critical part of my code.

The code, input data, and hardware stayed constant throughout. Only ESP-IDF configuration options were changed between runs.

Baseline Results

Starting from a stock ESP-IDF configuration (I used their hello_world starter app), the decode took roughly 1.4 seconds.

From there, I explored a few of the usual performance levers:

CPU frequency (an obvious one!)
Compiler optimization level
Flash SPI mode
Cache configuration

CPU Frequency: The Obvious Win

Unsurprisingly, increasing the CPU frequency from 160 MHz to 240 MHz produced an immediate improvement.

The result was roughly the 1.5× speed-up thst you woulld hope for (it was actually around 1.46 - but close enough).

Compiler Optimizations: Size vs Speed

ESP-IDF menu config offers two commonly used optimization modes:

Optimize for size (-Os)
Optimize for performance (-O2)

Weirdly, in my first job (many years ago!), this was discussed in quite detail.

You naively expect that -O2 should be faster than -Os. In this case, it wasn’t.

With this workload, -Os outperformed -O2 quite significantly. They both beat the debug build - but -Os improved it the most.

Why Would Smaller Code Be Faster?

On the ESP32-S3, application code normally runs from flash memory with an instruction cache (you can actually copy code into PSRAM if it’s available which can be faster than flash).

Flash is pretty slow which means the CPU caches can have a significant impact.

instruction cache size
cache line fetches
cache miss penalties

Optimizing for performance often:

increases inlining
unrolls loops
duplicates code paths

All of this increases code size, which can lead to more instruction cache misses and more reads from the flash.

Optimizing for size does the opposite: it produces tighter code that is more likely to stay resident in the cache, reducing stalls caused by flash fetches.

In this workload, that effect outweighed the benefits of more aggressive instruction-level optimizations.

Flash Mode and Cache Configuration

Because the GIF was embedded in flash and accessed frequently, flash bandwidth also mattered.

Two changes helped further:

Switching the flash SPI mode from DIO to QIO (chack that your module supports this!)
Increasing instruction and data cache sizes to their maximum values

These changes reduced the cost of cache refills and improved overall throughput.

Interestingly, once the caches were enlarged, -O2 did improve — but it still didn’t beat the -Os configuration with the same cache settings.

The Winning Configuration

For this benchmark, the fastest setup was:

CPU frequency: 240 MHz
Compiler optimization: Optimize for size (-Os)
Instruction & data cache: maximum (turn it up to 11!)
Flash SPI mode: QIO

This combination produced the lowest overall decode time.

This is the case for my specific workload!

It’s important to be clear about the limits of this result.

You may not see the same behaviour if:

Your hot code runs entirely from the instruction cache or IRAM
Your workload is dominated by tight math loops on small datasets
You’re memory-bandwidth bound on internal RAM rather than flash

In those cases, -O2 or even more aggressive optimization may still win.

Full Results Table

Build type	usecs	ms	% of baseline
Baseline	1425476	1425.48	100
240MHz	965408	965.4	67.72
240MHz + Os	872495	872.5	61.21
240MHz + O2	962329	962.3	67.50
240MHz + Os + QIO	861859	861.9	60.46
240MHz + Os + QIO + caches	843286	843.3	59.16
240MHz + O2 + QIO + caches	933093	933.1	65.46

Conclusions

Performance is often limited by memory and caching, not raw CPU execution.

Smaller code can mean fewer cache misses - and fewer cache misses can mean faster code.

If you’re working on performance-critical ESP-IDF projects, it’s worth benchmarking -Os alongside -O2.

If you’ve tried similar experiments on other ESP32 variants, I’d love to hear what you found.

Watching LLMs Think

Thu, 19 Feb 2026 00:00:00 +0000

Many years ago, when I was younger and thought a PhD sounded like a sensible life choice, I started one.

Early on, a lecturer gave me a piece of advice that stuck:

“Don’t watch the program run.”

He meant the long jobs. Training a neural net. Running simulations. Anything where the terminal starts spitting out numbers and you just… sit there. Watching loss values tick down as if your attention somehow helps.

It feels like work.

It’s not.

You can burn an entire afternoon that way and have nothing to show for it except slightly better metrics.

His point was simple: start the job, then get out of the way. Make coffee. Write something. Read a paper. Talk to an actual human. Do work that requires a brain.

Lately I’ve caught myself doing the same thing with coding agents.

You kick one off and suddenly you’re staring at “Thinking…” like it’s a progress bar for your own productivity. Then the text starts streaming past and you read every line, as if supervising it in real time makes it better.

It’s the exact same trap.

The machine is busy. You don’t need to be.

When you see “Thinking…”, that’s probably your cue to step away and do something only you can do. And if I’m honest, that usually isn’t more coding.

ESP32-C3 0.42 OLED

Mon, 16 Feb 2026 00:00:00 +0000

I’ve ended up with a bunch of these nice little ESP32-C3 modules.

I’m a bit late to the party with them, so other people have done a lot of heavy lifting working out how to drive the display. I followed this blog.

The only thing I didn’t quite like was the slight bodge in his drawing code where he used the U8G2_SSD1306_128X64_NONAME_F_HW_I2C class and then offset his code to work for 70x40 size display.

There is now an appropriate constructor that seems to work without needing any funny offsets.

#include <U8g2lib.h>
#include <Wire.h>

#include <U8g2lib.h>
#include <Wire.h>

U8G2_SSD1306_72X40_ER_F_HW_I2C u8g2(U8G2_R0, U8X8_PIN_NONE, 6, 5);

int width = 72;
int height = 40;

void setup(void)
{
     delay(1000);
     u8g2.begin();
     u8g2.setContrast(255); // set contrast to maximum 
     u8g2.setBusClock(400000); //400kHz I2C 
     u8g2.setFont(u8g2_font_ncenB10_tr);
}

void loop(void)
{
    u8g2.clearBuffer(); // clear the internal memory
    u8g2.drawFrame(0, 0, width, height); //draw a frame around the border
    u8g2.setCursor(15, 25);
    u8g2.printf("%dx%d", width, height);
    u8g2.sendBuffer(); // transfer internal memory to the display
}

Turning an ESP32 into a Thermal USB Webcam

Sun, 15 Feb 2026 00:00:00 +0000

In a previous project, I made an ESP32 pretend to be a USB webcam.

This time, I wanted to do it properly - turn it into a real USB webcam with a real camera.

I also wanted to push things a bit further - I’ve got an I2C thermal camera module - why not turn that into a USB camera?

The ESP32S3 has native USB support, which means it can present itself directly as a USB device - this opens up a whole world of possibilities.

For USB video, I’m using USB UVC (USB Video Class). I’m also sticking to MJPEG to make things simple.

The nice thing about MJPEG is that it’s not a video codec in the traditional sense — it’s just a stream of individual JPEG images, sent one after another over USB.

Simple case: a normal camera module

Many ESP32-compatible camera modules already output JPEG-compressed images.

That means the “encoder” part of the webcam is basically free:

Our code turns into this:

Capture a JPEG frame from the camera
Hand the JPEG bytes to the USB stack
Repeat

You really can’t get much simpler than that.

You can use any S3 dev board - there are some nice ones that have built in cameras, but you could use a standard dev board and a camera module.

What you can’t use is the old ESP-CAM boards - firstly these don’t have USB and secondly the standard ESP32 doesn’t have native USB support.

Moving to thermal: a 32×24 infrared camera

The thermal camera is where things get interesting.

I’m using an MLX90640. This module outputs a 32×24 pixel temperature image over I2C. That’s just 768 pixels total - really tiny and not very usable raw.

But it is enough data to work with.

Our new code flow is:

Read the raw thermal image over I2C
Convert temperatures to grayscale or false colour
Scale the image up to 320×240
JPEG encode it
Stream it over USB using UVC

I2C debugging (and a reminder to myself)

Before any of it actually worked, I managed to lose a fair bit of time debugging what I thought was an I2C software problem.

I scanned addresses.
Checked pull-ups.
Tried different voltages.
Swapped code around.

Eventually, I looked at the board under a microscope abd found that it was just a dodgy solder joint on the on-board 3.3 V regulator.

You can see a detailed post on this here

This particular thermal camera board includes:

Built-in I2C pull-up resistors (2.2 kΩ to 3.3 V)
An on-board 3.3 V regulator

In theory, that means the board expects to be powered from 5 V, feeding the regulator.

In practice, the regulator is a low-dropout device (around 120 mV dropout at 100 mA), so powering the board directly from 3.3 V worked just fine.

Importantly, because the pull-ups are tied to the 3.3 V rail, there are no weird voltage levels on the I2C bus even when powered this way - which does make me wonder how well it would work with a real 5v logic device.

Making 32×24 pixels usable

Once the thermal data is coming in reliably, the next problem is obvious:

32×24 pixels is tiny.

The solution is to scale it up by a factor of 10× in each direction, producing a 320×240 image that fits nicely into a webcam frame.

I implemented two scaling options:

Nearest neighbour: very fast, but can look a bit blocky
Bilinear scaling: smoother, still fast enough on the ESP32-S3

Both give surprisingly good results, and once the image is scaled and colour-mapped, you’d never guess it started life at such a low resolution.

JPEG encoding and USB streaming

After scaling, the image is JPEG-encoded and sent over USB using the UVC stack.

From the host computer’s point of view, this is just a normal webcam:

Works in standard camera apps
No custom drivers
No special software

Despite the low input resolution, the frame rate is perfectly usable, and the ESP32-S3 has more than enough performance to keep everything running smoothly.

You can see it all in actiion here - it’s pretty cool (or hot!).

Pong Cam - My ESP32S3 Thinks It's a WebCam!

Sun, 01 Feb 2026 00:00:00 +0000

TL;DR

The ESP32-S3 (and other Espressif modules - at time of writing: H4, P4, S3, S3) can act as a USB webcam using the standard UVC protocol
There is no camera connected — all frames are generated in software
We start with a static JPEG, move to animated GIFs, and finish with Pong running in real time
Video is sent as MJPEG (a stream of JPEG images) over USB
JPEG encoding on the ESP32-S3 is fast enough to make this practical

In this project, we turn an ESP32-S3 into something your computer happily believes is a USB webcam — even though there’s no camera connected at all.

For these set of projects, instead of streaming video from a sensor, the ESP32 generates frames in software, encodes them as JPEGs, and sends them over USB using the standard UVC (USB Video Class) protocol.

We build this up in three stages:

A static test card (boring but does show it working)
Animated GIF playback using MJPEG (kind of fun)
A real-time game of Pong streamed as live video (forget TFT and OLED displays - just use your computer!)

You can find all the source code here.

How does it work?

At a high level, a USB webcam is just a device that:

Enumerates as a USB UVC device
Negotiates resolution and frame rate with the host
Sends a video stream to the host

In our case:

The ESP32-S3 provides native USB support
Espressif’s USB UVC device component handles enumeration and protocol details
We provide the video data — whether that’s a static JPEG, decoded GIF frames, or a game framebuffer

With Espressif’s usb_device_uvc component, we can do either MJPEG or H264. The underlying libary, TinyUSB, does have support for more formats.

MJPEG (Motion JPEG) is exactly what it sounds like: a sequence of individual JPEG images sent one after another. There’s no inter-frame compression — every frame stands alone.

The nice thing is, our computer doesn’t really care about the hardware - if it presents itself as a USB UVC device then our computer will see it as a web cam.

I did have some weird issues getting Isochronous mode working on the UVC component - I got very random frame stalls and glitches. This is likely to be somethign that I am doing in the code.

For all the demos I switched over to Bulk mode (this is set in menuconfig).

Demo 1: Static Test Card

The simplest possible (albeit most boring) webcam is one that just shows a static image.

For the first demo, we embed a single JPEG — a classic BBC test card — directly into the firmware. Whenever the USB host requests a frame, we return the same JPEG data.

This proves:

USB enumeration works
The host accepts the device as a valid webcam
MJPEG streaming is functional

Implementation Notes

We’re using the Espressif IDF for this project. This uses CMake and it’s pretty easy to embed binary data into our firmware.

idf_component_register(SRCS
                       "main.cpp"
                       "uvc_streamer.cpp"
                       PRIV_REQUIRES spi_flash
                       INCLUDE_DIRS ""
                       EMBED_FILES "test_card.jpeg")

And then you can reference it in code:

extern const unsigned char jpeg_start[] asm("_binary_test_card_jpeg_start");
extern const unsigned char jpeg_end[]   asm("_binary_test_card_jpeg_end");

const size_t jpeg_data_len = jpeg_end - jpeg_start;
const uint8_t *jpeg_data = jpeg_start;

Setting up the uvc component is as simple as providing it with a set of callbacks:

uvc_device_config_t config = {
    .uvc_buffer = uvc_buffer_,           // pointer to a buffer - this should be big enough for one of your JPEG frames
    .uvc_buffer_size = jpeg_data_len_,   // the length of the buffer
    .start_cb = camera_start_cb,         // called when things start up
    .fb_get_cb = camera_fb_get_cb,       // request for a new frame of data
    .fb_return_cb = camera_fb_return_cb, // the frame has been sent
    .stop_cb = camera_stop_cb,           // called when things stop
    .cb_ctx = nullptr,                   // passed into all the functions
};

The crucial callback to implements is camera_fb_get_cb. This returns a populated framebuffer that is sent over the wire to our PC.

uvc_fb_t *UvcStreamer::camera_fb_get_cb(void *cb_ctx) {
  uint64_t now_us = esp_timer_get_time();
  memset(&fb_, 0, sizeof(fb_));
  fb_.buf = const_cast<uint8_t *>(jpeg_data_);
  fb_.len = jpeg_data_len_;
  fb_.width = kFrameWidth;
  fb_.height = kFrameHeight;
  fb_.format = UVC_FORMAT_JPEG;
  fb_.timestamp.tv_sec = now_us / 1000000ULL;
  fb_.timestamp.tv_usec = now_us % 1000000ULL;

  return &fb_;
}

At this point, the webcam is extremely boring - it doesn’t actually move. But it does work!

Demo 2: Animated GIFs

A static image is fine, but webcams are meant to move.

For this demo:

An animated GIF is embedded into the firmware
Each GIF frame is decoded and then re-encoded as a JPEG at boot time
The JPEG frames are sent over USB at the correct times

To get the gif down to a sensible size to fit in the flash I used ezgif to resize and optimize it to 320x240.

GIF Decoding

We use Larry Bank’s excellent AnimatedGIF library to extract frames and timing information .

Even though this is a highly optimised library, decoding gifs is surprisingly intensive - with our 320x240 images it takes on average just under 33ms per frame.

JPEG Encoding

Each decoded frame is then encoded as a JPEG. We use the Espressif esp_new_jpeg component for this. According to the docs this should be able to encode a 320x240 images at 40fps.

In my tests we got around 23ms per frame - which is pretty impressive and would be 45fps!

Demo 3: Pong as a Webcam

So, can we use our “webcam” for something more fun? How about as a real time display of a game?

For something real time and interactive like a game we need to be getting close to at least 30 FPS.

At 30 FPS we have a budget of 33ms per frame. Given our JPEG encoding takes around 23ms we only have 10ms per frame for everything else!

Game Loop Constraints

Each frame must:

Update game logic
Render the framebuffer
Encode the frame as JPEG
Send it over USB

Pseudo code for this is below:

// simplified main loop
while (true) {
    wait_for_host_frame_request();
    update_game();
    render_frame();
    jpeg_encode();
    send_jpeg();
}

With careful tuning, this just about works — and the result is a fully playable game of Pong streamed through a standard webcam interface. The key detail is that the host paces the loop: the ESP32 renders/encodes a new frame when the UVC stack asks for one.

In my initial tests I got just under 29FPS. After some recent optimisations (I got the JPEG encoding down to around 21ms) I hit a solid 30 fps! Not a bad result.

What’s Next

In a follow-up project, we’ll replace the generated frames with a real camera sensor - it should be pretty straightforward.