More wireless temperature displays: Low power LCD thermometer and ESP32 web server

Introduction

Previously, I had developed a simple wireless temperature display system using a network of battery-powered transmitters which transmit the temperature from their current location using low-cost 433MHz AM transmitters spread around the house to some custom-made display units, one of which was documented here: Wireless temperature display with bare glass LCDs

The transmitters were all built inside 4xAA battery boxes which had been modified to accept 2xAA batteries to power the stripboard circuit which occupied the other half. These units didn't have any display capability, but I thought it would be better if they did.

A small number of PIC microcontrollers have built-in LCD drivers, and after connecting an LCD to one on breadboard, I found that it was possible to achieve power consumption of only 20uA so it should be possible to have a display on it and still have a battery life measured in years. The PIC16LF1936 was used in this project.

All code and the PCB design for the transmitter can be found on GitHub here: wireless-thermometer-transmitter-dgl-lcd

All code and the PCB design for the receiver can be found on GitHub here: wireless-thermometer-display-esp32

The display

The DGL-0401YG-4EH LCD from the Wireless temperature display with bare glass LCDs would also be used here as it's a fairly large size and it also fits well in the space of 3xAA batteries.

Wireless communications

From the previous project: The 433MHz transmission system is a very simple system which does not define a protocol and is unidirectional, which means an unlimited amount of receivers can be added without any changes needing to be made to the firmware in the transmitters. The task of decoding and receiving the data was passed off to an NKM2401 to save time and due to reasons relating to the design of the temperature transmitters which was done previously, but it wouldn't be difficult to implement this directly in the PSoC...

The previous transmitters used a PICAXE microcontroller which included built-in support for the same protocol used by the NKM2401. No PICAXE microcontrollers have built-in LCD drivers, so that immediately ruled out the use of one of those. It would also be impractical to use an NKM2401 as that chip had no power saving optimisations and space was at a premium anyway. The only solution would be to reverse-engineer the protocol.

I captured a number of packets from the output of an NKM2401 with a logic analyser

From inspection of the waveform, we can see that each half bit is indeed exactly 200us and the packet format is as follows:

• One-byte preamble of 0x00
• Constant byte of 0x09
• 8 data bytes in the same order as the input bytes, with no processing, scrambling or further encoding
• CRC – and this is indeed a CRC not a simple checksum

I used the CRC RevEng program to determine that the CRC polynomial is 0xB3.

A more detailed explanation of my reverse engineering efforts can be found here.

I initially implemented the transmit sequence using C for loops, but this didn't work and the waveform showed that there was a longer delay between bytes than between bits, and the overhead of the C for loop was enough to make a difference at 4MHz. The solution was to use the rlf instruction in inline assembly as explained in the link above. The rlf instruction also makes implementing the CRC calculation much simpler than the typical C algorithm which uses a big lookup table.

Once implemented correctly, my PIC16LF1936-based transmitter project worked perfectly with the various receivers in the system.

The transmitter PCB

I designed the PCB to fit in the same space as 3xAA batteries, so that it would be possible to use a modified battery box as the enclosure. I also tried to track out a PCB antenna but it didn't work very well and ultimately a wire was needed for this function.

It is difficult to find battery boxes which take 5xAA batteries, and a 6xAA battery box would just be too big, so I considered solutions which would allow the use of a 4xAA battery box. The first idea was to find a half AA sized battery and use two of them in series, but they were all 3.6V primary lithium types and very expensive anyway. How about a 3.6V primary lithium AA battery? Also very expensive. Eventually, I settled on using 3.2V rechargeable LiFePO4 14500 cells, which are still more expensive than alkalines, but less expensive than primary lithium and can also be recharged once the 600mAh capacity is depleted. They also have a much flatter discharge voltage curve than alkalines so the contrast of the LCD will be consistent over time.

600mAh doesn't sound like much but the voltage is much higher than a regular alkaline AA, so the volumetric energy density is similar. The specific energy (energy per unit mass) of the LiFePO4 cell is incidentally much higher than NiMH or alkaline, and the LiFePO4 cell weighs much less than an alkaline or NiMH cell. I did test the cell and it delivered the claimed capacity. The power consumption of the transmitter is so low that the 600mAh capacity should power it for over 5 years if the backlight is not used frequently.

The receiver

This used the same PCB as the improved version of my ESP32-based Octopus Tracker Unit Rate Display project. Ultra-low power consumption wasn't a requirement and reducing the effort was more of a priority, so an NKM2401 was used for reception duties with the output connected to the ESP32's UART instead of implementing the decoding in the ESP32.

The display code was also reused from the ESP32-based Octopus Tracker Unit Rate Display project, but slightly modified so that the number was only displayed to one decimal place when the temperature was a single-digit positive value. This display code was combined with the Espressif's ESP-IDF webserver example, suitably modified so that requests to a specific page on the webserver would have the live temperatures injected into it, or unknown in the case of temperature IDs which hadn't been received since the last power cycle for correct handling in Home Assistant.

After some testing, it was found that the temperatures would stop updating in Home Assistant after a few days unless the receiver was power cycled. Examination of the code revealed that the cause was obvious and that was the wifi connection code in the webserver example was only a very basic implementation which wouldn't reconnect if the connection ever dropped. I added the much more elaborate wifi connection code used previously in the ESP32-based Octopus Tracker Unit Rate Display project and this seems to have resolved the problem and the connection is very reliable now.

The receiver is working well in Home Assistant and each temperature sensor works like any other sensor would.

ESP32-based Octopus Tracker Unit Rate Display

This project is based on the ESP32 and demonstrates how the chip can be used to connect to the internet, fetch useful data and display it.

octopus Tracker is a tariff which tracks the day-ahead wholesale prices of electricity and gas. This gets around the problem of energy being bought in advance at very high prices in 2022, making it by far the cheapest non-time of use tariff available in early 2023, but this comes at the expense of the tariff prices changing every day, so it's useful to have these prices conveniently displayed.

The project uses the esp-idf-json library and is based on the json-http-client2 example.

The code connects to wifi, then fetches the JSON data which contains the unit rates. The date and time in the HTTP response header is used to get the current date and time and set the ESP32's built-in RTC, which isn't displayed to the user, but used to refresh the prices every hour and determine what the current date is in order to display the correct prices from the JSON data.

The data is updated hourly because the day's unit rates are occasionally not available from the start of the day, and the correct unit rates won't be available for several hours in such a case.

Link to the source code on GitHub

Hardware design

Two three-digit 7-segment displays are used to display the prices. Each display already has three common anodes for the digits and has the matching segments of each digit connected together internally, and the segment pins of each display have been connected together to produce a display which is electrically a 6-digit multiplexed display. The anodes are switched with some general purpose PNP transistors because the peak current exceeds the current limit of a single ESP32 pin, and the segments are connected to ESP32 pins via resistors to limit the current.

A photodiode has been added to dim the display in conditions of low ambient light. An LDR would also be suitable. The voltage generated by the voltage divider is read using an ADC input and used to select one of four brightness levels. Filtering and hysteresis are used to avoid the brighness flickering in certain lighting conditions.

As an ESP32 WROOM 'dev kit' has been used for this project, the UART and 3.3V voltage regulator are built into the dev kit, so these components didn't have to be included in the circuit. Power to the project is supplied via a USB cable which is plugged into a convenient USB power supply.

Schematic

Hardware

The prototype has been carefully built on the copper side of some stripboard, taking care to ensure that no leads are sticking through to the component side on which only the 7-segment displays and photodiode are mounted. The perfectly smooth surface of the component side has been used to apply some labels.

Bush WI-1810 Internet Radio - Quick Teardown and Analysis

The Bush WI-1810 is a budget internet radio and Bluetooth speaker sold by Argos. At the time of writing, it was discounted to £25, but at its usual price of £49.99 it still represents the low end of the internet radio market. The radio is based on the Magic Systech platform, which is a popular platform and is found on many internet radios, but more premium brands such as Roberts and Pure use the competing Frontier Silicon SmartRadio platform. Both platforms allow set designers to incorporate a variety of features in a set including but not limited to internet radio, Bluetooth, uPnP streaming, FM, DAB+, CD player, and line in, but this set analysed here only features the first three of those features.

The current consumption of the radio is 0.25A @ 6.0V when in standby and 0.3A when on but nothing is playing. The current goes up by a negligible amount when an internet radio station is playing and the volume is turned down. When the volume is turned up to maximum, the current varies according to the audio and peaks at around 0.5A.

The level of integration in this product is surprisingly low. My original expectation was that there would be a Magic Systech-branded chip inside performing most of the key functions of the radio, much like the Frontier Silicon radios, but all of these functions are carried out by independent ICs and the CPU is an off-the-shelf one not specifically designed for radios. Despite the complexity of the design, components have been carefully selected to lower the cost whilst still delivering a reasonable level of performance where it matters - the audio quality.

Electrolytic capacitors - all off-brand through-hole 10V types, but surprisingly rated for 105 degrees C. Through-hole electrolytic capacitors are still cheaper than surface mount ones for some reason, so the extra assembly effort is often worth it.

CHMC SBE SCA108 Voltage regulator - I couldn't find anything for this part number, but the 0.33R resistor between pins 6 and 7 and the connections to the inductor, schottky diode and timing capacitor point to this being a really cheap Chinese clone of the MC34063, which itself is the cheapest widely available Western switching regulator IC. The 51k and 33k feedback resistors give an output voltage of 3.18V. This IC has a rather high maximum input voltage so this should give good headroom against overvoltage on the input.

The MC34063 is generally a good choice for this application. The only real disadvantage it has is that its switching frequency is low, which means it needs a fairly high-value inductor (typically 220uH), which is physically quite large at the regulator's typical rated current of 0.5A. Large inductors are expensive, so the designer has used a rather small inductor here.

I don't know how much current this design uses at 3.3V, or the current rating of the inductor, so I can't comment on whether it is comfortably adequate or being stressed. However, as both the inductor and chip get rather warm when the set is running, and the set uses 0.3A @ 6V when it's not producing any sound and it runs Linux, I would guess that the current it uses at 3.3V is much closer to 500mA than it is to 0mA, so if the device fails, I would check this inductor.

Nuvoton N32905U3DN main CPU - a surprisingly exotic chip which can run Linux and drive LCDs up to 1024x768. I found some limited information elsewhere on the internet which indicates that the Magic Systech software platform is Linux-based and that it is not exclusive to Nuvoton CPUs. The chip itself is not very old but the ARM926EJ-S CPU core itself is rather dated, which probably keeps costs down and contributes to the general sluggishness of the user interface.

W25Q32JV flash - this 32Mbit capacity (4Mbyte) flash chip will contain the entire program of the product as the CPU does not have any significant program memory of its own.

Super Chip SC2314 audio processor - this applies effects like volume, balance, bass, treble, etc. I'm surprised they didn't integrate these functions into the main CPU and implement them in software. Both channels appear to be in use, so there's an opportunity to mod in a stereo headphone jack to replace the mono jack it comes with. The L and R outputs from this chip go to C15 and C14, the other ends of which are connected together. I haven't tested it to see if the channels are stereo before that point.

CS8509E - Class D amplifier. Rated for operation up to 9.2V, and can deliver up to 8.5W into a 4-ohm load at 8.5V or 3W into a 4-ohm load at 5V. When powered from 6V, the maximum power would only be just over 3W at 1% THD according to a graph in the Chinese-language datasheet, which is probably why the Argos listing says it only has an output power of 3W despite the speaker being rated for 5W.

MT7601 Wi-Fi chip - commonly found in cheap Wi-Fi dongles, and probably selected for availability of Linux drivers. There is no Ethernet port on this set, which keeps the price down, but can result in reception being wiped out if the microwave is used in the kitchen (a common location to deploy a radio like this).

Bluetooth receiver - Beken BK8000 (under the sticker). This chip is commonly used on those Bluetooth-to-3.5mm modules which can be found on Aliexpress for next to nothing. Some of those Aliexpress modules look identical to the module in this radio. The module features a flash chip with a quarter of the capacity of the main processor's flash chip! All the audio decoding is done inside the BK8000, so the main processor just drives the module with some GPIO and presumably routes the audio to the speaker via the SC2314.

Speaker - 5W. This rather hefty speaker is not hi-fi quality but it's much better than that which would typically be found in an entry-level DAB/FM radio or even some entry-level boomboxes and the sound quality is quite reasonable for such a cheap set. I don't have a proper sound level meter so I can only give approximations of the frequency range, but when connected to a phone running a signal generator app via Bluetooth, the volume started to drop off below 80Hz and nothing was heard below 50Hz. At the high end, it sounded fine up to at least 9kHz.

Wireless temperature display with bare glass LCDs

First completed: 2018

Introduction

I had previously developed a simple wireless temperature display system using a network of battery-powered transmitters which transmit the temperature from their current location using low-cost 433MHz AM transmitters spread around the house to a custom-made display unit. I wanted to add a second display to show the temperatures from the same transmitters in another location, and also wanted to take the opportunity to experiment with the LCD drivers that are built into selected Cypress PSoC microcontrollers.

The PSoC 4 is a microcontroller based around the ARM Cortex-M0 processor core which features a comprehensive range of built-in peripherals and a small amount of programmable logic.

The LCD

The DGL-0401YG-4EH LCD was included in the Kemo Electronic S043 "lucky bag" of surplus displays and likely originated as a heating controller display. Such a supply method would be completely inappropriate for a commercial product due to no guarantee of supply, but for a hobby project it's fine.

the LCD has 4 common pins and 12 segment pins, meaning it is designed for 1/4 duty cycle multiplexed operation. The waveforms for multiplexing an LCD are more complex than for multiplexing LED displays because intermediate voltages are required and DC bias must be eliminated to avoid long-term damage to the LCD, so they're usually generated using a dedicated driver IC or by an LCD driver peripheral built into certain microcontrollers.

The PSoC's LCD driver is capable of up to 1/8 duty or 1/16 duty depending on the part chosen, so driving this LCD is no problem. In theory, multiple 1/4 duty LCDs could be wired for 1/8 or 1/16 duty to save I/O compared to using 1/4 duty, but there's a catch! The lower the duty (higher the denominator), the smaller the viewing angle becomes, which means that the LCD only has good contrast over a smaller range of viewing positions.

Ultimately, due to the amount of I/O available on the CY8CKIT-042, 1/8 duty was chosen as a good compromise between the viewing angle and number of I/O used. Some of the heating-related symbols were unused, so not all of the segments needed to be connected either. The segment lines for the °C symbol could also be commoned to save a further I/O line as there would be no need to control these symbols individually.

The one button added to the front switches the backlight brightness between three levels.

Wireless communications

The 433MHz transmission system is a very simple system which does not define a protocol and is unidirectional, which means an unlimited amount of receivers can be added without any changes needing to be made to the firmware in the transmitters. The task of decoding and receiving the data was passed off to an NKM2401 to save time and due to reasons relating to the design of the temperature transmitters which was done previously, but it wouldn't be difficult to implement this directly in the PSoC. For debugging, the 3.5mm jack in the bottom left corner can be connected to a computer serial port with a PICAXE programming cable and serves the dual purpose of allowing the monitoring of the received packets and the generation of test packets.

The data is transmitted in 8 byte packets. The first byte represents the ID of the temperature transmitter and is unique to each transmitter; the display unit uses this ID to decide which of the four LCDs should be updated with the newly received temperature. The second byte represents the type, allowing for future expansion with types other than temperature (e.g. humidity). Bytes 3 and 4 contain the temperature, bytes 5 to 7 are unused/reserved, and byte 8 is a very simple checksum which augments the error detection already implemented in the NKM2401.