Recently [shraiwi] decided to have a bit of good nerdy fun and implement the FAST machine vision algorithm on an ESP32-S3 using its SIMD ISA. This involves using the assembly instructions for the ISA, making for an exciting opportunity to become familiar with this part of this Xtensa Lx7-based twin-core MCU.
The Features from Accelerated Segment Test (FAST) algorithm is a corner detection method that can determine with reasonable accuracy and in real-time whether a given input frame contains said corners which thus may correspond to objects and other characteristics worthy of note. This is essential for machine vision, with machine learning able to bump up its recognition accuracy even more.
Implementing this algorithm on the ESP32-S3 proved to be a bit of a challenge due to somewhat limited SIMD ISA. Missing instructions included things like comparisons between unsigned byte values, and there is no support for direct misaligned reads.
All of these required some creative coding to work around, but in the end the ESP32-S3 running at 240 MHz was able to process a VGA stream in real-time at 30 FPS. This means about a 2x speed-up over a naive implementation using only non-SIMD instructions.
Most commercial pet trackers require a subscription or network connection to function. [Jon G Aguado] wanted a better way and designed LIA, a Meshtastic collar tracker.
LIA uses a custom PCB containing a ESP32-S3, LoRa radio, GPS/GNSS receiver, and a charge controller for the 18650 or 5023450 pouch Li-ion cell powering the device. Everything fits inside a 3D printed enclosure, and the device is charged via a magnetic 4-pin USB pogo connector to increase weather resistance.
One of the neat features of this particular tracker is that [Aguado] gave it two different power modes. High power gets a location fix every 30 seconds and has a pair of bright LEDs for visual assistance, low power only gets a fix every minute or so, and it can also be set to off, which is something we wish more device manufacturers remembered should be an option.
The Soonpho M7 Pan Tilt Head is a useful photography tool for remotely aiming a decently-sized camera. Only, [Kyle Housley] wanted a little more control than was available out of the box. Hence, he built a custom controller that could deliver just that.
The project is based around an ESP32-S3 paired with an NRF24L01 wireless module. The ESP32-S3 is hooked up to a computer to receive commands over serial on what movements to make. It then transmits over the NRF24L01 to another NRF24L01 module that has been hacked into the original M7’s controller. In doing so, it can command the M7 to move to a given specific pan and tilt position, or to make a smooth motion along a vector. It can also trigger shutter release in the attached camera as needed, to capture whatever is being looked at.
[Kyle] has used this rig to create a motion tracking system for aircraft photography. With a Yolo vision model running on a laptop, the pan-tilt head can be commanded to track aircraft passing by and photograph them when they’re in frame. It’s a pretty slick setup; we’d love to see similar done with the aid of ADS-B data, too—perhaps even with automatic image tagging and upload.
Slow refresh, ghosting and low-contrast — wait, are we talking about passive matrix LCDs, or e-paper displays? That might be why e-paper Game Boy emulators are a thing: the limitations of the black-on-grey e-paper screens remind us of the grey-on-green LCDs Nintendo used in the 80s. In this case [Bo Made It] made it out of a Waveshare ESP32-S3-ePaper-1.54, and got 30 FPS from it.
Now, regular readers might be thinking, “So, we’ve seen the 60 FPS e-paper monitor, how is this special?” It’s a fair question. The answer is that [Bo] is doing this on a randomly chosen dev board with a built in wavetable e-paper controller, rather than the bare inputs that allowed the [Wenting Zhang]’s project to work. On the other hand, [Bo] does credit [Wenting], particularly his e-ink PaperBoy project, with directly inspiring both the project and his implementation.
Again, the big difference is going through the blob of the controller, but it turns out you can still address individual pixels through it. [Bo] gave each pixel a ‘budget’ for up to 8 pulses it depending on how much it needs to change, speeding things up immensely. Our favorite part is how he achieves the Game Boy’s 4-bit greyscale by, in effect, deliberately ghosting the display. Pixels aren’t driven long enough to fully flip them if they’re going only one shade lighter or darker. This complicated matters, since going from black to ‘white’ now takes longer than ‘white’ to the next darker grey, and the exact timing needs to be worked out for each color transition. Getting that timing right took a lot of calibration, and we like how he used video to help automate the process.
That process is still ongoing, so there’s no GitHub link yet. [Bo] will open source everything when it’s ready, and we look forward to it. We also look forward to the PDA-like device he’s going to be using this display driver for. If this all sounds similar to a recent 20 FPS e-paper hack, that’s because it’s the same underlying technology.
We’ve seen plenty of game console projects here, many of them that seek to produce a miniature game console. But this one from [RayTriangle] may break a new barrier entirely — it fits an entire TV game console that plays DOOM, including the battery, into a TV antenna plug.
There’s a type of antenna plug with screw terminals, originally intended for matching 300 ohm balanced feeder to 75 ohm co-ax. It provides a tiny project box if you look at it that way, and it’s in here that the console sits. It’s an ESP32-S3 that talks to a controller via Bluetooth, and he’s gone into some detail on how the RF for the TV is made. Some clever tricks such as a look-up table for the phase shifted chroma waveforms for each color allow the creation of a good quality composite signal through a resistor-ladder DAC, and this is modulated in a surprisingly old-fashioned way onto a carrier provided by the ESP’s clock generator.
The result as can be seen in the video below is a bit noisy, but we think that might be fixable with a little filter magic. It’s designed for PAL TVs with a VHF tuner, but we’re guessing some ingenuity could be brought into play to make it happen for UHF or NTSC. The hardware meanwhile is put on two boards either side of the battery, with a flexible PCB joining the two.
It’s true that gaming though an analogue RF input to a TV is probably less common in 2026, but we applaud the ingenuity in getting this into such a small space. For some reason it reminds us of the world’s smallest MIDI synthesizer.
As the legacy AM broadcast bands fade away, what happens to the millions of devices built to receive them? Many of them will go into e-waste, but with a century of radios to choose from, some of them are collector’s items. Vintage tube radios like the ones [GarethDaviesLondon] has would go silent, so he’s made a small AM transmitter to keep them alive.
At its heart is an ESP32-S3, which takes an online radio stream and transmits it through RF generated with a pulse chain on a GPIO. Generating analogue signals from radio to video with a microcontroller is nothing new, but perhaps the more interesting part of this one comes in how he radiates enough from that pin. There’s a 3D printed box with stand-offs designed to take a widely spaced wire coil, which is enough for the vintage electronics to pick up. He makes the point that it may not be legal, but at that power we doubt anyone will notice.
The output on this one is 200kHz for the European long wave band, but we’re guessing a higher medium wave frequency could also be generated. Meanwhile if you are curious about AM, we’ve featured someone having a closer look at it.
Lately, we’ve covered several tools you can use with your laptop to track nearby devices and people. While they’re useful, their effectiveness depends on the strength of your Bluetooth adapter, and, of course, you need to have your laptop with you.
This time, we’re doing things differently. We want to show you a device that can automatically monitor nearby devices for extended periods, anywhere you choose to place it, and as often as you want. It doesn’t rely solely on Bluetooth, as it also uses Wi-Fi, which is far more likely to be enabled, increasing the chances of detecting someone in your area.
What is Paxcounter
Paxcounter is an open-source firmware project that takes a cheap little ESP32 development board and turns it into a sensor that can count people. Almost every smartphone in the world is constantly sending out small Wi-Fi signals, called probe requests, and Bluetooth signals too, even when the phone is not connected to anything. Paxcounter listens for these signals in the air. It counts how many different devices it hears during each scan, and from that, it can tell you a real time estimate of how many people are nearby.
The project started out as a simple way to measure how many passengers or pedestrians pass through a certain spot. But over time, it grew into something much bigger. Now it works as a general purpose IoT platform, built on hardware that usually costs somewhere between $10 and $30. Besides its main job of counting Wi-Fi and Bluetooth devices, a Paxcounter can also read environmental sensors, track its GPS position, keep accurate time, and send all of that data out through LoRaWAN, MQTT, a local serial connection, or straight onto an SD card.
How the Counting Works
The way Paxcounter counts people is simple, but it was clearly built with privacy in mind from the very start. Every scan cycle, which lasts 60 seconds by default, the device switches its Wi-Fi and Bluetooth radios into scanning mode and listens for probe requests and advertisement packets coming from nearby devices. Each of these packets carries a MAC address. Paxcounter takes just the last two bytes of that address and turns them into a short, temporary ID. This ID is only used to check for duplicates during that one scan cycle. Once the cycle ends, the count of unique IDs gets sent out, and the whole list is wiped from memory. The firmware also does not try to fingerprint any device. It never tries to figure out a phone’s brand, its operating system, or who owns it. All it wants to know is whether that device has already been counted in the current window.
This scan and clear cycle just keeps repeating, either nonstop or on a schedule if deep sleep power saving is turned on. The results, which include the Wi-Fi count, the Bluetooth count, and sometimes live sensor readings too, get packed into a small payload and sent out through whatever channel the device is set up to use. One thing worth knowing is that Wi-Fi and Bluetooth scanning actually share the same 2.4 GHz radio hardware on the ESP32. So running both scans at the same time slightly lowers the accuracy of each one. Because of that, the project’s own advice is to split Wi-Fi only counting and Bluetooth only counting across two separate devices whenever the best possible accuracy is needed for both.
One Firmware, Many Boards
Paxcounter comes with a hardware abstraction layer and its own pin mapping files for dozens of ESP32 and ESP32-S3 boards. These come from well known manufacturers like LILYGO and TTGO, Heltec, Pycom, WeMos, M5Stack, and Adafruit, and there is also a generic template ready for boards that are not officially supported yet. LILYGO even sells a ready-made board called Paxcounter LoRa, built specifically to run this firmware.
Depending on which board you pick, your device can end up supporting a LoRaWAN radio for sending data over long distances while using very little power, an OLED status screen, or a single color, RGB, or larger LED matrix light to show status. It can also support a physical button for flipping through display pages or sending an alarm message, battery voltage monitoring, GPS positioning, a real time clock chip along with IF482 or DCF77 time telegram output, and even an SD card slot for logging data locally when there is no network around.
Because the whole system was designed to be truly portable, the documentation goes into real detail about power draw, which usually sits somewhere between 450 and 1000 milliwatts depending on how the device is set up. It also makes good use of the ESP32’s deep sleep mode, so a device can keep running for a long stretch of time on just one 18650 lithium ion battery cell. Members of the community have already shared several 3D printable enclosure designs on Thingiverse for the more popular boards.
Getting the Device Up and Running
Paxcounter is built using PlatformIO instead of the plain Arduino IDE. This choice lets it work smoothly with editors like Visual Studio Code, Atom, or Eclipse, and it gives the project reproducible, script driven builds. In fact, the repository runs an automated PlatformIO build check every single time the code changes, using GitHub Actions, and there is even a CodeFactor badge that keeps an eye on ongoing code quality.
The configuration is intentionally spread across a handful of different files instead of being crammed into just one. This keeps board specific settings, behavioral settings, and personal settings nicely separated from each other. The platformio.ini file is where you select which board’s hardware profile you want to compile against. The paxcounter.conf file handles behavioral settings, things like how long a scan cycle lasts, sleep timing, and payload options. The shared lmic_config.h file sets the LoRaWAN region and frequency plan, so it matches the rules where you live. The shared loraconf.h file holds the device’s LoRaWAN join credentials, and the project recommends using OTAA rather than ABP for this. And the shared ota.conf file stores the Wi-Fi credentials the device uses for over the air firmware updates.
You can upload firmware the traditional way, over USB, or once a device has joined a LoRaWAN network, you can push updates over the air instead. A remote command tells the board to connect to Wi-Fi, check a hosted repository called PAX.express for a newer build, and then download and flash it automatically. If anything goes wrong during that process, it will roll back to the previous version on its own. Devices can also be set up to open a small local web based bootstrap menu right when they power on, which lets you upload a firmware file manually, even from a phone in tethering mode, without needing PlatformIO installed on site.
Configuration and Extensibility
Beyond just picking a board, Paxcounter gives you a long list of settings you can tune to fit your needs. It can log environmental data from sensors like the Bosch BMP180, BME280, BMP280, or BME680, read a Nova SDS011 particulate matter sensor to track dust in the air, and keep accurate time using either a DS3231 real time clock or a connected GPS module.
Display and LED
On boards that come with an OLED display, Paxcounter shows live status information you can cycle through with a short press of the button. This includes the current pax count, meaning the people count, a histogram of recent activity, GPS status, environmental sensor readings, and the time of day.
A long press of that same button sends an alarm message out over the network instead, which is a simple way to flag a problem from out in the field without needing any other kind of interface. Even on boards that do not have a display at all, a status LED still tells you what the device is doing through its blink pattern. You get a brief flash whenever a new Wi-Fi or Bluetooth device is spotted, a quick blink while the device is joining the LoRaWAN network, a short blink during data transmission, and a slow, long blink if there is a LoRaWAN stack error. Boards that have an RGB LED get a color coded version of these same signals.
How You Receive the Data
Once a Paxcounter has counted the people nearby and packed everything into a message, that data has to go somewhere so you can actually see it. How that happens depends on which output the device is using, and the good news is you can turn on more than one at the same time. If you are using LoRaWAN, which is the most common setup, the device does not send the data straight to you. Instead, a nearby LoRaWAN gateway picks up the signal first and forwards it on to a network server, usually The Things Stack. There is a small decoder script included with the project, and its job is to take that raw message and turn it into numbers you can actually read, something like a pax count of 14. From there, The Things Stack can pass the data along to your own app or dashboard using MQTT or a webhook, or you can simply watch it come in live through the built in console.
If a board does not have LoRa hardware built in, it can just skip the gateway completely and send that same kind of data straight to an MQTT service over Wi-Fi instead. You can also connect the device to a computer using a USB cable and read the numbers directly from a serial connection. This is a simple way to test things out without needing to set up a network at all. If SD card logging is turned on, everything also gets saved locally as a CSV file, so you can pull the card out later and open it up in a spreadsheet. This comes in handy in places where there is no network coverage to rely on.
Where It’s Used
Because a single Paxcounter device is cheap to build and can be left running unattended for a long time, you will find it popping up in a pretty wide range of places. Retailers and shopping centers use it to measure foot traffic without needing to install cameras. Event organizers use it to watch how crowds move around a venue in real time. Pentesters can get a passive read on how many Wi-Fi and Bluetooth devices are active in a building, or to notice unexpected devices showing up where they shouldn’t, all without needing camera access or network credentials.
Legal and Privacy Considerations
Since Paxcounter’s whole job involves listening to wireless traffic, its documentation is unusually upfront about the legal side of things. It points out that sniffing Wi-Fi and Bluetooth MAC addresses may be regulated or restricted depending on where you live, and it links to specific starting references for the US, the UK, the Netherlands and the EU, and Germany. It also makes clear that the legal responsibility for how a device is built and deployed falls on the person doing it, especially for public deployments where the results might get published somewhere. On the technical side of privacy, the project’s own design actually holds up pretty well against that legal backdrop. Identifiers are only ever built from the last two bytes of a scanned MAC address, they are kept in memory just for the length of one scan cycle, and then they are discarded completely. No MAC addresses or identifiers are ever sent out over the network, and the firmware does not do any extra tracking or fingerprinting of the devices it scans.
Summary
What really makes Paxcounter stand out is not any single feature on its own. It is the whole combination working together. One piece of open source firmware supports dozens of cheap boards, runs for a long time on a small battery, counts people without saving anything identifying about them, doubles as a general environmental sensor node, speaks LoRaWAN, MQTT, serial, and SD card all at once, and can be fully reconfigured from a distance once it is out in the field. The full source code, the complete board list, and all the documentation are available on GitHub.
If you enjoy experimenting with frequencies and trying new things, we recommend signing up for our SDR for Hackers training. With Master OTW, you’ll learn how to use your computer and inexpensive SDR hardware to explore and hack a wide range of radio signals.
Login
