It’s been a busy couple of months since the v5.0.0 release. If you recall my journey from concept to production, you know this project started as a simple utility. I wanted to take a moment to peel back the curtain and share what I’ve been working on since then. The road to v5.1.0 wasn’t just about adding features; it was about fixing annoyances that I encountered myself and building tools that I desperately needed for my own testing.
The “Reverse TFT” Headache
It all started back in November. I picked up one of those “Reverse TFT” Feather boards—you know, the ones where the screen is on the back? I flashed my existing v5.0.0 firmware onto it, expecting it to just work. It did not.
The screen lit up but stayed stubbornly black. I dove into the schematics and realized that while the standard TFT Feather works fine, the “Reverse” version has slightly different pin definitions. But the real kicker? Both require the I2C power pin to be explicitly toggled, which I had completely missed in the initial implementation.
// The simple line that fixed everything
pinMode(TFT_I2C_POWER, OUTPUT);
digitalWrite(TFT_I2C_POWER, HIGH);
Once I pushed that fix, the display came to life perfectly. It was a small change, but it paved the way for supporting a wider range of hardware reliably.
The Search for “Real” Latency
Fast forward to January. I was trying to optimize my home network and used the utility’s latency test. The result? “25ms”. Okay, fine. But then I ran it again: “200ms”. Then “40ms”.
I realized that pinging google.com or 8.8.8.8 is great for testing your internet connection, but terrible for testing your local WiFi performance. I needed a target on my local network that would echo packets instantly, without the jitter of the public internet.
That led to Commit 63684fe.
I decided to build my own echo servers. I wrote a high-performance C++ server for my Linux box that runs with real-time priority. It responds in microseconds, not milliseconds. For quick tests on my laptop, I whipped up a simple Python script.
Suddenly, I could see the true performance of the ESP32: sub-millisecond responses. It was a game-changer for debugging.
Updating the UI
With the backend tools in place, the old UI started to feel clunky. You had to click “Start”, wait 10 seconds, and then see a static result. Where’s the fun in that?
I wanted to see the packets flying. I wanted drama.
So, I rewrote the Latency Page to use a polling mechanism. Now, the moment you hit start, the browser begins asking the ESP32, “How many packets? What’s the jitter?” every second.
Here is a look at the simple architecture I settled on:
The result is a page that feels alive. You see the progress bar fill up, and the jitter stats jump around in real-time. It’s oddly satisfying to watch.
Polishing the Dashboard
While I was messing with the UI, I took a hard look at the main Status Dashboard. It was… functional. But a bit of a “wall of text”.
I decided to break it up into a grid layout. I grouped the WiFi status, network IP details, system hardware info, and connected clients into their own “cards”. It’s the same information, just much easier to scan at a glance.
Under the Hood: System Information
One specific request I kept getting was for easier access to hardware specs during field testing. I’ve added a
dedicated System Information section that pulls data directly from the ESP32 diagnostics.
It now displays:
- Chip Model & Revision (so you know if you’re on an older ESP32 or a shiny new S3)
- CPU Frequency
- Flash Size
- Free Heap (critical for debugging memory leaks)
It’s a small addition, but having this data front-and-center has saved me from guessing which board I grabbed from
the drawer.
The Release
Finally, after weeks of tweaking and testing (and playing with the new echo server way too much), I tagged v5.1.0.
This release feels solid. It solves the hardware quirks I found, adds the professional testing tools I needed, and makes the whole experience feel a lot more modern.
I hope you enjoy using it as much as I enjoyed building it.