Laws

When I was growing up, I learned that there were laws.

These were not simply rules or views of people like my parents or teachers, but something more. Laws were things that somehow defined the moral, and immutable set of rules for life. If you broke laws there were police that would take you away and lock you up.

Over time one realises that laws are not quite so concrete. For a start, they change, and new laws come in and old laws are repealed or changed.

The idea that something today may be illegal tomorrow, or the other way around, is crazy. It is how it works, but that is, well, just mental, how can a thing change from "right" to "wrong" or "wrong" to "right" just because we have moved on in time?

What I later learned is that these laws we all follow are created by, well, just people. And they are not people that have a lot of training, and learning, and credentials, and academic achievement or qualifications in their field. They are created by people that happened to win a local popularity contest in their constituency, working with others that have the same credibility. There is no qualification needed to make laws. There is no test. There is no exam. You literally have to win a local popularity contest to be an MP, and MPs can literally make new laws.

That, in itself, in insane, sorry. I mean some of them are sensible, and some even qualified. I have known some MPs that seriously know what they are doing. But "running the country" and, importantly, "making laws" has no qualifications needed. It is amateurs that won a local popularity contest, that is it.

So is there a better system?

Environmental monitoring

The new Faikin Remote have sold a few, nice. Thank you. Now on Tindie, and more coming soon. The BLE linking to Faikin is working really well now.

But ironically more have sold not as Faikin Remote, so far, but as environmental monitors. The boards have pressure, temperature (via many means), humidity, and CO₂.

What is even more amusing is that the monitoring is probably best done using my generic display signage code (EPD) as it has all the sensor code to allow display of the values. No link to Faikin, but links to Home Assistant, and simple http polling, and so on, for all sensors.

Irony on top of that is I have had to just make a version of my display code for no display, a blind version, as it is ideal for this monitoring application even when you have no display (data centres, etc).

Home and office monitoring of CO₂ levels is becoming more important as people realise how much of an impact a lack of fresh air really has.

Faikin Remote

We have done a lot of small PCB designs over the years, but by far the most popular is my Faikin board. Reports are that even Daikin have recommended it to people wanting Home Assistant integration! It allows control of a lot of Daikin air conditioners over WiFi, MQTT, web, and Home Assistant. Constantly improving, and easy to use with local working not cloud based.

My latest design idea is a rework of a previous "environmental monitor", but specifically targeted at the Faikin users. The concept is that it can be a display and control for the Faikin. Whilst some ducted Daikin have a wall mount control, it is not cheap, so this would work with those and the more typical wall mount Daikin that do not support a wall mount display.

Key functions would be:

• Display current state of air conditioning unit.
• Allow change of key settings (power, mode, fan speed, target temp).
• Remote temperature sensor to allow room temp to be referenced at the controller in "Faikin auto" mode.

But the idea is the board can work with no display as reference temperature or just an environmental monitor for Home Assistant without a Faikin involved.

This is the current board design.

The expensive CO₂ sensor would be optional as it adds over $20 to the cost. Both the tab for it, and the 5 way joystick button, could be snapped off for a purely display or monitoring application.

A Waveshare 2" display fits on the front. Full colour 240x320 pixel. It is designed to fit the header so it can be removed if needed to access WAGOs, etc. The display adds another $20 at least.

User interface

I want to make the user interface simple - anything beyond the basic controls for the aircon you have to do via web interface. That should make it easy to use.

The idea is a joystick allows change of target temp (up/down) or switch to other setting (left/right) and change of mode and fan speed, as well as simple push on/off.

Bluetooth

Whilst it can all work over WiFi and MQTT, my plan is to link to Faikin using BLE as well, both ways. So Faikin reports mode/status, and this advises control and current reference temperature. This should make it extra robust with no need for WiFi or internet to continue working. The plan is a simple announcement BLE, not a connection, much like the many cheap BLE temperature/humidity sensors that exist.

Sensors

The current set of sensors include:

• MCP9808 Ambient temperature sensor. This is highly regarded as a good temperature sensor.
• VEML6040 Ambient light sensor (with a night mode to turn off display) including colour.
• GZP6816D Atmospheric pressure sensor, and additional temp sensor.
• SCD41 CO₂ sensor, with humidity, and another temp sensor. This would be optional.
• DS18B20 connection 3 pin WAGO for more temperature sensors.
• Detecting remote BLE temperature sensor.

All of these would report to Home Assistant as needed, and also report control and one reference temperature of choice to Faikin.

And yes, too many temp sensors, so system will allow a config of which are used and per sensor offset (to allow for heat via PCB). I may even allow averaging of multiple sensors. It will be interesting to see how this all works. DS18B20 are great for adding an "outdoor" sensor to report to HA as well. 

Generic signage

My existing EPD app which is general signage will be extended to handle the sensors as things to display so this can be simply used as a generic environmental display (and HA integration). Indeed this is likely to be the first code I do for these new boards, without a Faikin link.

Packaging

The basic board needs to be sold with and without the SCD41 CO₂ module. The board is likely $30 and the SCD41 adds at least $20 to that, probably more like $30. Not everyone wants CO₂ and humidity. The fluctuating value of the dollar is a pain in this all.

And then I may package with Waveshare 2" display, 8 way 0.1" pitch header, and extra M2 screws. This is likely another $20 or even $30.

Maybe even with DS18B20 sensor as an option. These are quite cheap.

I am not sure I want to do 3D case printing, but I plan a number of STL files.

Tindie makes such options simple, so that is likely the main sales channel initially. We'll see about Amazon as well. Those with A&A accounts will be able to order direct as always.

Update

The first boards (no button) have arrived. I have decided I'll try the TI TMP1075 as an alternative temperature sensor. In practice it seems a DS18B20 is best as it is separate from the board, closely followed by the SCD41. The MCP9808 (and presumably the TMP1075) suffers from some local heating from the PCB. The GZP6816D is close to the ESP32 and so not good at all for temperature (it is there for pressure). The T6793 CO2 sensor is not good, gives silly values (yes, I checked, and this is not a driver error), is bulky, needs 5V (does not work on 3.3V) and is actually not that much cheaper than the SCD41. The VEML6040 light sensor works well, but is a fun exercise for the casework.

Comments

All comments welcome.,

One Time Pad (again).

I did a video 7 years ago: Uncrackable Pen & Paper Cryptography

It had several comments, many of which seemed to think there were ways of "cracking" it. There are not. Having got a comment recently, I did another video, OTP.

Wikipedia explains its quite well. It explains your cannot crack it if :-

• The key must be at least as long as the plaintext.
• The key must be truly random.
• The key must never be reused in whole or in part.
• The key must be kept completely secret by the communicating parties.

Even so, people still comment, and a friend of mine just posted...

"Rev, set a challenge on your blog first to decode message without a key wins a firebrick dragon?"

"I would have thought brittle[sic] force decode first 4 chars and wait till it looks like a word."

I really thought I had explained it, but clearly not.

The short version is YOU CANNOT CRACK IT!

In my second video I tried to explain this by dumbing down the message to just 0 or 1, with two possible keys, 0 or 1, giving a possible encrypted message 0 or 1.

Now, imagine you intercept my message and it is a 1

You can BRUTE FORCE try every possible key:

• Key 0 means message was 1
• Key 1 means message was 0

So what was the message? You don't know. You have no way to tell.

You don't know because every possible message, no matter how meaningful or meaningless is possible with a key, with equal probability of being the actual message.

The "I would have thought brute force decode first 4 chars" misses the point - you can brute force to make every possible first 4 letters, with no clue which of those is correct or even more likely.

And just to be clear, even if you know the first 3 letters are ANX (Ref Enigma) that does not help you because the key for those letters has no impact on the next letters (unlike Enigma).

So let me try and say it again, YOU CANNOT CRACK IT! I suggest reading the Wikipedia article.

Back to LCD

My graphics library has undergone plenty of improvements for the e-paper work, but now I am back on LCDs. These have extra challenges, because they have colours and shades.

The main reason is new environmental sensor boards with LCD.

This means I need to anti-alias text, digits, lines, circles, etc. Previously I had pre-rendered 16 level fonts and icons. But I have moved away from pre-rendered bit map fonts in my latest e-paper code already.

I have gone through several approaches to this. The fact my fonts are vector based previously allowed me to just draw lines and circles on the e-paper. That is fine when over plotting is no problem, i.e. white on white is white.

But if you want to anti-alias you have to over sample, e.g. a 4x4 matrix to then know how many pixels are set (0-16) and use that to control alpha blending of existing pixel and new pixel (or background pixel and foreground pixel).

My first approach for fonts was to make code to allow me to tell if a point x,y is plotted or not - so instead of actively plotting dots (circles) and multiple lines that over lap other lines and dots, I have to do the maths to work out "is this point within a dot" and "is this point on a line". The dot is easy - simple Pythagoras. But the lines was more work - I can work out distance to a point is within stroke width using squares. Working out end of line is harder, so ended up working out the point of perpendicular intersection so I could range check end points and then check distance using squares.

It worked, and allowed me to over sample 4x4 and work out grey levels.

A better way

The problem with the above is the 16 times processing of points. So I came up with a new plan - scan lines and run lengths.

The new logic scans the character top to bottom to determine the left/right for each line or dot that is in the character at that scan line. This is actually quite easy for a dot as I can use a look up to get the left/right for any point on a circle and scale. The line is a rectangle, and the fact it is only ever horizontal, vertical, or a 45 degree line means I don't even need square roots to work out the points, and simply work out the left/right for the specified Y scan. It is simple to merge overlapping runs on a scan line and the max runs is low as we know how the font works (up to 6 ranges).

This means only 4 times the processing of non anti-aliasing, as opposed to 16 times. The runs can then be worked out 4 scan lines at a time and plotting a sequence of the same grey level. The same logic works for anti-aliased or not, just not 4 times over sampling on the Y axis when not anti-aliasing.

7 segment digits

The 7 segment digits are not simple lines and dots, they are a complex path (original in SVG), but it is easy to render and run length encode the scan lines for a single large 7 segment digit (well, 9 segments with colon and dot). I can then scale which lines I extract from this large image to make the same run length logic as I do for the vector fonts and use the same run length plotting code.

Lines and circles

Another primitive is lines and circles, and whilst arbitrary angle lines do need one fast integer square root to get the corners, converting to run length on scan lines is, again, simple, and can use the same run length plotting code.

The same is true for a circle, using the same circle lookup table (with interpolation for a larger circle than the table).

Even faster

All of the above still comes down to pixels, but there is a simple important step I have now added to that. I made the pixel plot primitive have a horizontal run length parameter. This allows a number of checks and memory access and so on to be worked out once, and then a simple loop to apply a run length of pixels plotted the same. When plotting 100% alpha it is extra quick as no checking of existing pixel and alpha blending. It can be a simple loop incrementing memory address. Having all of the primitives for fonts, 7 seg, lines, circles, and so on actually convert to run length makes it easy to use such a primitive.

QR!

P.S. Yes, everyone knows I am a stickler for accurate valid QR codes, but I have in fact gone as bit mad with an option here - the targets are 100% correct but the pixels are circles. This is because of the way QR codes are decoded hitting the pixel centres (having found the targets to get accurate alignment), so this should always work whilst having a subtly different aesthetic. I think it is better than some of the other QR code abuse, but it is an option on my EPD code.

More on e-paper

I have learned some lessons, so sharing with you.

The 7.5" e-paper are fun, I have loads of them with the nice laminated glass and black border to sell, plug, plug!

But the story of making e-paper work is not simple.

Software

This I am good at, and the latest code allow a range of widgets and extracted values to be displayed in various ways on the display.

Hardware

This is where I am also always learning. To explain, even in software, where I have being doing this for what 50 year, and have a degree, even now I learn lessons.

But hardware is more challenging for me - my formal training is less, but not nonexistent.

But the real challenge is the turn around time - software I can recompile and try in minutes - hardware is days or weeks to try out as a proper PCB, days if I solder and don't have the components yet. I have done milled PCBs which make that easier in a way, well, quicker, at least.

Symptoms

So..., what happened? The issue was with the larger 7.5" e-paper displays which I have used for years - I have on my doorbell display and my fridge. There is one at the Indian restaurant and two at the pub. They work flawlessly.

What happened is trying one for some other people, and they wanted a displayed image, and that created "smearing" over the display. It looked shit.

It seems some graphics, and I have concluded it is those with a lot of black/white transitions across the display line, break down in an odd way.

The fix?

I assumed it was me, and did loads and loads of tinkering with different LUT settings, and temperature compensation settings and VCOM calibration settings and all sorts.

I got it working OK, but it created a new problem!

Fading and burn in!

It is not actual "burn" in as such but it has the same effect - a lingering image. What is worse was random fading - even 1 minute updates would fade away showing burned in images within seconds. But only some times.

Two factors - one was not doing a POF command, and that creates massive burn in within hours. Even now, at the right angle, on some of my test panels, I see that I tried this on "MONDAY". Do not do that ever!

The other is the LUT was working to push the KK and WW frames a lot, and that left the panel in some state with a charge that meant any change could leave this fading effect.

The effect would eventually dissipate if the display was constant but it could take hours.

This was clearly not the fix I had hoped for.

Henry

So what was the answer? Well, if resistance is futile, inductance is king!

The boost circuit I was using was based on a known working design and used a 10uH inductor. But that was for a watch, a small e-paper display.

The reference circuit Waveshare do has a 68uH inductor. I tried that, it helped massively.

But testing showed that bigger is better! So now it is a 470uH inductor. And that is amazing.

I can do normal changes and updates with no smearing effects in any way. My fudged LUTs still break, and make a fading effect but they are not needed - I can do simpler LUTs and not have issues.

The results are amazing - I can do a non flashy update which is not causing burn in and full updates that work. I have applied the Waveshare v2 panel LUT for full (fast, flashy) update as well. It does full "flashy" updates a lot over night to try and clear any unwanted charge, just in case.

So finally I have cracked my months long e-paper headache.

If you got one of my older controllers you may not even see a problem - it only happens with some graphics, but if you have an issue the fix is a simple component change - ask me if you need a new 470uH indicator sending.

Do I have to pay council tax?

Apparently I have to pay my council tax by CASH monthly...

This is a shock, honestly! I would normally pay by bank transfer for whole year up front.

But OK... Except.

Err, OK, so do I have to turn up each month with cash which they cannot accept?

To be fair, if that saved me over £3k a year in council tax, I'd do it. I'd video record each attempt to pay, obviously, for a judge if they tried to take me to court.

Apparently "Cash is the default payment method that the council tax system uses for payments other than direct debit. This does not mean that the payment has to be made in cash."

As they seem confused, I have asked...

We'll see.