Showing posts with label ESP8285. Show all posts
Showing posts with label ESP8285. Show all posts

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.

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.



Solar charging ESP-Now BATMAN prototype 4

After the last test run, I decided I wanted to investigate the supply load tracking feature of the MCP73871 charge controller to see if it improves charging. With a small solar cell in winter, it will be very easy for the charging circuit load to drag down the voltage from the cell such that it ceases to be of use.

In order to see how well this works you also really need a good measure of the voltage and current at both the battery and the charging input. Which means adding the INA219 modules back again after I took them out.

Having considered reworking the previous board it's just too untidy and with the SD card reader attached the ESP8285 doesn't have enough pins to go around. Using socketed modules allowed me to just make a new carrier board and swap them over. I also made a big effort at tidier wiring, the last one was offensive.

The supply load tracking feature on the MCP73871 is called Voltage Proportional Charge Control (VPCC) and reduces load to the supply if the voltage drops below a threshold. VPCC needs a simple voltage divider that provides 1.23v (or more) at a pin while the supply is OK. If this voltage drops, it reduces current draw to bring it back up. On the new board I've fitted a small socket header so I can fit different values to the voltage divider.

We're also getting to the time of year where it might go below freezing and the thermal protection circuit needs testing. So I've added another header for the thermistor network, temporarily bypassed with a resistor while I fiddle with the VPCC in isolation. I'm going to move my test location to near an indoor window where there's more sun for more of the day and hang the solar cell out of the window. Once I've investigated the practical worth of VPCC I'll add the thermistor network and do some tests with heating and cooling it.

Solar charging ESP-Now BATMAN prototype 3

After the component selection failure with my last solar prototype, I resolved to have another go.

This time, I decided to build as close an equivalent as possible on stripboard despite the presence of several SMD-only components. For this I needed a QFN20 breakout and with the buck convertor, I used one of the first boards I had made, cutting off the large empty sections. The QFN20 was not fun to solder but it works.

I'm glad I went through this step as it showed up a poor selection of GPIO pins for the connection to the MCP73871 charge controller. My very first prototype used an evaluation board and not all the connections are broken out on it. Moving the status connections to the ESP8285 did what I wanted but dragged one of the pins low and stopped it from booting in some states. This is one of those things that again I should have picked up from reading the datasheets, but didn't.

With a little shuffle of pins, the prototype is ugly but seemingly nicely functional so I've dropped it into the shed to test. Late November is a bad time for solar power in the UK, so it's a bit of a 'torture test' of charging viability. It's quite likely to fail as I've not put much in the way of smarts yet about when it sleeps or switches off the radio.

In the meantime I've bought an ESP32S2 module and breakout adapter from a Tindie seller. I may build a second prototype based around this as the S2 is like an ESP8266++ with Bluetooth support and lots more resources without seemingly much more power draw. The extra GPIO pins won't be unwelcome too, the ESP8285 has few and I've ended up re-using the UART pins. Not a big deal but it means you can't have Serial debug info with the charge controller working and you need to rely on OTA updates after an initial upload of the code.

Update

This prototype ran for roughly 66 hours before the battery got low and it started sleeping in an attempt to allow the sun to charge them. That's plenty enough for my requirement of a full weekend's service.

However, from the logs it looks like it only spent 4 hours actively charging the battery, which is shockingly low even given its shady position in the low winter sun. As the MCP73871 only has three binary status indicators I don't feel I have enough data to be clear what contribution the solar panel was making to the runtime so I am going to modify this prototype and add an INA219 current monitor inline with the battery.

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.

Rookie SMD mistake

 

I received the new boards from JLCPCB and they look great, but I've made a real rookie mistake when ordering.

Working in EasyEDA, component selection defaults to 0201 packages for things like the resistors.

These are tinyReally really tiny.

This is something I already knew and just missed it when laying out the board.

I realised my mistake when ordering the components but thought, let's give it a go. I have made an attempt to solder these but with my ageing eyesight I can barely see and handle them, let alone apply paste and hot air to successfully solder them.

Now with the ongoing pandemic I don't have any immediate application for these boards, so I'll pause a little while before coming back to them and producing a new version. Either I'll choose larger components or have JLCPCB do PCB assembly for me, which is increasingly affordable.

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.



Solar charging ESP-Now BATMAN prototype 2

After over two weeks continuous running my first prototype of the solar charged prototype proved itself with a 2W panel. So I spent a chunk of time designing the next iteration in EasyEDA and ordered five PCBs from JLCPCB in China.

I've taken a small gamble with this design as I haven't built it on breadboard first and have added a number of new features.
  • Thermal protection for the 18650 cells, a feature available but omitted from the MCP73871 evaluation board. They will now only charge in temperatures of 0-50C, which is a default safe option. I don't feel this will kick in often in the UK except perhaps on a very sunny but cold morning however to omit this feature would be slightly negligent.
  • Replacement of the INA219 current monitors with a simple resistor ladder to measure supply voltage after the charge controller with the ESP8285.
  • Connection of the MCP73871 status pins to the ESP8285 rather than indicator LEDs.
  • A microSD socket for optional file storage.
This is quite a simple project compared to the people making their own small board computers or things based on FPGAs but it's only my second ever manufactured PCB. All the pins on the ESP8285 board are in use, although in principle IO0 which has a button attached for putting it into programming mode could be doubled up with for something else so long as it defaulted to a pullup.

Instead of going straight to the final run of boards I'd like to test these five before ordering more. I made absolutely no effort to keep it compact so even if no changes are needed I'll still move things around and tidy it up before the final order.

Once these arrive I'm hoping the extra efficiency of the PAM2301 regulator will make a 1W panel viable in the UK but if not, 2W panels aren't overly huge.

Solar panel doubling

 A bit of data logging showed a single 1W panel useful for supplementing battery power to my mesh network node, but not really enough to charge it meaningfully at the same time. My garden is south facing and the house blocks direct sun lots of the day so it was only the few hours where the panel was in strong direct sun that the result was acceptable. For something that spends a lot of the time asleep this would be reasonable but as I want each node to run for all the waking hours then I need it to do better. I did get 52 hours of runtime, which is technically enough for my needs if I fit two 18650s in the node, but I still don't like the thought of it running down constantly with only a tiny amount of headroom.

The data also shows the regulator board I took out of a drawer is an LDO, not a buck converter, so it's 60% efficient a lot of the time. I will make a pin compatible replacement with the converter I specified for the final boards and that should be a big help.

I've now set up two 1W panels in parallel to make an effective 2W panel. Only a few hours later it's clear this makes a massive difference as they spend lots of time charging the cell rather than just 'treading water'. I'll leave the test to run until the battery protection kicks in at 3.5V but it looks like 2W panels really are what's needed even if I were to replace the LDO. There are some really quite affordable 2W 5.5V cells on Banggood, so going up in size isn't a big deal.

Solar charger data logging


 After a little fiddling around today I had software on ESP8285 node so I can keep track of the battery use and how well the MCP73871 manages things.

Working at my desk it seems to seamlessly charge then swap over to battery if needed, but more importantly if there's roughly 0.5W charging capacity, which is what I'm expecting from the solar panels I have, available it'll run the ESP8285 and use excess to top up the single 18650 I've fitted for now. This is exactly what I was hoping for from the chip, but what's not clear yet is how well it works around dawn and dusk. Playing around with my bench PSU would give me some idea but with solar cells varying voltage under load I've just gone straight for a practical test.

The code I've put on isn't anything like the final application but it does sit there connected to WiFi pushing data to MQTT every 30s so it's a pretty reasonable test. I'm dropping the output into a .csv file on my server and I'll look at it periodically to see how the battery fares. As I wanted real timestamps on the data I used the quite nice ezTime library to sync with NTP but more importantly maintain a usable time based off the ESP8285's internal clock and only periodically update it. This is a feature I will need when things happen for real, although I'll probably have to use GPS and a local NTP server due to lack of guaranteed internet access.

Also Blogger has changed and all my layouts are broken. Sigh.

Solar charging ESP-Now BATMAN prototype

Putting a 'production' board together rekindled my interest in a solar charging prototype of my mesh network nodes.

A small solar cell in typical UK weather is not going to be able to run the node 100% of the daytime, but it will almost certainly work as a useful 'runtime extender'.

I started looking at this way back last autumn then like a lot of things my enthusiasm waned and it languished in a box for months. Today I finished off putting it together to a point where I could knock some software up and start logging charging/load data.

I'm using the same ESP8285 module I have for the nodes, with an MCP73871 development board for charging and power management. The naive approach would be to stick a conventional LiPo charger in parallel with the batteries but the load messes with the charging.

The MCP73871 manages the power path so that depending on the charging power available it will run the load from that while also charging the batteries, run the load from it, or once it it is too low run the load from the batteries. As the battery isn't directly connected to the load this can be done while maintaining proper charge behaviour for the LiPo. It is not proper MPPT tracking for the solar cell, but it does sensing of how much current it can draw before the voltage drops too low that will have a similar effect. For extra efficiency a DC-DC converter that does MPPT would help, but I'm going to suck it and see if this prototype is 'good enough'.

I've shoehorned several INA219 current/voltage sensors into the power path so I know the battery, charging and load detail. My plan is to stick this inside my shed, with a solar cell outside and simply log the data until it falls off the network because the MCP73871 has decided to protect the battery.

ESP-Now BATMAN boards

Back in February I was faced with a looming deadline for our LARP in March where we would be using my ESP-Now mesh network for messaging between props and also to end devices used by players.

For this to work we'd need some fixed nodes to give minimal coverage. I had previously built ten static nodes using Wemos D1 mini Pro boards and NiMH batteries and used them in testing but battery life was only around eight hours which wouldn't be enough even with overnight charging.

I did a few sums, came up with a power budget and figured something with a more efficient regulator, no indicator LEDs and a couple of 18650 cells in parallel should easily run for a whole weekend, eliminating another point of stress for the game.

Scratch building all this would have been a drag so I designed and ordered twenty boards from JLCPCB in China.

I had previously tried designing boards in KiCAD but found the interface impenetrable even for simple things and got deterred. For these boards I tried out JLCPCB's own web based EDA software, EasyEDA and was pleasantly surprised.

While I did have a bit of a struggle finding matching footprints for the components involved the process really wasn't hard. They also integrate this fairly tightly with the PCB ordering making the generation of gerber files, drill files and so on something you don't need to worry about too much.

This smoothing over of the complicated process meant I was able to get to grips with EasyEDA, design a board and order it in a morning with my only previous experience being a couple of failed attempts to do something useful in KiCAD.

Sadly with the postponement of our game due to the pandemic these boards have sat on the side since delivery but today I finally built one and it works! I added a reset switch to make repeated programming easier, and were I to design them again I would add a reset and flash button on the board, but for now these suffice. There's almost nothing to the circuit, it's an ESP8285 module, buck regulator, battery holders and some headers. No charging or protection circuit and nothing to leech power that isn't needed.

Until I add more features I have in mind like onboard solar charging then they'll do. In the meantime I'll do some current measurements and rundown tests with this one to check its performance. I'm really hoping these will give us the coverage we need for the game and now I've some more time to work on it I can actually check properly.

ESP8285 programming

For the boards I'm planning on building I'm going to shift to using ESP8285 modules instead of ESP8266.

The main reason is the integrated flash and the secondary one is it's smaller, with more usable pins than an ESP-01S in less space. I'm not at all space constrained for the first iteration of my project but I will be for later items.

Nice as these are they're really designed for surface mount use so I had to build a little breakout to work with the handful I bought to test with. It's a bit rough and ready but works just fine.

A side effect of the integrated flash memory is you don't need to mess about with pulling pins high to boot. You just need to pull GPIO0 low if you want to program it. I put a couple of buttons on my breakout, one to reset and one to hold GPIO0 low, making for easy programming.

I did a little test with this and my mesh code works perfectly. Another bonus is these chips seem to use slightly less power, ~70mA instead of ~80mA for the ESP-01S. Some of that will be the lack of LED indicators but it's welcome nonetheless on a battery powered project.