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.

Don't use UPS

I know I said before, but this is an update on the saga.

Executive summary

• I had 4 parcels sent from China (same sender) via UPS, all marked with our VAT and EORI.
• UPS tried to charge a fee, it seems contrary to HMRC advice they do not do Postponed VAT Accounting by default.
• I refused delivery and they confirmed return to sender (I confirmed the rest by email), but only sent 3 of the parcels back.
• They told the sender the missing parcel had been disposed off.
• They told me the missing parcel had been abandoned because "the sender is not served by UPS", something that is clearly a lie.
• They have invoiced for VAT (and an un-agreed disbursement fee) for all 4 parcels, and then late payment penalties.
• It has taken over 6 weeks for this to get close to being resolved.
• Use DHL, or maybe FedEx. Don't use UPS!

Postponed VAT Accounting (PVA)

I've explained PVA, but basically a VAT registered business getting overseas deliveries should get them without paying a fee if the sender includes the VAT/EORI when sending, that is HMRC advice to couriers. It gets declared on import and we (recipient) get paperwork from HMRC to ensure we account for it and the reclaimed VAT on next VAT return. Simple, easy, no admin fees, no delays.

• DHL manage it - not problem
• FedEx manage it - usually - not always - but seem to cave when pointed out.
• UPS want a separate signed agreement with us and the sender, and extra paperwork by the sender on every shipment. No way random foreign senders will do this. It is just, in my view, incompetent. Senders know to do VAT/EORI, but not extra UPS paperwork.

What did they do wrong?

I did try a parcel via UPS and it all worked well, but the good value of the parcel was $2, one of JLCs super discounted bare PCBs. That arrived, no fees, no invoices. Surprising. That lulled me in to a false sense of security and 4 more orders were shipped using UPS. Big mistake.

First arrived and driver wants a fee paid, I said no. I actually include the VAT on the address as an address line as well as on the waybill so I pointed to the VAT number on the label and explained it should be PVA. He had no idea, and literally threw the parcel back in the van.

Of the 4 parcelled, one other was tried and my wife rejected it. On that occasion the driver was very used to such things saying loads of people reject parcels with fees - usually because they paid fees to sender to handle and UPS cocked up (slightly different to out case). This really says something of UPS's competence.

The tracking showed each of the 4 parcels having multiple refused deliveries, this was clearly a lie. Not their first.

They took weeks to send 3 of the parcels back to sender. I guess they can take as long as they like. But when only 3 arrived we asked questions. They told the sender the parcel was disposed of. This was a lie, what a surprise.

They told me it was abandoned. It took weeks to get the explanation that "the sender is not serviced by UPS". This is a lie, wow.

They sent an invoice for the abandoned parcel (VAT and disbursement fee), which is not valid, obviously. I checked the HMRC import records and they only recorded (and hence paid HMRC) for the other 3 parcels. They were charging me for VAT they apparently have not paid HMRC. That sounds really fraudulent to me.

They sent invoices for the other three, even though returned to sender.

They kept quoting their terms and conditions that they can basically lose or destroy a parcel and not be liable to anyone. Wow! I have repeatedly had to explain that I am not subject to their terms and conditions. I have not agreed them. I am not a customer. I have no contract with them.

I have explained that if they have appropriated my parcel, that is Theft, a criminal matter. If they have lied ("sender is not served by UPS") to do that, then that is Fraud, a criminal matter. I was getting nowhere.

Surprise!

To my utter shock, they sent back the missing parcel to China. It arrived there after many weeks. The UK UPS contact seems unaware of this?!

But then, I get an invoice for late payment penalties - even though I have no contract with them that could lead to such penalties. Even statutory late payments penalties are a statutory contract term and don't apply if no contract. This is verging on harassment.

They have, eventually, cancelled invoices and late payment penalties. I have not seen any attempt for them to correct the HMRC import VAT reports though.

Update:

We are late March now. They are no longer chasing invoices or late payments, but would not accept that late payments are invalid and they should refund every customer (late payments are statutory as part of a commercial contract which does not exist in this case).

But they are now hassling JLC, the sender, saying a parcel is stuck in customs awaiting payment of duty. It is almost tempting to pay it and then claim damages when they fail to deliver the parcel (the one they sent back to China months ago).