Evolution of my code and PCBs

One the last few weeks my code and PCB designs have evolved a bit!

EPD

This is still called EPD (E-Paper Display), but in practice it is now a general purpose signage system allowing a number of widgets to be displayed getting data from many sources. Making it work with the 2" and 2.4" waveshare LCDs was nice. I got my PNG code doing colour nicely for this, and alpha blending.

One aspect I was very pleased about was the display connection - the display has 8 pads/holes at 0.1" spacing for a normal 0.1" header pin strip. Making a board to work with this is easy and you solder top and bottom - done! But it makes it almost impossible to remove cleanly if ever needed.

The trick is a surface mount header on my board, on top of pads/holes to allow for longer pins. This then allows 0.1" header pins on the display that then just plug in. It can be unplugged simply if access needed for connectors, or if changing display/board at any point. 

But the code has evolved even more - allowing a wide number of sensors (I2C and one-wire-bus), and formatting specially for temperatures (small C/F, colour based on range), etc. And now even BLE based temperature and humidity sensors as well.

In fact, with all of the sensors reporting to Home Assistant, I have had to make a "non display" version of the code for someone that is using this with no display - which is crazy for code designed to display stuff.

I also added handing of buttons as the board (see below) has them, causing Home Assistant triggers.

Faikin Remote

This other code has worked very much in parallel with a lot in common - including adding a load of sensors, the same as EPD. The main use case is to work a Faikin.

However the PCB design for this has ended up being a key module for use with my EPD code. It too has changed.

The initial sensors were temperature (as main thing for Faikin remote), humidity, and CO₂. The module is designed to also work a fan and radiator based - fan based on humidity and CO₂, and radiator based on temperature for cases where you have air-con and radiator. But it works for rooms I have that only have radiator, obviously. So it is an environmental monitor (working with HA) and a remote for the Faikin.

It also has pressure, so the CO₂ can be calibrated, and a light sensor so it can go off when dark (ideal for a bedroom).

But it is growing, with my latest designs (not yet on sale) having a microphone for noise level, and also an IR remote receiver. The idea of the IR is that a Daikin remote could work this directly. I'll need to code these soon.

It is becoming a really comprehensive environmental monitoring board now.

I was also asked to make the snap off bits (button, CO₂, and now IR) have pads to allow them to be wired in, so that is done - you can remove and mount nearby and wire back to the board.

Practical uses

Obviously I have these working with Faikin modules, and have them working with radiators (with and without air-con), and in places just monitoring. Some customers have them around offices to monitor workspace environmental conditions.

One good use case with remote BLE sensors is the pub. Showing BLE sensors in various places, and the DS18B20 temperature probe from another of the boards in the cellar monitoring the beer cooler. The fact this is all visible from the bar now makes life easier, and highlights any out of temperature readings (like when someone opened the beer keg store room to put in a sensor).

What is ideal is this is all reported and logged and graphed on Home Assistant as well. Any issues with the beer/lager the bar staff can see if there is an issue with the cooler at a glance (as had happened a couple of times). We also have logs and graphs which helps when the engineer comes in to sort the cooler.

Next step is probably one monitoring all the fridges. I found these small BLE sensors manage to work inside a metal fridge, if you are close enough. They will still do their temp checks, but this will alert quickly in one place if any issues, and provide historical records nicely. Obviously we check these with a calibrated thermometer as well.

All I need to do now is find a source of the BLE sensors that still work and can be flashed with Telink Flasher. Any pointers welcome.

Tindie

Yes, the code and PCB design is all open source, and I have these on Tindie. I do a tad cheaper for collection from Aber if you are local. Check it out as there is quite a lot on there now.

E-paper

E-paper is pretty magic stuff, and somewhat voodoo in the way the drivers work.

Some time ago I made my own drivers for various e-paper devices including the Waveshare 7.5" 480x800 mono display.

The only complicated bit was working out a fast LUT to allow things like the clock update without several seconds flashing the whole display black and white. If you have used e-paper, you will know that a normal update is a muti second sequence of black and white flashing, even if only for a region of the display.

This is problematic in many ways, leaving some level of shadow of the changes, and possibly causing charge to build up and create ghosting. I ensured we do some full updates (only once a day), but that seemed to be fine. I have used this on signs for some years now, and they work well.

Seven segment digits

The use of seven segment digit fonts for the clock, i.e. what changes every minute, is important too. Any shadowing looks clean because it shows on the segments that are logically on or off only, indeed a shadow of off segments looks perfectly normal, even deliberate.

Applying the fast update a couple of times also works well to kill off the initial shadow of the change.

So yes, this works well.

Problems?

However, having used this for some years, I ran in to a snag.

The problem is down to the choice of black and white on the image as a whole. I did check, and adding some heavy capacitors on the power lines did not help, so not that. A choice of image with a lot of white (even as shown here) was enough to create some extra ghosting on change and look messy.

So I tinkered some more. I got a very clean effect initially but greying and fading within seconds, arrrg! I then decided to leave the power on, PON, and that works to hold the black and white cleanly. Yay.

But no!

This was creating a nasty cumulative effect, over several hours the display did a nasty burn in. It is not a real burn in, but charge on particles in the display. It meant that the display got more and more ghosting of previous segments and text. After a day it was really terrible.

So back to the auto PON/update/POFF, which is what I did before, but that again left it grey.

Finally after yet more tweaking, I have a settled on PON, update, POFF manually, i.e. not using auto mode, and setting a 4 frame setting on POF (not 100% sure what that does). The result was that the final fading was very slight, leaving a pretty clean display even when there is the problem image.

Clearing the burn in

I then had to do a lot of black/white full refreshes to try and clear some of the burn in and it is working, but taking time. I have added an option for over a hundred full updates in middle of night, now.

So I think I have it sussed, again.

What's next?

My E-paper code allows clock, date, sunrise/set, QR codes, (seasonal) images, and a few other bits, even (at a push) bins that are to be put out (Monmouthshire). The effects are configurable and stack up from the bottom of the display (well, bins at top).

But I think I will start a new version.

The plan is a series of widgets that you can set anywhere on the display and any size in any order. This will allow me to add more and more widgets - maybe weather as well, simple text, images of other sizes. All sorts, and easily extended over time.

Buy these?

Finally the plug, I have sourced 100 of these very nice 7.5" displays, and selling on Tindie with and without my controllers.

Regardless of my work on this code, you can always load esphome, or other code to run these displays.