Dialling the gate

People will know I am a slight Stargate fan (!), and I like making PCBs. So, well... Latest is...

LEDs

First off, the LEDs. There is a very popular LED format, a WS2812B chip and RGB LEDs in a package. These use a serial daisy chained control channel allowing 256 colours of each of Red, Green, and Blue, to be loaded individually to a whole chain of LEDs. This design has 372 LEDs.

There are standard libraries to drive these, but I have discovered the ESP32 S3 is better as it uses DMA for the "remote control" hardware that is used to drive the data for these LEDs.

You can get these on tapes, and rings, and so on, usually 5mm x 5mm, or 4mm by 4mm, and I had even seen some 2mm x 2mm, but was surprised to find they are now available in these tiny 1mm x 1mm format. This ring design has a 100mm diameter centre hole.

They also usually need 5V power, but amazingly these small 1mm x 1mm modules work on 3.3V (or 5V), which is impressive (Blue is usually the voltage hog).

They are also very cheap. Part XL-1010RGBC-WS2812B, LCSC Part C5349953.

Alignment

My first mistake with the LEDs was making the layout simple, so a grid of these LEDs were one way up on one row, and the other way up on the next row. This allowed GND to be between two rows, then VCC between two rows, and so on. I put caps at the ends of the rows (which works well). This allowed me to pack them at 1.6mm spacing.

This was impressive, but I missed the (apparently well know) issue that the LEDs are placed within the 1mm x 1mm space, so for example Red is one side, and hence an all grid red looks like this, not evenly spaced.

They have to all be the same way around to avoid such issues.

Diamonds

I tried doing the same way and really a pain to track. The trick is to actually place them at 45 degrees, diamond style. This makes tracking really simple.

This allows a track at the top for GND, and at the bottom for VCC, and a link from LED to LED corner to corner for the daisy chained data line. Shown here I have vias for extra power. With thin tracks between the pads of the capacitors (expected to be one per LED) it makes for a really neat layout.

Grids

Grids were easy, and grids of LEDs like this are simple, with 2mm spacing (no caps), which is not bad. Caps added at end of row or column.

Apart from tracks joining VCC and GND top and bottom, or side and side, I actually created zone fills to make for thicker overall power tracks.

The latest design at 2mm spacing is 10mm x 18mm for a 5x7 grid, and allows them to be placed next to each other for a whole row at 2mm spacing, LEDs at the top and bottom of each column.

Rings

The other thing to do was rings of LEDs.

The principle is pretty simple, tracks (this time arcs) for GND, data, and VCC. Some zone fill for VCC and GND, again arcs (well polygons and lots of points).

Adding vias is fun, and I ended up with code that puts them off to one side if diodes and caps too close together (as above image) or in line in the GND/VCC tracks when enough space.

A simple ring with evenly spaces LEDs and caps is easy, but then I decided I needed some grouping of LEDs together with specific tighter spacing (the chevrons in the top image).

I also had to cater for the fact that power vias from one ring could clash with some of the next ring, and so omit some that were too close.

C code

If you have tried doing this in KiCad, it is far from easy - even with the grid locking and simple spacing like 2mm, it is hard, and making a ring with 39 LEDs, i.e. 4.6153846 degrees between LED and cap and LED, is, well, totally impossible. No chance doing it manually at all.

So, obviously, I ended up making C code, parsing in the PCB file, and moving LEDs and caps and making tracks and vias and fill zones. I have code for grid layout and ring layout now.

The gate

Working out the exact animation for the gate will need a bit of trial and error I expect - I cannot actually spin the symbols, so some poetic licence involved, but easy to "spin" the rings of 117 LEDs.

I have actually gone for a number of rings...

• 117 inner rings, this is 3 per gate symbol, so makes for a nice "1 in 3" spin effect and allows the inner to be lit up and made sparkly for the gate open.
• 39 gate symbol ring, so I can light individual symbols during dialling (seeing as they don't spin).
• 18 ring for bottom of engaged chevrons (9 chevrons, so 2 per chevron).
• 117 outer ring, again for spinning, but also can be two for chevron when engaged, and 3 for chevron end when not.
• Two 18 rings for chevrons getting wider.
• A 45 ring, so 5 per chevron, for the lights at the edge of the gate when selected.

I think making it dial will be cool. PCBs ordered, so a week or so (maybe more, some holiday in China), and I can post video of the real thing.

Open source

This is all open source, PCB designs and code, but if you want to buy one of these, and a driver, let me know. I have 5 on order.

Setting the temperature

My air-con can have a temperature set and aim for it.

• It has a wide range of ± a few degrees which I don't like.
• It is not setting temperature by me, it is basing it on some sensor it has.

To fix this I have used an environmental sensor - on my desk, and for my bedroom, on my bed head. I then control the air-con - telling it I want it higher or lower than it thinks things are, so as to aim for the right temperature by me. It works well most of the time and keeps the temperature very close.

That is my bedroom, last night (cooling), units in ℃, so maybe ±0.2 ℃ at most. Good.

I also have radiators for the winter, and they have the same fun, driving the valve on the radiator with some prediction.

Which to use for heating? air-con (heat pump) or radiator... Bearing in mind some of the house does not have air-con, so has radiators anyway. I don't actually know which is most cost effective / efficient. But I can choose. Have systems in place to make sure they are never fighting each other :-)

Per room radiator control

One of the key things is per-room controls - this means a temperature sensor in the room, and a radiator control, and some way to tell the boiler that one of the rooms needs heat. We have two heating loops (up and down), my daughter has two (left and right!). But for each radiator there is one boiler control that is needed.

The hard way

So, the hard way, I have my fancy environmental monitors with a display. They have a config for temp targets throughout the day. I have systems to override for empty rooms. Using the light switch marks a room in use for the day :-)

They talk MQTT to a Shelly running Tasmota that controls the radiator. So needs an MQTT broker.

The Shelly talks MQTT to a FireBrick to say radiator is on/off.

The FireBrick has a set of profiles, and any one in each loop will cause a message to another Shelly running Tasmota to operate the heating loop valve.

This triggers the boiler as needed.

It works.

It is not cheap or simple - the env sensors cost, the FireBrick costs a lot.

The easy way - maybe

So I am working on an easy way - my daughter happens to have a FireBrick, but even so I am trying to make a really easy way to do this. Not all of my kids have one (?!).

The first step is the reference temperature. A sensor that can be placed sensibly, e.g. by a bed.

I had found some nice industrial (BlueCoinT) ones at €31, but now have found, thanks to a recommendation, some stupidly cheap ones on Amazon. They are only £9, and even cheaper on AliExpress. They can be refreshed with sensible code.

The next step is controlling the radiator, and something like a Shelly Plus Mini would be ideal. Not sure of price yet, but the normal Shelly Plus 1 is £16.49. Whoa, they used to be less than that! Interesting. The Mini may be less. We'll see. But up to under £26. The radiator control itself is something like this, £19.63

So yes, we are up to £45 per room. A few more £s for back box and fused spur box for the Shelly mini by the radiator. And one Shelly at the boiler.

The comms can all be BLE. Sensor to Shelly, and Shelly to boiler control Shelly. Just needs a bit of software.

Not ideal, but £50 per room for exact per room heating control is probably quickly worth it. Simple web interface (or maybe even HomeKit) for unoccupied rooms, and controls for times of day and target temperatures via a web page. This can quickly save on heating costs and make things more comfortable.

It always amazed me people ran their house with one thermostat on the wall in the hall.

What counts as R&D?

One of the things a company can do in the UK is claim some tax benefits for spending some of the company resources on R&D. It is an incentive for companies to do R&D.

As a company that does a lot of R&D, we work with a really good agency on this, and get some tax credit. This works well, and is indeed an incentive for us to do more R&D.

This year the rules have changed slightly, and I noted a couple of them. It is all a bit open to interpretation, but a couple of the points seem a bit odd.

Open source

For a start, if we, as a company, did some purely open source stuff that was not direct benefit to us - by way of giving back to the open source community, it seems that would not qualify for R&D tax credits. It has to benefit the company. Thankfully this is not really a problem as pretty much all of the open source stuff we do is used in house and so benefits us directly as well. Some of the stuff we don't use in house, is actually stuff we then make and sell, so a benefit to us. But it is a disincentive for doing something purely open source.

Super human engineers

The other one that is odd is that things are not R&D if they would be apparent to a competent engineer in the field with publicly available information.

Well, we employ competent engineers. everything they do is apparent to a competent engineer. It almost sounds like, to be valid R&D, we need super human engineers, which seems a bit much.

We had a lot of discussion on this - one thing is the "publicly available information". This has meant we have focused a lot on things where the publicly available information is wrong or incomplete. And notably where what was "apparent" to the competent engineer was in fact wrong when tried.

Though one other aspect is that we think we can validly say that anything we are doing based on closed source designs and code is something that qualifies because that closed source is not publicly available information. None of it would be apparent to our competent engineers without access to that closed source information. So again, this seems to be discouraging open source.

Even so, the end result was a good meeting today, and plenty of R&D work.

Amazon done wrong

We sell on Amazon, and for that I'll apologise at the start, but it does provide some convenience to some customers and mostly works.

A few weeks ago we got an email saying we have to upload dome documents or they will close the account, and several ongoing reminders. Oh shit...

The problem is that the staff, including me, have a login to the seller account and can do 99% of things on it, as needed, but we could not do this as it had to be the main seller account. OK, so log in to that. Easy.

Except it wants to SMS a number to one of two numbers. Both were set up (and so worked at the time), but are 01344 (i.e. landline) numbers, and between when set up and now Amazon have obviously fucked up their SMS stuff and cannot SMS either.

The interworking of SMS really is a shit show and needs OFCOM to actually do its job and ensure it works properly.

But they also for calling them with a code - yay - except that also does not work - no clue why. Both numbers valid for SMS and calls, and they do neither.

So I tried the "remove 2FA" and sent pictures of passport, or something. My accounts manager did the same several times. No joy.

Every single chat was just crazy, and got to being daily. I mean I am tempted to publish them - they are so mad. One of them insisted I wait 24 hours after trying before contacting them - I said I had done that - he asked why I did not contact them after waiting 24 hours - and I explained I did - this is me contacting them!! The chats were like that. I don't like to judge people as "stupid", honest, people are only sensible in the areas they know, and that applies to all of us. But really, these chats were "special".

Just to be clear - the only reason I could "chat" at all is I had a working amazon account from which to chat. If not I would be screwed.

I have my case handled and referred to these, all of which did not reply at all!

• Internal escalation team
• Account recovery team
• External escalation team

I finally got someone that insisted that another "remove 2FA" should work, and I tried it, and, well, it did. But the instructions were clear - once done I could log in with just a password.

This was a lie. I logged in, and it said "Enter verification code. For your security, we've sent the code to your phone ***-***-**23" which basically means 2FA, so not removed, but also a number I don't know. Not either of the two numbers before.

Many more chats. No way to progress this. Doing the "remove 2FA" again stalled as it needs the code sent to *23 to get as far as uploading a driving licence even. I kept on, emailed in again, and finally it changed.

Now I have option for OTP by email or by SMS to *23, yay, but then it again does "Enter verification code. For your security, we've sent the code to your phone ***-***-**23" as well. So email and SMS now! (yes, when I got SMS working it wanted email too, so yes, both now needed!).

Had there not been an actual mobile *23 I really think we would be screwed. They have zero way to sort this from what I can see. Removing 2FA is "still do 2FA using a *main* mobile number" which you cannot change until you log in!

Turns out, after some research, checking staff lists, and pestering someone on leave and at a party (really, thank you Mike), I found someone that had a number ending in 23, and they were indeed what was on Amazon. So they let me know the code. Yes, that is being fixed, they should not have been on the main login, really. History from when first set up.

So finally I am in - it took a couple of attempts, but now the 2FA is sorted.

Phew.

So back to step 1. What is it they need.

Well this...

Yep, it is a sort of Farage test I think!

Obviously I click Agree and submit.

And, well, predictable...

So, err...

So another chat, and really, I am at a loss on this chat...

Ok, long winded, but basically no clue why this was an issue "not understandable" somehow, and actually, no, there is no way to upload a screenshot.

Eventually got an email and replied with a screenshot. It is a "don't reply to this" email address, FFS.

LIGHT HAS A SPEED - SO WHY NOT DARK?

I was looking at today's xkcd, and am reminded of a Terry Pratchett quote: [The science of Discworld, Terry Pratchett, Ian Stewart & Jack Cohen, ISBN 9780091886578, chapter 22 "Things That Aren't"]

LIGHT HAS A SPEED - SO WHY NOT DARK?

It's a reasonable question. Let's see where it leads.

In the 1960s a biological supply company advertised a device for scientists who used micro-scopes. In order to see things under a microscope, it's often a good idea to make a very thin slice of whatever it is you're going to look at. Then you put the slice on a glass slide, stick it under the microscope lens, and peer in at the other end to see what it looks like. How do you make the slice? Not like slicing bread.

The thing you want to cut - let's assume it's a piece of liver for the sake of argument - is too floppy to be sliced on its own. Come to think of it, so is a lot of bread.

You have to hold the liver firmly while you're cutting it, so you embed it in a block of wax. Then you use a gadget called a micro-tome, something like a miniature bacon-slicer, to cut off a series of very thin slices. You drop them on the surface of warm water, stick some on to a microscope slide, dissolve away the wax, and prepare the slide for viewing. Simple ...

But the device that the company was selling wasn't a microtome: it was something to keep the wax block cool while the microtome was slicing it, so that the heat generated by the friction would not make the wax difficult to slice and damage delicate details of the specimen.

Their solution to this problem was a large concave (dish-shaped) mirror. You were supposed to build a little pile of ice cubes and  'focus the cold' on to your specimen.

Perhaps you don't see anything remarkable here. In that case you probably speak of the 'spread of ignorance', and draw the curtains in the evening to 'keep the cold out' - and the darkness.

It occurs to me that it would surely work as you would expect. Whilst you cannot focus cold on to something, you can cover part of the area that would radiate heat from the environment to something with a mirror, and that mirror pointing at ice cubes means that not as much heat is radiating from the ice cubes via the mirror to the target as would be otherwise. But heat from the target is radiating to the ice cubes that absorb that heat. The net flow of heat would be from the sample to the ice cubes for a large chunk of the area surrounding the sample.

But this would mathematically be the same as considering cold radiating from the ice cubes to the target via the mirror. I suspect the maths works out exactly as you would expect for focusing cold just the same as it does for electron holes.

Yes?

ESP32-S3-MINI-1 GPIO

I now have a few boards, including a general test board...

The ESP32-S3-MINI-1 has 39 GPIO pins, though the data sheet defines that one (GPIO26) is reserved when using PSRAM (e.g. ESP32-S3-MINI-1-N4R2).

Unlike the S1 boards, the GPIO are all available as input or output, making its very flexible. But as always there are some caveats on GPIO usage.

The following relates specifically to the ESP32-S3-MINI-1 module only.

Restricted use:

GPIO0

GPIO0 is the main strapping pin that defines BOOT mode. If low at startup the device enters boot mode. It is pulled up internally so can be left unconnected. This means you cannot use this as an input if there is any chance of the input being low at start up. It can be freely used as an output.

By far the most common usage for GPIO0 is connection to the cathode of a status LED.

GPIO19/20

By default these are USB. This may make them not ideal to use for inputs. Note that they can be configured not to be USB by a fuse setting, but will be USB on an unconfigured module. As such it is probably best to use for USB.

GPIO26

The cannot be used with a PSRAM module, e.g. ESP32-S3-MINI-1-N4R2. It can be used if not PSRAM, e.g. ESP32-S3-MINI-1-N8.

GPIO43/44

By default the boot serial console uses GPIO43 and GPIO44. This means GPIO43 is configured as an output at start up. There are settings to stop any actual output on this. This means it cannot be used as a driven input without at least a resistor to handle the clash at startup. GPIO44 is an input so can be used for any purpose without any problems generally.

GPIO46

GPIO46 only matters when in BOOT mode (GPIO0 low) and in such case must be low. It is pulled low by default so an be unconnected. But do not use this as an input that could be high at startup in BOOT mode. It can safely be used as an output.

Caution:

GPIO3

This is defined as a strapping pin, and is floating by default. However it is only relevant depending with some specific eFuse settings related to JTAG operation. When using the default USB JTAG working, this pin can be used as a general input or output.

GPIO45

GPIO46 impacts the voltage used for SPI, but depends on EFUSE_VDD_SPI_FORCE. But this efuse is already set by default on this module, which means GPIO45 is ignored. It can therefore be used as an input or output.

Serial or USB console?

The S3 modules have two ways you can operate the console - the normal serial (UART), and USB.

USB

The default USB working is as USB JTAG and Serial console. This allows flashing and debug console, and a lot more debugging using JTAG and OpenOCD. This is by far the simplest way to manage the module and what I would recommend.

In most cases my boards have USB, either a printed tab for USB-A or a USB-C connector, but in the rare cases they do not, it is simple to include a header for USB to work with a lead.

This nicely fits under the module itself, with no vias, so takes no space and so no component cost. I deliberately spaced as 0.1" header and with a polarity to avoid confusion.

Apart from using JTAG, the USB serial is not really serial, so is way quicker for flashing code than using the real serial port.

There is one small snag...

It is possible to use an efuse, and more importantly, it is possible for the application to turn off the USB pins. This can even be inadvertent (I have done this, loading code for a different board which had an LED on GPIO19). This then means you cannot use the USB port at all, so cannot reset or load code or anything.

For this one reason, it is always useful to have a fallback.

Serial

The other approach for flashing and console is the conventional serial port. For this you need to have at least Tx and Rx (GPIO43/44) pins, and boot mode (GPIO0), and a means to reset (EN). You could use power on as the reset and keep it to just 5 pins. I use a header that works the same as the Shelly 1 and so can use my Tasmotiser board.

This also fits under the processor rather nicely with no need for vias, and no component cost. In fact, it can fit under the processor along with a USB header...

ESP32-S3

I have worked through a few of these processors - starting with the ESP8266. I moved to the ESP32 quickly and have not looked back - initially with the WROOM module (which can be hand soldered), to the PICO module (which is smaller and needs solder stencil and paste).

But finally the ESP32-S3 (version 3 of the silicon) is available as a module, the ESP32-S3-MINI-1, so I am finally starting to use that. The fact that the ESP32-PICO-MINI seem to suddenly be out of stock, seems like the time to upgrade designs.

The S3 has several improvements which may be useful.

Size matters

A key difference is size. The ESP32-PICO-MINI (i.e. S1) is 13.2mm square plus antenna, but the ESP32-S3-MINI is 15.4mm square plus antenna. So 2.2mm wider and longer.

For almost all of my designs this slight change does not matter, and indeed, for some the other changes actually make things smaller. There are exceptions - the module to go in to the case of a Galaxy keypad may be too big as there is very little space.

However, there is one useful side effect of this extra size. I have a small 5 pad footprint for serial programming - it uses the same 5 pins as the Shelly, and is pretty much the minimum you can have for serial programming and debug (see on image above on the right of the components). Now the module is slightly bigger than can actually fit behind the module, so effectively taking no extra space on a single signed board. This is one of those small details that saves space - e.g. the design show above is now a couple of mm shorter as a result.

General purpose I/O

Another change is the GPIO. The S1 modules have fewer GPIO (27), but several of them are input only - all of one side of the module has no output GPIO. There are also a number of NC pins.

The S3 has more GPIO (39), and all of them are input and output. There are no NC pins (apart from GPIO26 when using the PSRAM based module). This means all three sides of the module have lots of usable GPIO. This is perfect for tracking as you can easily track to the nearest convenient GPIO, which saves space.

USB

This is where it gets both interesting and slightly disappointing.

The S3 has USB built in, so direct connection of D- and D+ pins to specific GPIO. It can be disabled, and it can be used in s/w as USB server or client side as needed, which is very cool. This saves space on many designs if no UART needed.

The default, starting point, is USB JTAG with USB serial. This appears on my Mac, for a totally un-programmed module, as a USB serial port. I can connect to it and see the boot loader serial output. This is excellent as it means I can use a much simpler interface to the module - no need for a UART. As many of my modules have USB for programming and debug, this makes it a lot simpler.

However, there is a snag, it seems. Whilst this works as you would expect as a serial console port over USB, it seems it does not provide the normal connection for RST to reset, and DTR to boot mode (GPIO0). So you can only really use it to load code if you have a button for GPIO0 and RST on your board. This is a lot of board space, and really is silly.

 UPDATE: I don't know what was wrong with my first test boards, but this is working, so, all OK! I think perhaps I simply had out of date tools on my Mac (e.g. esptool).

Now, there are a few rays of sunshine.

1. It seems when un-programmed it does work in boot mode and so can be flashed, even though no RST or DTR working. That said, it seemed oddly intermittent, so I plan to do more testing on that. It may mean I can use USB for the initial loading of code and fuse settings.
2. Obviously as a USB JTAG interface it may be that there are ways to force a reset and boot mode or load code over JTAG, but this is not obvious from the documentation. If I can work that out I can make boards which do not also need my 5 pad serial header, which is what I was aiming for.
3. It is possible to internally detach this USB JTAG/serial and run USB from code in the module - this can handle code loading as a feature you compile in it seems (though even that suggests GPIO0 needed - why?!). I have not sorted that yet. My main concern is that if the code in the module does not have this, or is crashing, or whatever, I will have no fall back unless I have my serial header.

So more to do, and any help welcome. If there is a fallback for the USB JTAG working that allows code loading without having to do GPIO0 and reset, that would be really nice. For now, I'll keep my 5 pad serial, under the chip itself, as a fallback.

In theory OpenOCD is loaded, and should work for the JTAG. No idea how to use that yet, but that is a different matter as it does not work - some obscure error which sounds like a libusb issue on modern Macs. Arg!

Security

One small concern - JTAG is usually a very powerful interface on a system. If the chip is left with USB JTAG set up, perhaps because that is the only way to load code sensibly, it may also mean it can be controlled such as to allow secure boot and flash to be accessed. I.e. single stepping code after loading, etc. It may be that for security it needs the JTAG USB disabling (a one time e-fuse setting). I need to investigate. As a whole my security threat considerations have generally be based on physical access being a reasonable challenge, as the serial interface represents a similar risk in some cases, but it depends on the application.