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.

Quick cyberdeck build: Part 9

This is an after action report on the Cyberdeck as the LARP I put it together for was this week. It worked excellently with a couple of minor irritations.

In advance I had worried about the battery life being poor as I'd never really done a run down test and it was fitted with a cheap eBay aftermarket battery. Also, hanging the keypad, trackball and illuminated buttons off USB OTG was using a little power all the time despite using my Power Profiler to help reduce that as much as I could.

In the end it was just fine to be used heavily all day. There was a lot of in-game chat.

I had wondered about usability as modern smartphones and their apps are designed around a touch interface with really great predictive typing. 

Going back to a trackball, mouse buttons and keyboard is very much a retrograde step. Discord (which the LARP used for in game communications) did suck a bit with the non-touch interface but was usable and the case fitted nicely in both hands for two thumb typing. The screen could still be touched but this is hard near the edges due to the lip on the case.

The biggest aggro was the paint. I hate painting 3D printed objects and having tried not to spray the paint on too thick and give it plenty of time to dry the red parts were still soft as I was travelling to the game.

At various points the case, especially the back, kept sticking to other things like the tool belt I carried the Cyberdeck in. You can see this quite clearly in the second photo where it's messed up the finish. If I ever open this up again to add more features, like a LORA radio, I'll end up reprinting the case and transferring the internals to a new one which will mean ungluing some of the wiring.

Quick cyberdeck build: Part 8

Some nine months after I started this 'quick' build it's done.

Nothing unexpected slowed me down really, but the level of accuracy needed in modelling the 3D printed enclosure ate lots and lots of time and test prints. I also faffed with not finalising how the charging would be done and having to swap from USB OTG host to USB charging and this led to reprints of the back section of the case.

There's now a slide switch on the bottom that swaps from charging to enabling USB OTG next to the USB socket.

Painting 3D prints is horrible and I hate it. I don't know how cosplay people deal with all the faff. I guess them shifting heavily to resin printers even on things without masses of detail tells you everything you need to know about how awful finishing FDM 3D printed stuff is. The final result on the top fascia is great but I really can't justify it on most of my one-use props. The back didn't come out as well but you're not looking at the back much.

The device is obviously a massive inefficient use of space compared to the phone I built this around but that would be missing the point.

I've also decided that there's room inside this one for an RFM95 LORA module to make a LORA messenger, which would be quite cool but it'll have to wait until I've got time to make a second iteration of this. I'd also like to fit a USB hub and the option to plug in USB flash drives etc. A full size USB socket is quite chonky but there might be scope to squeeze one in.

I'm assisting running a Cyberpunk LARP in a month or so and wondering about reworking the 'cyberdecks' I made for the previous instalment of the game. They are just big 3D printed carry cases for Nexus 9 tablets which I've settled on as my standard "issue a tablet to LARP players" tablet because they're cheap and decent. 

The game semi-requires of attaching stuff to the 'cyberdecks' with USB OTG cable at one point and once you start down that road adding random buttons and a keypad gets very tempting.


Hoverboard motor powered rover: Part 4

With the arrival of more Kinects I need to get back to mounting a computer on the rover in a better way than just cable-tying a Raspberry Pi to a cable-tie base. It was rattling round like a mad thing outdoors which was just generally unsatisfactory.

Having read up a little on ROS I came to the conclusion that I needed a more powerful computer than a Pi 3B+. The Kinects chuck a lot of data at USB, the Pi3 hangs everything off USB and poor performance of USB peripherals is a standard Pi thing. If I want to try the Xbox One Kinect it requires USB3 which the Pi3 simply doesn't have. However with the ongoing chip shortage you simply can't buy things like Pi 4s or Jetson Nanos easily.

To get something with a bit of grunt and more memory without breaking the bank I took a leaf out of Colin Hickey's book and bought a used thin client from eBay. This one is a Dell Wyse 5060 which gets you an AMD GX-424CC quad core 2.4Ghz processor, 4GB RAM, USB3 and a tiny 8GB SSD for £37 delivered. A quick rummage in my box of PC parts and I found another SODIMM so it's now sporting 8GB of RAM. There's a well know pre-set password of 'Fireport' on the BIOS and once you've cleared this you can wipe the SSD and install any desktop OS you fancy.

Ubuntu 20.04LTS, the main supported OS for the final release ROS 1 'Noetic' fits on the 8GB SSD fine although I can imagine running out of space at some point. The SSD fitted is a weird stubby SATA thing plugged directly into the board but apart from the physical form factor it seems it's otherwise standard SATA. So if needed I can make an internal cradle and connect a standard drive with SATA cables.

It's a really nice little machine. I booted a LiveUSB of the Ubuntu desktop and it's really quite nippy for the basic specification.

Being a thin client the case has proper mounting points for both a VESA mount and a desktop stand. It just fits on the deck of the rover and I can see myself using the VESA mount for this. It's fanless and DC powered with a ubiquitous 19V laptop style supply and I should be able to use a buck convertor to get that from the rover's 36V battery pack easily. Physically it's about 5-6 times the size of a Pi in a case but given the scale of rover I'm building this isn't a big deal.

The only concern is this will use a lot more power than a SBC like a Pi or Jetson but it is far more efficient than a full desktop, it's effectively laptop style components. It's missing the optional WiFi adapter but I'm not bothered by that. I've got some USB ones and with six USB ports on two separate buses that's not going to kill performance for other things.

I'm really impressed with the build quality, silence and compactness of this little thing, it's almost tempting to replace the hulking ancient desktop I use in my cellar workshop with another Wyse 5060 the same. I'm not even sure it'd be any slower.

Quick cyberdeck build: Part 7

I've been worrying about the charging of the battery for the Cyberdeck and my naïve idea was to simply stick a TP4056 charger inline with the battery. This sort of worked and when I fitted the new battery recently I checked it was OK, but the behaviour of the phone and the labelling on the pack gave me pause.

For a start the phone doesn't know the battery is charging. This sort of doesn't matter but you've also got the issue the charger doesn't know when to stop charging if the phone is switched on, due to the load from the device. This is exactly the sort of stuff I get fussy about in other projects and it's nagging at me that I was not practicing what I preach.

Also the TP4056 is set up for a slightly different chemistry cell with a 4.2v charge voltage. The battery I received has a 4.35v charge voltage and a peer at the images for these Motorola replacements shows they're all the same.

You can't change the charge voltage on the TP4056 it's preset.

This put the nail in the idea of just sticking that TP4056 charger inline and I'm back to charging it via the phone. Which is precluded by the OTG USB needed for the keyboard and trackball.

So I need to make it switchable.

For USB OTG to occur, the usually unused ID pin on the micro USB connector needs to be connected to ground. When this happens it turns the phone into a USB host and it starts supplying 5v on the VBUS pin normally used to charge the phone.

Once in USB OTG mode you can't charge the phone and supplying 5V on VBUS doesn't achieve anything. If you switch out of USB OTG mode while supplying 5V on VBUS with a device still attached this particular phone cycles from charging to not, which I'm not sure is expected behaviour or not but it's what I've got to deal with.

I've done a practical test to verify all this and using a couple of switches means you can swap from charging to USB OTG reliably. I'm sure something could be done with a few MOSFETs to effect the required swaps when you connect a charger but for this project I'm just going with a DPDT switch made out of two small SPDT switches mostly for time reasons. This has the added benefit of allowing me to completely disconnect the USB peripheral if I want.

So I've got to remake the little flat USB OTG cable I made and rework the whole thing, but I think it's worth doing slightly more properly than I'd planned.


Hoverboard motor powered rover: Part 3

 

I finally took my rover down to East Essex Hackspace and drove it around a bit.

This showed it to be fairly easy to drive with the ESP-Now Nunchuck remote control and the range is more than I need for basic testing.

At its lowest speed setting the rover doesn't always make a lot of purchase on the uneven ground as it's prone to wheel spinning, but as it's 4WD it always makes some progress. This will be massively helped with some form of suspension.

Four wheels screwed to the corners of a piece of plywood is not an optimum chassis design once the surface is anything less than super smooth, but I knew this when I did it.

On the higher speed settings it digs in, gains momentum and flies about, rattling as it goes. The Kinect shook off of its 3D printed mount and I could hear the cable-tied Raspberry Pi rattling like mad so these things need securing in a significantly better way. I'm building up to stripping down the Kinect and making a custom enclosure of my own.

For the test I was using the 'best' of the three battery packs salvaged from the hoverboards and it lasted just fine.

There's not much else to say about this test but here's a little video I recorded.





Quick cyberdeck build: Part 6

Today I received the replacement battery for the cyberdeck and fitted it after modifying the leads so I can insert the external charger between battery and phone. I'm still not 100% happy with this setup but it works.

The interim result is really quite appealing but the paint is still not 100% dry and as I need to handle it a lot doing the last parts I'm going to shelve any more work on it for a couple of days. It's gloss paint so still very slightly soft and I bet it actually takes a week to dry.

Designing the bumpers has got a little mired in lack of vision for what they should look like and some difficulties there'd be in printing and painting the sort of ribbed look I originally wanted. The OpenSCAD design has got very messy with little tweaks to locations and dimensions all over the place in the code so making anything line up nicely is hard. I need to resolve this soon as it will be a long print that also needs painting.

Quick cyberdeck build: Part 5

Quick? I don't think so.

With no immediate use for my Android Cyberdeck project it got shelved for almost a year but now I'm off to a LARP next month that is using the Discord app. for in-game communications.

So this came back out of storage and progressed somewhat.

To make the XBox 360 chatpad and the little Pimoroni trackball work I've made a custom short flat USB OTG cable by cutting up one of the OTG adaptors I had (so it had the extra pin shorted) and mating it with a micro-USB plug scavenged from a cable. Yes you can buy these things but I'm not in the habit of making my own USB cables so I don't have the parts hanging around.

There's a small nub sticking out of the side of the current enclosure but it's getting cosmetic 'bumpers' I'll use to hide this.

The redesign for more buttons has gone OK. There are now three illuminated tactile buttons which I'm hoping I can make use of for dedicated forward/back as well as the usual click. I could almost do with some more because Android has a surprisingly pleasant mouse button interface that you don't normally experience because frankly how often do you connect a mouse to your phone? I might try and implement some buttons in the side that take the place of a mouse scroll wheel, but it'll be fiddly to physically mount them.

The huge battery in shot is just for testing it's far too big to work in the final thing, I think I'm going to order a replacement for the OEM battery as it's a perfect fit. Tucking the added electronics into that space was the original plan but a nicely fitted battery is more important.