Stroke

The NHS have been very thorough investigating the stroke I had.

Thankfully the ongoing effects are slight - my typing is still more iffy than it was before, but good news.

They even did an ultrasound on my heart to try and find the underlying cause.

The good news is they found nothing. Well, I'll take it as good news. It also means they could not explain it, which is not so good. But given I had a stroke immediately after COVID, that seems a likely cause.

However, the one thing I find odd is the NHS efficiency here. The letter arrived this week (13th March 2025).

So what happened. I don't think even Royal Mail have a 17th class post that takes 6 months to deliver a letter. So that is rather weird.

Right to private communications

The European Convention on Human Rights protects the right to respect for private life, the home and correspondence. This includes protecting the privacy of messages, phone calls, and emails.

But UK and EU governments are trying to break that right in various ways.

So some thoughts.

1. Encrypted communication is a thing, it exists, it cannot be banned, it is just maths. I have done a nice video on how to make an uncrackable entirely manual encryption (one time pad) here.
2. Criminals can use encryption. My video is an extreme example, but in practice the tools to do this electronically in many effective ways exist and can be used by criminals, and MPs.
3. There are even ways to use encryption in a way that is mathematically impossible to prove you are doing - steganography - where there is no way to tell your encrypted messages apart from random noise in say an image or video.

What this means is that even slightly savvy criminals are safe. The tools all exist and are easy to use. The only issue is if non criminals like you and me can expect that right to privacy.

The Investigatory Powers Act (on which I commented, and was a witness at parliament) did, and does, try to crack encryption as a legal process, maybe, the wording is not ideal. Apple's news on this is one of the key examples. Not the first and not the last, and not something that actually tackles criminals using encryption, it will just make normal people way less safe. Remember criminals can use encryption!

One of the challenges for most normal people is how to use encryption. Most people do not care, or know, why they should even. But there are many ways. The old school ways are using PGP email, which is complex but that is no longer the case. There are many apps and ways to communicate securely, and the obvious ones are things like iMessage (for now). Apple designed it to be secure. But also WhatsApp and Signal.

The problem is that any organisation operating any messaging system that is secure is subject to secret orders from governments to impose back doors.

There are even calls for scanning content for illegal material, which only works if a service has access to the content. This has so many problems, apart from breaking basic human rights. And, I remind you that the "bad people" with "illegal content" can always encrypt what they do anyway, and even secretly if they want to. They actually have an incentive to take the extra steps that normal innocent people do not. The only problem is removing privacy for normal people.

So now to come to the main point of this blog...

Delta Chat

This is an app that works with email, it connects to your provider's email server (not all providers work, but many do, using IMAP and SMTP), and allows a more traditional style messaging app that makes encrypted communications simple.

It is clever, well done.

What is extra clever is this is just an email client. It is not a service that is subject to either Investigatory Power Act or Online Safety Act. Indeed, the latter explicitly excludes email, a term OFCOM consider everyone understands (really!).

But it makes secure encrypted chat a thing anyone can do, easily, in a way that legally there is very little that can get in the way.

So worth considering.

Muddled?

I have been advised this is all a little muddled, and I agree.

• IPA issues with Apple in the middle of OSA coming in to force
• OSA not applying to email, but OSA is not directly an encryption thing, probably.
• EU trying to do content scanning which means service providers having access to content.

I agree, it is muddled, and I bet that is intentional for some, but this is to try and say there is a way to chat, encrypted, with no scanning content, and no age checks, all in one, and easy to use.

More with E-paper

My previous code allowed a number of settings to be stacked up to suit all sorts of needs - a clock, day of week, sunrise/sunset, and even bin collection details.

I have started a new version now, at https://github.com/revk/ESP32-EPD

This is around the idea of a stack of widgets, each placed on the frame buffer.

This would seem a simple approach - and each widget can be positioned and aligned as needed. The idea is to have at least the same functionality as before, but allow me to work on more and more widget types over time.

So the basic widgets are:-

• image
• text (choice of two font styles)
• digits (i.e. 7 seg so cleaner in-situ updates on e-paper, intended for a clock)
• QR code

But even then it is not simple - I have some content substitutions to allow display of $DATE, $TIME, $DAY, $IP, $SUNRISE, $SUNSET, and so on. This makes a simple clock very easy to do.

Text

Whilst most of the above are simple, I have done a few extra bits - allowed multiple line text. Added some characters to 7 segment font to allow display of hexadecimal and the like, etc.

Images

Images were, however, a major change. previously I had full frame (for this 480x800) 1 bit per pixel (48000 bytes) file. Easy to make with some scripts. I also had some similar (smaller) icon files for the bin collections, but they need to know the image size to work.

I wanted more, and I wanted easier.

For a start, for E-paper, there are some more things I need from images.

• Would be nice if image file said size so I did not have to know in advance and users would not have to make images a specific size
• Would be nice to allow transparency, so one image on another can work without solid rectangular borders.
• Would be nice to allow not just black/white, but black/white/red for 3 colour E-paper.

None of these work for the simple 1 bit per pixel images.

So, for that reason, I have moved totally to PNG files (as per previous blog post). I have yet to code the black/white/red, but I can now.

Masks

One change I realised I needed was a plot mode - does text plot black background and white text, or just white text, or maybe just black text, etc. So I now have invert and mask operations on all widgets. 

Seasons

The system still has a season letter E=Easter, M=FullMoon, X=Xmas, etc. And allows that season code letter in the image url, so that works.

Bins

Bins (i.e. which bins to put out next and when) are the remaining widget to re-do. PNGs for the icons will make it way easier.  No need for fixed size icons and pre-converted images.

I plan to define a simpler and clearer JSON format and implement (and document) that first, but that will be soon.

More widgets

There are a load of obvious ones to add...

• Weather from an external weather URL, to show icon
• Weather to show min/max temp, maybe a $MINTEMP/$MAXTEMP or something. Adding ℃ to my font may be a challenge.
• Might be fun to add some sort of delivery tracking estimated time some how - but this means knowing tracking, and so on. Something too think about - a sign in the hall showing we expect a parcel would be really useful.
• I did previously have an SNMP uptime thing, I could add that back.
• Well, what else?

The nice thing is adding widgets is pretty simple with this structure, just more widget types in the config and the code to back them.

Confidence

This is one of those more personal blogs.

This week, well, started last week, I had a small technical challenge. The exact details do not really matter for this. But I'll explain.

I wanted to code something - something that was not quite readily available (some people had things very close to something I could just use, but not quite, which is where it gets fun).

The boring bit: It was a system to decode PNG image files, and allow me to use them in an embedded system driving a e-paper display. The details do not matter.

All that matters is that it was not easy to do - it involved understanding a detailed technical specification (PNG), and a new thing (zlib) which I had not used before. For a change the specification is a really really good one, which, in many ways, makes it easier.

Can I do it at all?

A biggie for me is should I, can I, even embark on this project.

To be clear, I have no reason to. Nobody wants this (well they may now), nobody needs this, nobody is asking for this, nobody is paying me for this. It is solely to make an e-paper thing I have easier to use. It is educational for me, a challenge.

Indeed, many of the helpful suggestions are to use a different file format, and not png. I do that already, but I wanted to make it simple - all can handle "save as png" I feel, so can I make it handle png. All and every format for png though?!

The protocol - the file format, which I literally sat in hot tub for over two hours reading, is good. But has some tricky bits. One is the compression/expansion using zlib, something I have never done.

I was seriously concerned I could make this work at all. Could I do it? Could I do it in a way that fitted in memory on an ESP32? Am I up to the job?

Yes I can!

I decided to go for it, in linux and then ESP32 code.

Each step worked well, and was not an issue. Minor changes as I coded. Lots of testing. zlib is easy, it turns out. zlib works on ESP32 too.

PNG has a lot of options, and as a decoder you have to handle them all. As an encoder you can be picky, but decoders cannot. I had to slog over the different options - make every one work properly.

In a day?

I spent a day, well, until early afternoon, and then a couple of hours next day. Total time under one day's work.

It works!

It went perfectly - the bugs were simple to fix. When I slept on it, all the remaining bugs came to me in my sleep, like they used to.

Not lost it?

So no, I have not lost it!

The work was not as easy as it used to be - younger me would have worked on in that evening and not next day. Younger me would not have made as many typos (way more since I had a stroke). But the results is good.

I worry about "losing it", and "imposter syndrome" all the time. I hope this is is a good sign I am not a losing the plot, honest.

Here it is https://github.com/revk/ESP32-LWPNG

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.

IronMan

The IronMan project has been challenging...

Basically, we know someone that does IronMan for events and parties, along with others that do Spiderman, and so on.

But the suit he has is somewhat failing - the original electronics failed a long time ago, and the reworks (no idea who did) also failed.

So this is at least third, or more, refit for this, but we have taken it on with some serious dedication I think.

The helmet

The helmet has a servo, to lift the visor, and LEDs for the eyes. We actually replaced the electronics on this twice - initially a simple LED controller, and then a more custom board.

The eyes are now WS2812 LED strips. so way more flexible, even if normally just static cyan.

One of the challenges was the current spikes from the servo - it killed LEDs. Big capacitors is the main fix for this.

The suit

The suit was also a challenge, and really, the stuff in there was a mess. Again, two stages, firstly a simple LED controller for the "arc reactor", but now gutting it all and replacing with custom controller handling multiple LED strips, and speakers.

The previous electronics had several primary cells, a rechargeable battery, and speakers and LEDs. But the speakers never worked properly apparently.

The new build takes a lot less space, is rechargeable, and lasts all day.

The gloves

These were especially challenging. The helmet and suit could accommodate a decent USB battery pack. But the glove are too small, so needed a design that could handle a small LiPo, and charging.

The previous electronics were a simple LED torch fitting and 9V primary cell. This was bulky, and just "lit up".

The new design is a rechargeable LiPo, and 88 RGB LED rings with diffuser, button, and repulsor effect.

Overall

The end result is nothing short of as complete revamp.

Less space taken in helmet, gloves, and suit. Rechargeable batteries in all, all lasting 8 hours. BLE linking so sound effects link to repulsor in gloves and helmet sounds.

At this stage there is concern the LEDs for the arc reactor and gloves may be too bright, and the speakers too loud, both of which can easily be adjusted.

Speakers

One of my concerns was the speakers, and I found these were the best. I tried 5 different types.

From PiHut, and really good.

They are glued inside the suit but sound awesome.

My son should have a video on it all soon.

Tindie so far

Well, the Tindie store is set up, and I am adding stuff.

https://www.tindie.com/stores/revk/

The basics

It is simple to use and way way way less hassle the Amazon. Amazon are a pain to make any change to any listing, often even refusing to do so for no good reason. Tindie, is simple, just works, changes are easy and happen immediately.

I am shipping, which is less ideal, but RM click'n'drop works well. I may be able to do more with APIs to tie things up more seamlessly in due course. As this scales up this will no doubt transfer to the sales team in the office.

Options

One nice thing is I can add sales options - which works because I am shipping to order. I did this on the coaster. Which diffuser to use, and if shipped assembled or as a kit. This would not work with Amazon fulfilment, obviously.

The costs

Works out around 10% in payment and Tindie fees. Pretty typical.

Getting paid

Payment via PayPal was a concern, especially as it looked a lot like I could not get PayPal to send me money without open banking crap (giving them access to my account!). However, we sorted the business PayPal account, and that allowed simple fast payment to the business bank account and did not appear to involve any fees, and seemed sensible exchange rate (Tindie is all in dollars). Looks like it is monthly, which is simple enough.

Looks like I have to go in to PayPal and accept the payment and then tell PayPal to send the money, which is a nuisance but not to much so on a monthly basis.

Paperwork

We need to work out VAT and paperwork, but simple enough to convert all to GBP on the monthly payment and generate the right VAT invoice matching the money that arrives - should keep HMRC happy. Again, this is where I may API it all and make it simple and seamless.

API

This is probably next step - make more streamlined for orders and paperwork. I'll write that up in due course I expect.