Hackspace access control

I'm a trustee at East Essex Hackspace which is currently discussing buying a fibre laser and it's rekindled the desire for 'toolbots' to control access to things. Originally I was looking at this over a year ago but got busy with other things so shelved it and then the need suddenly seemed less urgent.

One of our challenges is that when we opened we used some Wiegand RFID readers for our door entry system and fed the UIDs they gave into our membership database. Later on we found out that these UIDs weren't the same as the UIDs other things reported. I did some fiddling around and realised a simple XOR and byte reshuffle that fixed this so we were back in business until I built something using this and found it wasn't right for some issued cards. 

Then the access control project got shelved.

Having dug out my access control mockup again I armed myself with a pile of cards that I know don't map IDs how I thought and quickly realised if they have a 7-byte UID then the byte order reshuffle is different than for a 4-byte UID. So we're potentially back in business.

For the hardware I've taken a bit of an executive decision on the basis that whoever does the work gets to say how it's done, otherwise endless bikeshedding occurs. The hardware will be based on an Olimex ESP32-EVB which is an ESP32 dev board with Ethernet, onboard relays and a bunch of hardware we probably don't need. They're reliably available and properly certified.

To add the RFID reader I've designed a little 'shield' that plugs into the UEXT connector on the EVB which I'll solder some cheap MRC522 boards to.

It also breaks out some GPIO and has LEDs and somewhere to connect a sounder. I'm not even sure if we'll use a sounder, but I just wanted to get the board ordered.

Work on the software has been ongoing for ages but I've started poking at it again and one of the other Trustees already did a bunch of stuff in our membership database so I'm hoping this project can get done without too much pain.

Each tool will have different ways of limiting its use but my expectation most will already have an interlock or emergency stop that can be connected to one of the onboard relays of the EVB. I'd not expect these devices to control the main power feed to the tool unless it's a very small one.

m2mDirect v0.1.1 release

A long time ago I created m2mMesh, which was an Arduino library for a self-organising mesh network onESP8266/32 that allowed you to do machine-to-machine messaging.

This has been quite useful but sometimes it's overly heavyweight so I've written a simpler thing for direct links between two devices. Also with just two devices you can use the built in encryption features of ESP-NOW. Lack of encryption was always a concern with m2mMesh.

This new library is m2mDirect, which I intend to use for control/telemetry of the various rovers I've been working on.

It's not in the Arduino Library Manager yet as it needs more work, in particular ESP8266 support and channel negotiation, but it is now available on GitHub.

Reject modernity, embrace tradition

I've recently been ordering some custom PCBs from JLCPCB for projects. The combo of EasyEDA and direct integration with JLCPCB, who offer it, makes it easy for somebody who's used to homebrewing small bits of simple electronics to spin up PCBs. It's cheap too.

They've all been variants on an ESP32 microcontroller, some kind of 3.3v power supply then a load of headers for the specific peripherals I want for that specific project.

My SMD soldering is a bit hit and miss, I've had a few irritating failures from creating shorts under big modules like the ESP32-WROOM or the uSD socket. I'm OK at putting solder paste on, but then I tend to very slightly botch the placement and have to nudge the module into place smearing it. I just don't have hands steady enough to get it right first time. I'm fine with the smaller components.

On the whole though it's a positive experience and I've got better at this than when I was first ordering things in 2019.

One of the things that changed since then is the proliferation of microcontrollers that have native USB support. Now there are multiple ESP32 variants with it but it's appearing all over the place, right down to the ultra-cheap RISC-V chips from WCH.

The boards above have ESP32-S2 modules but I'm also making things with the ESP32-C3, which I'm coming to really like due to low cost, native USB for programming and just enough GPIO for most things.

The upshot of this is making boards with USB naturally leads to wanting USB connectors for the boards. 

Which I dislike.

Low volume electronics projects with SMD soldered micro-USB sockets have a bad history for me. I've damaged or totally ripped off the socket on more than one board and they're often just a bit cruddy. Professionally made high volume products are better but it's still a weak point.

The obvious solution is to fit USB-C, which addresses many of the issues but have you looked at the soldering footprint for one? Nope. Also I don't need USB-C. These are USB 1.1 devices with no need for Power Delivery or anything smart.

So I've embraced old-school full size USB-B connectors for the larger PCBs. They're trivial to hand solder and robust. Which is good if they're likely to get rough handling, which some of these may do. If it's going in a physically large object the extra size isn't going to matter.

For the smaller PCBs I'm using some common cheap micro-USB breakouts. External USB-C breakouts would also work.

The ESP32-C3 is replacing the ESP8266 in my affections and I ordered twenty of this PCB. It is effectively a small battery efficient development board. So I've reinvented the wheel a bit.

In the kind of projects where I expect to use this I often bury the main PCB inside somewhere but will want the USB socket accessible in the side of the enclosure.

Having the USB socket on a short flying lead is convenient for this and USB is more tolerant of this than you'd expect. In principle you need to match the track impedances/lengths etc. but in practice you get way with it. It adds a lot of flexibility and if the socket gets damaged it can be easily replaced.

Separating the the USB socket also means I can come up with whatever power path I want at time of build. Some things are going to have LiPo batteries and want an onboard charger. Some will have removable batteries. Some will be USB powered. These boards are generic after all.

I may come back to this and design myself a board that includes onboard power path management/charging for a single LiPo cell, which I did on an old design, but for now I'm happy with how these are coming out.

Making ESPUI a captive portal on ESP8266/ESP32

There's a really nice UI for making basic interactive web applications using the Arduino IDE on ESP microcontrollers, ESPUI. This is a real shortcut to usability for very basic "push a button a on web page and something happens" projects as it works asynchronously and does all the behind the scenes dirty work for you.

It does have one dull limitation though, it doesn't by default work as a captive portal. You can bodge a fix to this with the following steps.

First, find the line in ESPUI.c

server->onNotFound([](AsyncWebServerRequest* request) { request->send(404); });

Then comment it out and add the code

server->onNotFound([](AsyncWebServerRequest* request) { request->redirect("/")});

This means any time a request for an unexpected URL hits the Web Server on the ESP it will redirect to the root of the server. You can change this to some other URL by changing the "/".

Now this still won't get all requests to hit the ESP, you need to add the following bits into the rest of the sketch. This assumes your ESP is acting as an AP on the usual IP address 192.168.4.1, but you can see how it's easily changed.

<near the top of the sketch>
#include <DNSServer.h>
IPAddress apIP(192, 168, 4, 1);
DNSServer dnsServer;

void setup()
{
    <rest of your setup stuff>
    dnsServer.start(53, "*", apIP);
    dnsServer.setErrorReplyCode(DNSReplyCode::NoError);
}

 
void loop()
{

    <rest of your loop stuff>

    dnsServer.processNextRequest();
}

I really should submit a more complete solution as a pull request and new example to the library.

Now when most devices hit the ESP they will take you straight to the page asking you to "sign in" etc. and it doesn't stop you manually going to the page.

InfoPoint code and word wrapping

I made a little effort to tidy up and post the code used on the EMFCamp 2022 Cybar InfoPoints. It's under the main Polybius organisation on GitHub.

The InfoPoints ended up working nicely and I will almost certainly use devices that sync configuration from GitHub in future. It makes for a really nice free place to store configuration with all the user admin/permission work done for you, so long as it's OK for the information to be publicly viewable.

I might investigate if there's some way to do this with a private repository and if so I might turn it into a library.

This also caused me to remove the word wrapping code I wrote to format the displayed text with and turn it into a generic Arduino word wrap library.

When I first started work on this I was amazed there isn't a basic word wrap library that's not part of some other larger project, or at least I didn't manage to find one. Word wrapping is a standard kind of thing you'd really expect to find covered.

There is some messy stuff around what to do with very long words wrapping into small spaces, which I've tried to handle and if the text doesn't fit into the requested lines it adds ellipses (...) hopefully somewhere sensible. I can see this getting re-used a chunk in my various Arduino projects with user interfaces.

Creating a UI on a microcontroller: Part 11

I've been doing lots of work on the flow of things in the user interface in the terminal application so it works better. The deeper in I get the more boilerplate I'm writing to make buttons appear and disappear without leaving stuff floating around, so it's quite slow progress.

On the plus side, the syncing of user accounts and so on is working nicely and I've now made it so that it live updates. Make a change to a user and it appears near-instantly on the other terminals. Previously it synced the files on the SD card but they didn't show until a reboot.

Actually coding that to happen took another swathe of boilerplate but each time I do a thing like this I'm edging closer to a believable looking application. Also a bit of bugfixing which might have finally nailed the occasional exceptions when using a mouse.

As it's getting closer to something I can demonstrate I did a quick show and tell on Brian Lough's 'Project Doc' stream this evening. Which I believe is recorded for posterity.

Creating a UI on a microcontroller: Part 10

I've done a little more work on my retro 'computer terminal' application. When it started out, the key feature was messaging over the mesh network library I've also been working on.

All the code was there but just commented out while I got the user interface library knocked into shape. So I uncommented it and spent some time making some improvements. Again it also showed up some limitations in the UI library. Most of these were around showing/hiding the cursor and moving it back to the line where you're typing reliably.

With these ironed out, the basic chat functionality pretty much just worked despite being written a year ago and not touched since.

I've done a little video of two terminals sending chat messages. At one point I had a 'bot' that produced Lorem Ipsum any time there was activity in a chat. I must dust that off.

Creating a UI on a microcontroller: Part 9

I finally got this library knocked into shape enough that I could start porting my application to it. Doing so showed up even more shortcomings but I've now fixed this and we're back into feature creep.

The application pretends to be a 'computer terminal' and needs to deliver movie style retro computer interactions. Once of these is looking at files stored on the SD card attached to the microcontroller. Which will sync across multiple 'nodes' running the same code.

I've spent a chunk of time this week improving how large chunks of text (or small files) display and have added support for basic Markdown formatting. You've limited capabilities in a dumb terminal but I think it does well enough at stopping it being a wall of uniform text.

Here's a quick video demo of the user interface in action. It can be driven entirely with keyboard but also the mouse works and you can click the buttons, scrollbar on the text window and so on.

Creating a UI on a microcontroller: Part 8

This week I'm back working on my 'rod for my own back' project, ie. making a library to display a useful user interface over the UART of a generic microcontroller.

This week I've started on actually using it for its intended purpose, faking up a retro mainframe computer on ESP8266/ESP32. Trying to refactor my original code for this application to use the library has shown up a few of things.

First I was definitely right to pull out all the code and turn it into a generic library. Secondly it was missing a few features I need but thirdly and most annoyingly it still has lots of bugs.

In particular I had created lots of bugs with redrawing changing items or things that appear, disappear or change frequently. The main application is too complicated to troubleshoot with so I wrote this trivial alarm clock. You set the time and alarm with the +/- under each digit and when they match it turns red, rings the bell and a cancel button appears.

Trivial as this application is, it's really helped with the troubleshooting and I've added a load more functions, one of which changes the title bar of the terminal emulator, if allowed. It's all boilerplate, not fancy algorithms, but I still get a real sense of satisfaction in controlling an AVR Arduino with the mouse and keyboard on the computer it's plugged in to.

Here's a little video of it in action.

Creating a UI on a microcontroller: Part 7

It's been a while since my last update on this library, but I have been working on things slowly. I got buried deep in the hole of optimising memory until you could again use my library on an AVR Arduino board, but perhaps more importantly it massively reduces the memory footprint on other things.

I got bogged down in the messy detail of handling the AVR program space functions, especially when trying to make it also compile and run for ESP8266. The Arduino core for ESP8266 provides similar looking functions but they don't behave exactly the same. Also I encountered some messiness when trying to use them inside a C++ class, in ways I should have realised was verboten.

Regardless, now if you pass the library a string type argument stored in program space it marks it as such and accesses it differently, depending on the processor. This includes using different methods to find the length of strings for centring and so on.

Time consuming fiddly stuff but it had to be done and finally you can run the example code on an Arduino Nano again, only consuming 1124 of 2048 bytes dynamic memory. The sketch does use most of the program storage, which is down to the large amount of text stored there. It runs stably, something you can easily compromise when throwing lots of string data around with a small margins on the stack.

I've enjoyed this learning exercise, but I now need to test my library with other architectures supported by the Arduino IDE, such as a Teensy with an ARM Cortex-M4. In these cases it shouldn't be so necessary to store small chunks of text in program storage but it is something I would like to be sure of working. I believe I have a Teensy 3.2 somewhere.

Creating a UI on a microcontroller: Part 5

In this update I've added 'list boxes' and the ability to style text inputs as password fields. So the list of widgets is now...

• Buttons
• Checkboxes
• Radio buttons
• Text boxes with scrollable content
• List boxes
• Single line text input fields
• Single line password input fields

Creating a UI on a microcontroller: Part 4

In this update I show the work I've done on styling widgets with colours, different box drawing characters and different positions for labels/shortcuts.

Creating a UI on a microcontroller: Part 3

Another update on my terminal interface UI library and after lots of code cleanup it now handles multiple editable text input fields. I started using OBS to capture the output with so this video is cleaner than the first ones.

To recap I've now got the following working as simple to create 'widgets', any of which you can have multiples of on the screen at the same time and swap between them with keyboard shortcuts or the mouse.

• Buttons
• Checkboxes
• Radio buttons
• Text boxes with scrollable content
• Single line text input fields

At this point it's using more memory than is practical on classic AVR Arduino boards but I know I'll be able to reduce the footprint a lot later.

Creating a UI on a microcontroller: Part 2

More work on the terminal UI library, but I've now added radio buttons and a scrolling text window, useful for showing a larger block especially from an SD card or stored in program flash memory.

If loading from an SD card it would need to be loaded into the memory of the microcontroller, I've not yet added support for very large blocks of text.

 

Creating a UI on a microcontroller: Part 1

A chunk of my work has always been about building things with microcontroller boards (either classic Arduino AVR or ESP8266/ESP32) that you interact with directly.

For our (postponed) LARP event in March I had created a fake 'computer terminal' that you interacted with, where all the work is done on an ESP8266. RFID cards log a user on and there was a chat application, file viewing and so on, all using my ESP-Now mesh network to allow the individual terminals to send messages to each other.

In order to make this I used ANSI/VT100 escape sequences to create a very simple 'application' that you accessed using a terminal emulator, PuTTY, running on old laptops.

It's not wrong to argue this is the 'tail wagging the dog' when there's a much more powerful computer just running PuTTY but the guiding factor was the mesh networking, not the application itself. It also meant anything you could run PuTTY on could quickly and easily be pressed into service as a terminal and PuTTY is available for Windows and Linux. Likewise any other terminal emulator that supported a broad range of terminal capabilities could be used, but all my testing has been with PuTTY.

In the weeks before the event, I was in a 'crunch' working on various props and technology for the game 14+ hours a day until suddenly we postponed due to the pandemic.

As irritating as this was it's given me time to turn this work into a re-usable Arduino library. Such things already exist to place the cursor, change colours and so on but the one I've been working on has 'widgets' like mouse-clickable buttons and does the work of drawing/updating them for you.

The idea is if you have an Arduino project that needs a user interface, perhaps one that's infrequently used, you can build this with minimal pain. Then to access it you just connect a USB cable and there's a terminal UI available over the serial connection. Sadly it does not work in the Arduino console monitor as it's not a proper terminal application, but PuTTY isn't onerous to install.

I have an aspiration this would be usable over the network on microcontrollers with Wi-Fi such as the ESP8266 but it probably has more value on those without. If you've got Wi-Fi, basic web server front ends are going to be more flexible.

ESP32-CAM helmet camera, prototype 3

 

While working with the ESP32-CAM board I've realised that the AMS1117 LDO fitted to it is a bit of a problem due to a 1V dropout value. This means that if you power it from an 18650 cell it starts to brown out far sooner than needed.

Coincidentally somebody from the LARP community asked me to see if I can make a design that takes four AA batteries and I put this new version together. The 6V from the battery pack works much better than the single 18650 and means they can be swapped easily but sadly makes the camera really quite bulky. Nonetheless I've sent them the files so they can have a go at building some units.

Going forward I've seen that the LDL1117 LDO only has a 0.3-0.6v dropout and is pin compatible. I think carefully desoldering the AMS117 and replacing it with one of these would solve my brownout problems.

An alternative would be a small 'daughterboard' that connects to the headers and has a buck convertor. This would be the more elegant option, especially if I managed to include the power switch and lamp button onboard. I've still not found time to see if I can make an I2S microphone work with the board, but that could also go on a 'daughterboard' if it did.

ESP32-CAM helmet camera, prototype 2

 

I did a little more work on the design and added an external antenna, as it's a known fact the board works better with one.

Then I put quite a lot of effort into painting it up in a basic camouflage pattern. I am very pleased with how this worked out.

No other real changes to the project but it shows you can make something decent looking at a low cost.

ESP32-CAM helmet camera, prototype 1

It's been a while since I've blogged. Back in March I was working very hard indeed on making props for our upcoming LARP. With the pandemic we suddenly had to postpone until some indeterminate time in the future.

This killed my enthusiasm for a bit and when I picked up projects again I needed a change.

Over the last couple of weeks I've been fiddling with the ESP32-CAM board again and turned the pile of components in the first photo into a working helmet camera prototype.

With the standard camera example code loaded it works really quite solidly and the battery life with a 18650 cell recovered from an old laptop battery pack seems good.

I started out with the selfie lens for aesthetic reasons but it does a good job of taking in a whole room as you move around, something the default lens these boards ship with doesn't do.

The tactile button on the side switches on the onboard 'flash' LED and there's an acrylic light pipe bringing the light out of the shadow of the lens. It's not a proper long throw torch but it just about manages to light a dark room so you can see and the camera will generate a very grainy picture with the gain up full.

Onboard charging is nice but currently getting the cell in/out in the field is impractically fiddly and the holder is stuck in with tape. The indicator LEDs on the TP4056 board are brought out on the side with another couple of light pipes and these work great. The idea is if these were issued on a multi-day game it would be the player responsibility to keep them charged and a USB charging socket makes that practical. For a short game they probably won't need charging.

Overall this has worked out really nicely and the design I've done in OpenSCAD is modular enough it's easy to swap out the rail mount and add something different. These could easily double as 'CCTV' cameras with a ball socket mount.

The design does need a little more work to make it easy to assemble but broadly it's there. I've also had it suggested that an external antenna would be acceptable, when I thought it would be too ugly. So I'll work on a version with that over the next few weeks, the boards have a uFL connector and it'll really help increase range.

I've got enough camera boards and recovered batteries in good condition to build a set for a whole team of 'marines' and a few static CCTV units. Doing this while keeping the cost down for 10+ units has been a major requirement of this project and I've definitely succeeded at that. The bill of materials using the recovered 18650s comes in at about £7 plus printer filament at the moment.

LILYGO TTGO T-Wristband

This is the LilyGo TTGO T-Wristband that turned up today, catchy name.

LilyGo are known for producing a lot of 'maker friendly' development boards where they cram a lot of useful stuff together on a board in various combinations, lots of it based around the ESP8266 or ESP32.

Chances are there's a combination that might not be exactly what you want, but close enough you don't need to build something up from scratch or a tangle of different modules. Want an E-paper display, OLED display, LORA radio, Cellular connectivity, LiPo charging circuit and ESP or some random combo of 2-3 of these on one board they probably make it. It's all cheap and cheerful AliExpress/Banggood fare and I've bought a few things from them over the years.

This here is closer to an actual product, it's a 'fitness band' looking much like one of the sea of cheap BLE ones available for attaching to your phone but it's maker friendly with a programming cable and apparently usable code for all the components on GitHub.

Based around the ESP32 it's probably not the best platform for something like this as it's too power hungry, but it should be something I can program myself.

I have plans to tie it into my mesh network and directly deliver messages over ESP-Now with no need for a phone.

This is a kind of speculative purchase, I may not find the time to get the code in order for when I need it, but it was cheap as chips and if it does work it will be great.

If it does work I may buy 2-3 more.

ESP32-CAM case, selfie lens and mount - part 1

Poundland (the major UK 'dollar store') had selfie lenses for 50p so I picked up a few to play with on my stash of ESP32-CAM modules.

I've 3D printed a mount that protects the board and lines up the lens perfectly with the existing camera. The lens is an interference fit, at least on my printer, and screws in firmly.

Initial testing seems positive as it really expands the field of view. It's never going to rival a GoPro but makes the module much more versatile. You can buy a wide angle cameras for the ESP32-CAM but typically you have to buy that separately, almost doubling the cost so this was a cheaper way to get similar effect.

It also gives it a 'big lens' look rather than the pinhole camera of the usual module. Which is the aesthetic I want.

I still need to design a back to the case but this should give me a robust housing for these things. Different backs could have different options including a battery holder and switch.

The flash LED is exposed close to the lens but this would work better with a bit of acrylic rod acting as a light pipe and make it possible to make the whole thing passably waterproof with some thought.

The nasty thing with the LED is it shares a pin with the SD card interface so if you access the card it flashes. This is a problem. I have no idea who would have thought that was a good idea, it's not like there aren't any free pins. Fine if you use the camera over the network but makes the flash useless in situations you want to write to SD and if it's battery powered will chew power. Just why?