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.
I have for a very long time wanted to build in the sort of 'scanning' you see in sci-fi movies to our LARP events as an actual working piece of tech. As the majority of our events occur outdoors the obvious answer is GPS. So I've made a gamble and bought forty GPS modules that came up just cheap enough to justify it to myself.
More so than other modules, cheap GPS modules seem to appear, disappear, then a few months later something similar but different appears on the market. I had identified some I wanted for this project a while back but then they disappeared and as I want to make a compact wearable with a 3D printed case, changing modules is non-trivial.
These super-compact modules look just the ticket and ordering them is an attempt to force my hand into making progress on this. The plan is that most things I build which are connected to the mesh network will have a GPS module. I did this a long time ago with the 'magic compass' but doing it at scale opens up the possibility of making something like the 'motion tracker' seen in Aliens etc.
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.
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.
I've been doing a little home automation with Home Assistant recently and this involved putting temperature sensors in every room. I started out with some ugly stripboard SHT11 based things but they were unreliable and inaccurate.
During a Banggood sale I managed to pick up some Wemos 'shields' with an SHT30 temperature/humidity sensor so I converted all my sensors over to these. Tidier but still a bare circuit board with power LEDs lighting the room at night.
I fiddled around in OpenSCAD and came up with a fairly decent 3D printed enclosure and now have eight sensors dotted around my house, including the shed. This design leaves the SHT30 sticking out in free air with a 'baffle' to separate it from the rest of the device. Even so the temperature readings are massively effected by heat soak from the ESP8266 and quite inefficient LDO on the board. I've now put this on Thingiverse.
To fix the heat soak you need to connect D0 to RST on the D1 mini with a short piece of wire and enable deep sleep so they draw (and waste) much less power. In Tasmota this needs two console commands...
TelePeriod 10
DeepSleepTime 300
...the 'TelePeriod' means it sends data 10s after connecting to WiFi and 'DeepSleepTime' means it sleeps until the next five minute interval on the clock. If you're copying this example don't issue the commands until you're happy with the Tasmota configuration. The short wake time makes it a pain to issue changes later.
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.
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.
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.
I've been doing a little home automation with Home Assistant recently and this involved putting temperature sensors in every room. I started out with some ugly stripboard SHT11 based things but they were unreliable and inaccurate.
