Summary

The Benjymometer (a portmanteau from "Benjy" --That's me-- and "thermometer") is a DIY wireless thermometer designed to have extended range as compared with brick and mortar wireless thermometers. The original system used Arduino Pro Minis and 315 MHz Amplitude-Shift Keying (ASK) radios and supported both large seven-segment displays and 16x2 LCD displays. The system has been in use since 2017.

When I saw the Adafruit ESP32-S2 Reverse TFT Feather, I decided I could enhance the BenjyMometer receivers. The original Benjymometer could display high, low, and current temperature on the web using an optional Beagle Bone Black; however, this arrangement was unwieldy. But the Adafruit board has built-in WiFi, making web access easy. The board also has three user buttons, a small TFT display, and a LiPo battery charger/monitor.

Problems

I ran into two problems building the receiver: one hardware, one software.

Hardware Problem

My first experiments with the ESP-32 and ASK receiver failed. No packets were received. To understand the problem, consider the hardware configuration: an ESP-32, an ASK receiver requiring 5V, and a boost converter board to convert the 3.3 battery voltage to 5V. Under normal operating conditions, the ESP-32 is powered from a USB power module, so 5V is available; however, during a power failure, only the 3.3V battery power is available. The boost converter is used at all times to avoid switching between the power options.

In an effort to debug the problem, I used the boost converter to power a 16x2 LCD display board, and the ESP-32 started receiving packets. The boost converter board uses a TPS61023 boost converter IC. In situations where the load is low, the IC switches from PWM (Pulse Width Modulation) mode to PFM (Pulse Frequency Modulation) mode which can produce subharmonics. So adding the LCD display changed the boost converter operation mode and reduced subharmoics near the 315MHz receiver frequency. In the production version of the unit, I use a resistor to add load to the boost converter. (See the TPS61023 Datasheet.)

Software Problem

The Arduino ProMini-based transmitters and receivers use the Virtual Wire library. I decided to use its replacement, the RadioHead library because it was compatible with the ESP-32 Arduino toolchain. (It appears I could have used the FreeRTOS toolchain which I am familiar with, but I missed that option.) I assumed these two versions of the ASK (Amplitude Shift Keying) library could interoperate, but I found there is a catch. The Radiohead library prepends a header for source and destination which the VirtualWire library doesn't use. So I modified the radiohead library with a new function, setCompat(int version). Called with an argument of 1, it disables the extra header in RadioHead. (This page explains the extra header: https://forums.raspberrypi.com/viewtopic.php?t=230446.)

Hardware

The hardware consists of the following:

• Adafruit ESP32-S2 TFT Feather or Adafruit ESP32-S3 Reverse TFT Feather
• Adafruit MiniBoost 3V to 5V boost converter using TPS61023
• RF Link Receiver (315 MHz)
• Level shifter built around a 5LN01 and two 10K resistors
• 1K resistor, 10uF capacitor, and 0.1uF capacitor for buck converter taming

The schematic follows:

Software

During setup, the hardware is initialized. Then the system logs in to WiFi and sets its clock.

Because the software was written for a single core ESP32, there is one main loop. The loop executes the following actions:

• If a web transaction (graph display) is not in progress, check to see if there is a new HTTP connection, and if so, set a flag.
• If a web transaction is being processed, check for a client reset. If the connection is still active, do a non-blocking read for a character from the socket.
• When the end of an HTTP request is received, the code displays an HTML table of current, high, and low temperatures and battery status for the temperature transmitters. The code generates a temperature graph using Chart.js. Indoor and outdoor temperature for 24 hours are displayed on the graph. JavaScript causes the page to be updated every minute.
• Next the code checks to see if button zero is depressed, and if so, it is debounced. Each press rotates through three screens on the TFT display. The first screen shows the inside and outside temperatures. The second screen shows current, maximum, and minimum temperatures for both sensors and the ESP32 LiPo battery status. The last screen shows the number of missing packets during the last day, the WiFi IP address, and the number of WiFi reconnects.
• Button one is checked. It toggles the TFT backlight.
• In some versions of the code, button two forces a re-connect to the WiFi router.
• The code then does a non-blocking read for an ASK packet. If a packet is received, it is parsed, and temperature or battery data is updated.
• The time is checked for missing packets. Temperature sensors with missing data are flagged with an asterisk on the web page and a text color of yellow on the TFT display. (Packets are expected approximately every 2 minutes with some variation based on the unit address. This approach is used to avoid continuous collisions between multiple sensors.)
• High and low temperatures are reset at midnight.
• Next chart data is updated when a 30 minute average of temperature is obtained.

ASK is susceptible to interference and multipath. House materials also attenuate the signals. Because of multipath interference, placement of receivers in the house is critical. The ProMini receivers appear to have a lower error rate than the ESP32 version. My assumption is that the ESP32 and boost converter generate RF that can interfere with the ASK signal. I tried to minimize this with the PCB layout. The error rate for the ESP32 receiver and the outside sensor unit averages about 3% (about 22 lost packets out of 720 in a day). I find this to be an acceptable error rate.