Forem: Gabriel Womelsdorf

Is My Thermostat Lying? Designing a Low-Power Multi-Sensor Node (Series)

Gabriel Womelsdorf — Fri, 10 Apr 2026 19:45:43 +0000

A Cruel Thermostat

I'm sure many of you can relate to the lies that our thermostats push to us every day, 68 degrees my foot. Jokes aside, it's well established that the temperature across the room is not constant, with variation from the floor to ceiling, as well as local hot-spots near heat generating equipment or personnel. This creates a need for localized heat monitoring to track and log these hot-spots.

Where There's One There's Another

Additionally, in spaces with large heat generation, specifically from additive manufacturing or soldering, there is a marked increase in VOC, NOx, and CO2 generating. This poses several risks to occupants, from CO2 accumulation, to long term health degradation from exposures to VOCs such as styrene.

Engineering a solution

To track and monitor these quantities, I began work on a small air quality monitoring project. The first version began as a DHT11 connected to a raspberry pi pico. But after its untimely destruction, and with the accuracy of the DHT11 having much to be desired, I set out to create a new unit.

Requirements

The system was designed with four primary constraints:

No daughterboards (fully integrated design)
High-accuracy sensors
On-board power (battery operation)
Compact footprint

Version 1

The first official version of my air quality sensor, dubbed the Air Sentry was based off of the ESP32. Unfortunately, I did not include a USB interface on the PCB, which made programming and powering difficult. Apart from that small oversight, it was powered off of an internal battery, and could take 5 different measurements:

Temperature via SHT45
Humidity via SHT45
CO2 via STCC4
VOC Index via SGP41
NOx Index via SGP41

The primary motivator behind the ESP32 was fourfold:

A large amount of computing power
Ease of hardware integration
Programming over the USB interface
Relatively inexpensive

The ability to program over USB, rather than with a dedicated debugger gave me the ability to quickly program on the fly, rather than finding where I put the programmer. The ease of integration allowed me to focus on the design of the sensors, rather than the complex RF integration that BLE requires.

Numerous electrical issues primarily related to power regulation prevented reliable operation, leading to a rapid redesign.

Version 2

Version 2 addressed the power delivery issues identified in the first design and improved overall board stability. It also included some LEDs but kept the same sensors. There were also numerous electrical fixes that were identified from the first version. Before I manufactured this board, however, I shifted towards a longer and less square layout requirement. This was to try turning it into a commercial product.

Version 4

Funny enough, I skipped version 3 accidentally, but nonetheless, version 4 was built with this new requirement. Again, based around the ESP32, it included a new BMP390 barometric pressure sensor, and removed most of the LEDS. This was the first version to be successfully constructed. And after some driver development with ESPHome, I had a fully functional sensor node to play around with. However, power management with ESPHome proved challenging. As the project shifted toward longer-term data collection, I needed the device to operate for at least a week on battery power, something the current architecture struggled to support.

Version 5

Version 5 of the Air Sentry introduced the first major architectural redesign of the device since its inception. Thus, past version 5, the name officially changed to the Air Sentry Neo. The Neo replaced the ESP32 with a nRF52810 MCU, and consolidated the battery charging and voltage regulation using the nPM1304 PMIC. The combination allows me to have full control over the power of the device, with a sleep current under 500 µA. This transition traded the simplicity of ESP32-based layout and integration for lower idle current and more granular control over power modes. The improved efficiency also enabled a smaller board footprint without introducing thermal drift issues in the temperature sensor. On the software side, the system transitioned to Zephyr RTOS, and initial bring-up was successful with reliable sensor readings.

Unfortunately, there were issues with the clock generation, which led to a kernel panic when the BLE systems were turned on. This leads to the current state of the project: Version 6, which is focused on stabilizing the clock system and finalizing the design.

Conclusion

What started as a simple attempt to verify a thermostat reading evolved into a full design of a low-power, multi-sensor environmental monitoring system.

Across multiple iterations, the project highlighted several key lessons:

Power architecture is critical for battery-operated systems
Rapid hardware iteration exposes design flaws early
Platform choice (ESP32 vs nRF52) has a significant impact on power performance

With Version 5, the system reached a point of functional maturity, achieving reliable sensing and a substantial reduction in power consumption. However, challenges with clock stability and BLE integration remain.

Version 6 is currently in development and is focused on resolving these timing issues and finalizing the design for long-term deployment.

Ultimately, the goal is to use this system to generate and publish data on environmental conditions in additive manufacturing spaces—providing greater transparency into how these environments impact temperature and air quality.

Designing some memory for the Z80 supercomputer

Gabriel Womelsdorf — Wed, 18 May 2022 13:25:18 +0000

I have heard the comparison of CPUs to brains, and while this is good for teaching the basics of computer operation, I tend to disagree with this analogy as you dive deeper into the computer hardware world. I disagree with this because a brain is made up of many parts, one of which is memory, which is a fundamental part of the operation of computer systems and biological organisms alike. That said today I am going to design a memory module for the Z80 supercomputer.

What is memory?

Understanding exactly what memory is and how it works is a fundamental part of designing computer systems. Think of memory in this case as the computers working memory, as well as its short term memory. We will use it to store variables, programs, results from computations as well any other storage that does not need to be stored after power down.

How much memory is enough?

There is no definitive answer to this question, an iPhone with 1Mb of memory would not be very useful, but a Z80 with the same would be extremely overkill. In this case, due to the memory requirements of 1024 bit numbers, which take up a whole whopping 128 bytes of memory, or .128Kb I will have around 512Kb of working memory. Due note that only one 1024 bit number wouldn't be very useful, so in order to have 256 of them we would need 32Kb of RAM, still not 512Kb but that gives me a good amount of memory for future features.

What kind of memory?

There are many kinds of memory, from the magnetic core memory used in the Apollo Guidance computer, to the NOR and NAND flash memory in the USB stick. However when talking about volatile memory, the kind used in RAM sticks and modules, SRAM and DRAM rule supreme. DRAM is expensive and generally higher capacity, however SRAM is abundant, uses less circuitry and is less expensive in smaller chip capacities. Finding memory chips with a capacity of 512Kb is not difficult, but first we need to convert to Kbits in order to make our search easier, this is a fairly easy tasks by just multiplying Kbytes by 8 to get Kbits, 512 * 8 = 4096 or 4Mbits. Another important characteristic of memory is the organization, memory comes in many different forms in order to be compatible with many different processors, in this case we need a 512x8 chip, meaning it has 512 banks of 8 bit values. The IS61C5128AL-10TLI by ISSI fits these requirements perfectly.

Wiring the chip to a Z80

Data lines

Wiring the data lines for this chip is fairly straight forward and we can follow the same general steps as the processor

Control Lines

Next up are the control lines for the memory chip, in order to address the chip properly we need to use some logic to ensure the chip is only read from during a memory read, and not an IO read, same goes for writing to the chip. This can be accomplished with a simple OR gate, since the RD/WR lines as well as the MEMRQ lines are active low, as well as the RD/WR lines on the SRAM chip.

Address Lines 0-15

Connecting these is also straightforward, its only lines 16-18 that are a tad complicated

Address Lines 16-18

Now these lines are a bit more complicated because the Z80 only has 16 bits for address space, so we need to employ some tricks to expand this address space using a technique called bank switching. In order to do this we are going to use something called a D Latch in combination with some IO logic using something called a multiplexer. However that will be built in a separate module, however for now we can add the latches using a 74hc573

The ROM

All computers need some sort of read only memory that executes immediately at startup, in this case I am going to use a 64Kbit or 8Kb, which may seem small but this can't be written to so it won't be used as RAM, for this I am going to use the at28hc64bf, This can be wired in the same way.

The #CS pin

This pin is used in order to select the memory chips we are accessing, because this chip shares memory space with the ram chip, we effectively need to disable the RAM chip when in the ROMS address space, which can be done with a ton of OR gates. And an inverter.

Placing and routing

This is the same process as last time, here is the result after using an autorouter.

What's next

There are many more boards to design, including control boards, expansion modules such as an enhanced ALU, output boards and all sorts of other boards, but I think next I will design the output board, since many of the expansion boards need to be designed before the control boards.

Designing an 8-bit supercomputer

Gabriel Womelsdorf — Fri, 13 May 2022 19:16:12 +0000

In this short series I will be designing one of the first Z80 based supercomputers, in order to accomplish this we need to make useful modules for the multiple Z80 processors to use, this will include external APUs that can handle the large floating point numbers that the machine will be able to compute.

Z80 Compute Modules

In order for this machine to have any usable modules first we need to build some Z80 processor cards, this can easily be accomplished with a few small boards.

The Z80

The Z80 is an 8-bit processor with 16 bits of address space, there are a multitude of control and status lines as well that need to be controlled in order for the processor to run properly, first of which are the power (+5V) and ground (GND) connections, which supply power to the Z80, the +5V line should also have a decoupling capacitor to ground with a 100nF value.

Next are the control signals, ordinarily you would tie the majority of these to ground with a resistor, however in this case they will be needed later down the design process in order to control and monitor certain aspects of the running system, as such we will tie them to ground with an external input for control using a D Type latch.

There is a lot going on here, but basically I am attaching these pins to a latch so external circuitry can control them.

The final pieces of the puzzle for now are the data lines and address lines as well as a few other outputs and inputs, these will be used in tandem with the BUSREQ control line in order for the processors to access the memory and peripherals.

With this being the final schematic.

Routing the traces

Routing PCB traces is a massive pain, so I am going to use an autorouter to do the job for me, more specifically a tool called FreeRouting

freerouting / freerouting

Advanced PCB auto-router

Freerouting

Freerouting is an advanced autorouter for all PCB programs that support the standard Specctra or Electra DSN interface.

Download installers for Windows, Linux, and macOS here.

Introduction

Freerouting is a powerful PCB autorouter compatible with any PCB design software that supports the standard Specctra or Electra DSN interface. It imports .dsn files generated by the host system's Specctra interface and exports .ses Specctra session files.

Getting started

You can interact with Freerouting using the Graphical User Interface (GUI), the Command Line Interface (CLI), or the Freerouting API. All interfaces support command-line arguments to set input/output files or modify settings.

Integrations are available with:

Click here for more details.

Graphical User Interface (GUI)

Launch Freerouting: Upon launching, you'll see the main interface
Open Your Design: Go to File > Open... and select your .dsn input…

View on GitHub

Prior to routing:

After reorganizing:

After routing:

3D Render:

Next Up: Memory Modules