These are the design specifications the reader was designed around.

The ESP32-S3 with 8 MB of PSRAM was selected as the microcontroller, and the OV2640 with a 160° field of view was selected as the camera. Production readers send their readings over LoRaWAN; Wi-Fi is only used by the reader on the training rig.

The camera is pointed at the water meter and takes readings on 6-hour intervals. After the reading is made on device, the numerical reading is transmitted over LoRaWAN to a database storing the readings, which the user and the utility provider can access over a dashboard. The original image is never transmitted; only the predicted reading is.

Prototype V2 is a shrunken-down version of Prototype V1. It fits in tighter spaces and let me explore smaller components like the Wio-SX1262 LoRa module from Seeed Studio. It has built-in battery management, power circuitry for the camera and fan, PWM-dimmable LED lights and a LoRa module. I designed the board in KiCad, sourced the components from DigiKey and sent it to JLCPCB for manufacturing; it is a 4-layer board. The circuits are in the report.

The PCB was designed to be roughly the same size as a typical ESP32-S3 dev board. This compact design allows a smaller housing that fits meters in tighter spaces.

Prototype V2 was developed before the writing of the report, so some deprecated decisions are still part of it: the fan, proposed for high-humidity conditions that may cause fogging, will be dropped instead if the readings are not reliable; and the power circuitry pre-dates the decision to use Li-SOCl2 cells.

The interior enclosure houses the PCB and batteries of Prototype V2. I exported the 3D file from KiCad into Onshape as the reference, modelled the camera by hand for accuracy, and designed it toolless: side clips snap the two halves together, grooves and pins stop lateral slide, platforms and posts hold the PCB without screws, and a cutout lets the LoRa IPEX cable reach the transceiver. The fit and finish of the final print was great, but I had to cut a hole for the flipped camera from the incorrect pin layout of the assembly stage.

The exterior adapter is two parts. The bottom half mounts against the meter and puts the camera lens about 4 cm from the dial, the focus distance chosen in the camera test. The top half is much wider, which leaves room to align the reader to the barrels and lets me reuse it on other meters by redesigning only a bottom half. I had forgotten the tabs that lock the meter’s lid, so a few cuts with side cutters made room for them.

The first version of MeterSim was built alongside Prototype V0.5’s firmware. They work in conjunction, so Prototype V0.5 can be controlled automatically by MeterSim and labelled image data can be generated for model training. All the software and firmware builds were entirely written by Claude.

MeterSim is built to be used by agentic AI agents instead of humans, so the control panel serves as a monitoring platform for humans to see the progress made by the agents. Agents use MeterSim as a framework to build tests, collect data and verify accuracy while creating DrumNet. It replaces the most tedious task in machine learning, gathering quality data to train on, by generating the data; and since the environment is simulated, the data is naturally labelled.

MeterSim has 9 different meter designs that can be customised with different barrel configurations, like 7 integer barrels and 1 decimal barrel (7+1); the integer barrels are typically in white or black while the decimal barrels are in red.

Common combinations of conditions are saved as presets: clean, noon, digit glare, half shadow, soft shadow, dusk, shaded, tilted and dirty.

It also simulates half-rolled barrels, so the model can be trained to predict the value of barrels that are in the middle of transitioning from one value to another. This is done automatically by the agent during training data collection.

MeterSim also simulates different weather and meter surface conditions to better match how a meter left out in the elements may look; this is part of the training so the reader can read in different conditions. The controls include glare, smudge, shadow, lighting, blur, sensor noise, fog, dirt and scaling.

MeterSim is a self-hosted web app with two endpoints: the control panel at /control and the display at /display. The reader is connected over Wi-Fi on the same local network as the MeterSim instance; it uses this to send readings and images it has taken and to receive commands.

For model evaluation, a randomised meter and its conditions are generated and shown to the reader, which takes an image and makes a reading using the trained network. The results are sent back to MeterSim, and since MeterSim knows the simulated value (the answer), it is compared against the prediction; repeated many times, this gives an approximate accuracy of the model, performed by an agent without human intervention. Collecting labelled data works the same way, except the images the reader takes are saved to disk along with the labels in JSON, ready for training.

SimGen2 generates an image in about 2 s, almost 5× faster than capturing with the physical reader. Used in parallel with the reader, it produced tens of thousands of unique labelled images, which trained the DrumNet Simulated model. Here a real capture tinted magenta is overlaid on its SimGen2 synthetic version tinted green; where they match the image is uncoloured. The LED glare in the real capture is the biggest difference left.

Twenty-one real captures and their SimGen2 versions across six meter designs, cut from the report’s sheets. Drag the divider: the real capture is on the left, SimGen2 on the right. The register strip is the part DrumNet reads, so it is the big one.

LLM-based AI agents were used extensively in this project. Agents were tasked to improve the full vision pipeline running on the ESP32-S3 with the target of 99 % meter accuracy. The core loop is developing a hypothesis, planning the execution, gathering training data, retraining, fine-tuning or RL-ing the model, testing for improvements or regressions, then reporting the findings and starting again.

With six agents running simultaneously, they would constantly compete for resources, so the scheduler was developed. It lets the agents book timeslots on the shared resources: my server (CPU compute) and laptop (GPU compute), collectively the compute resource used for training, and the Jetson rig, which lets an agent flash and interact with Prototype V1 while controlling the display it is pointed at through MeterSim.

On the scheduler’s compute timeline, the filled area is booked threads against the 20-thread budget and the red line is booked memory against the 9 GB budget. The laptop GPU takes one job at a time.

The agents ran 24/7 through a “heartbeat”, a simple script that wakes an agent after a set time, or at a set time, to continue working. The agents were instructed to act independently and make their own decisions, so very little human involvement was required.

Tailscale was at the heart of the networking: a personal peer-to-peer VPN that let the agents running on my server at home communicate with and control the Jetson rig located in school, over SSH. T3 Code, an open-source meta-harness for Claude Code and Codex, managed the agents.

An Astra 6 agent was tasked with writing the firmware for the reader (Prototype V2) and for the M5Stack Cardputer Adv, which runs ConfigKing, the configuration console that lets onsite engineers configure readers for deployment and reconfigure them later. The agent was told to only write code using Fable 5.1.

My laptop, the LoRaWAN gateway (graciously provided by Mr Lee Chang Fatt) and the Jetson Nano were set up on the same network; the Cardputer and Prototype V2 were connected over USB serial to the laptop, and all four devices were made available to the agents.

1. Wake from RTCThe reader wakes from sleep and restores its configuration and LoRaWAN session from Non-Volatile Storage.
2. Image captureThe camera is initialised and a capture is taken with the LED lights.
3. Low power readingThe image goes straight through the DrumNet readers using the stored ROI from setup, no WindowNet. The normal, cheapest path: a confident reading goes to the uplink, about 1.5 s awake in all.
4. Full DrumNet pipelineOnly if the readers report a low confidence does the full pipeline run as a backup, with WindowNet finding the window again.
5. Check confidenceThe new reading’s confidence is checked. Most readings leave the loop here.
6. Run with alternative spotterThe spotter runs once more with a different backup set of weights, one last attempt this cycle.
7. Reject readingA failed attempt is stored in NVS for later evaluation and a low-confidence warning is reported on the dashboard.
8. LoRaWAN uplinkThe LoRa link switches on and the reading is sent to the gateway.
9. SleepAll peripherals shut down and the reader deep-sleeps until the RTC wakes it for the next cycle. Pressing BOOT wakes it for configuration.

After the reading is made it is sent to the LoRaWAN gateway, which forwards it over MQTT to the Jetson Nano, where it is stored. The Jetson serves the dashboard as a single HTML file whose JavaScript updates the values from the stored data. The dashboard is a demo and is not designed to scale to real deployments.

The reader needs to run for very long durations, up to 2 years, on a set of batteries. The ESP32-S3 is relatively efficient at heavy tasks like the vector maths neural networks need, but it is nowhere near as efficient as Nordic’s nRF line-up, so these are the strategies to reduce energy use. The wireless radios of the ESP32-S3 are turned off in deployment; they are only used for initial configuration.

The OV2640 supports up to 1600 × 1200 but also sub-sampling modes of 800 × 600 SVGA and 400 × 296 CIF.

I had initially dismissed PWM dimming because the OV2640 uses a rolling shutter, which could capture between the off-cycles of the PWM signal and show banding. But the OV2640 did not suffer from any banding, so I run the LEDs at 20 kHz with 50 % duty cycle. This saves some fraction of power and adds brightness control.

The greyscale filter is done on the camera by the OV2640 and returns a slightly smaller image file; the impact is none to minimal, but it was easy to implement.

Earlier builds of DrumNet ran at full-precision Float32 on the ESP32-S3, slow and inefficient. The ESP32-S3 has built-in vector instructions, accessed through the ESP-NN library, that perform Multiply and Accumulate (MAC) operations multiple times per clock cycle. After quantising DrumNet to 8 bits, capture-to-prediction time was cut from 61 s to 17 s, roughly 3.6× faster. Efficiency gains have not been properly measured, although I am sure there were big improvements there too.

• Low Iq, high-efficiency DC-DC converters. The OV2640 needs 1.5 V and 2.8 V. Buck converters have better efficiency than LDOs, but their high quiescent current and more complex design add cost and board space for close-to-negligible gains, and can introduce artefacts in the image, so I stuck with LDOs with low quiescent current. The main 3.3 V rail would be swapped for a special low-Iq (~75 nA) buck-boost converter, the TI TPS63900.
• Ultra-low-power timer ICs. A timer IC like the Ambiq AM1805 can turn off all the components and turn them back on on a schedule. The gain would probably be minimal.
• LoRaWAN. Chosen for its superior low power and long range, and because its open standard lets the operator entirely own and run their network, unlike Sigfox and NB-IoT.

I needed a capable macro camera, wide enough to capture the full width of the meter barrels while in close proximity to the meter. There were no options that were both low cost and of the correct connector type from reputable retailers, so I bought two OV2640 cameras from Lazada, one with a 160° field-of-view lens and one with 120°. They were not advertised as macro, but an intrinsic property of wide-angle lenses is their ultra-short focusing distance and much deeper apparent depth of field.

The test was simple: take an image with both cameras at 3 cm, 4 cm and 6 cm, against two focusing charts. Chart A was hand-drawn by me; Chart B is Stephen H. Westin’s ISO 12233 chart from Cornell. Using a spare ESP32-S3 cam board and a simple web applet written with an AI agent, the camera was mounted to the side of a box with a ruler starting from the lens, and the charts sat on a movable stand.

Pick a lens, a distance and a chart: the full capture, with its centre, left and right cut from the same frame at actual pixels. These are fixed-focus lenses, so focus is permanently set at the factory. Moving forward I use the 160° variant at 4 cm.

On the 160° variant, focus tapers off towards the left of the image from the centre, while the effect is nowhere near as strong in the opposite direction. The chart was perpendicular to the camera with no major slants or dents, and the 120° variant tapers conically and evenly, so this points towards a manufacturing defect; I have no extra cameras to test if that is true.

Due to time constraints, the project stops as it currently is; many issues still need to be addressed before this could be a viable solution. The energy use of this meter has not been measured or tested for its rated 2-year life cycle, and as Prototype V2 stands I do not think that rating is possible: a third revision with more energy-saving components is needed before it is reasonable to start monitoring consumption. The firmware is close to my targeted level of efficiency.

The 56 % reading accuracy of DrumNet V10 is a far cry from the targeted 99 %. The primary bottleneck is WindowNet: most erroneous readings were caused by its inability to find the correct ROI. The readers also show signs of under-training; a meter they have not seen yields a low confidence, because the dataset was dominated by the 9 meters SimGen2 could generate. A more diverse and larger dataset could help both. The shell is much too bulky for a real deployment; the camera is the primary cause of the Z-height, so a shorter camera that is better at macro imaging needs to be selected, and weather sealing will need different materials and designs.

Much of this project was my first attempt at something new. I am not exactly satisfied with the outcome, but I am proud of the knowledge and experience I have gained, and grateful for the rare opportunity of time, resources and support to learn and experiment the way I do. Thank you to Mr Alex Oh (NYP) for his guidance, expertise and encouragement, to Mr Soh (NYP), without whom I would not have got the camera working, and to Mr Lee Chang Fatt (NYP) for the LoRaWAN gateway.