I have a vague aspiration to build networked bodycams for our Sci-Fi LARP system. You see it often in movies where people back in a control room can see what the 'away team' are doing. Action movie emulation is where we're at.
Since the first ESP32 based camera boards arrived I've been eyeing them up but there's been a sudden influx of cheap ones (about £4.20 delivered) on Banggood and I bought a small batch to play with.
There are a few bits of example code floating around on the Internet so I uploaded what proved to be a very solid 'streaming webcam' sketch and I'm very impressed. Now I need to port my ESP-Now mesh network code to ESP32 and see if I can do video, or at least frequently refreshing stills, over that.
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.
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.
Solar charging
I'm still working on my mesh network stuff but sometimes it feels like I'm working on so many things at once I never make any progress with any of them.
One of the things I want to make sure I have in place is a number of fixed nodes with decent batteries and passable antennas to do the heavy lifting of infill coverage.
I built ten of these and they worked but battery life with cheap NiMH cells was disappointing so I'm doing a second iteration where I'm throwing more serious batteries, better efficiency and top-up solar charging into the mix. The hope with this is that they will run for 2-3 days at least.
For the batteries I've purchased twenty brand new 2500mAh 18650 LiPo cells, planning to put them together in pairs. A quite naive calculation on battery life, assuming the nodes use about 80mA gives me 60 hours, but I know it'll work out less than this.
For efficiency I'm looking at an efficient PAM2301 switching regulator recommended to me by Mike, who's used them in some of his projects. This will generate the 3.3v needed for the ESP8266.
I'm also going down to ESP8285 modules with no status LEDs or clutter, which should help a bit. I've yet to measure their typical load.
The solar charging is a whim that may not deliver. I've picked up ten 1W 5.5V panels from China and after a bit of reading round the subject settled on using an MCP73871 charger chip and bought an official development board to play with.
With LiPo cells you can't just connect a charger to the batteries at the same time as the load. The charging algorithm for LiPos has constant current/constant voltage modes to ensure safe charging and attaching the load directly during charging messes with that.
The MCP73871 was very specifically chosen because it's not a simple charger but a power management device designed to supply power to the load as a priority, charging the battery if there's excess current available from the supply. It also manages switching the load from the incoming supply to the battery when there's no incoming supply. It's not an MPPT charger but it does reduce charging current when the supply voltage drops and tries to stabilise it. Which should achieve a similar end.
If I've read the datasheet correctly all this means it should fairly transparently 'top up' the 18650s if the solar cells can provide enough current.
There's a LOT of IF coming off this plan. One of the 1W panels delivered 100mA in the morning sun to an LED so I may not be completely out of luck.
I've got some INA219 current monitoring modules coming too so I'm hoping to get some fairly true readings of how this all behaves by putting them into the proof of concept build. I may be able to monitor the panel, charger and battery individually at the same so I can see what's going on and do fairly good efficiency measurements.
Or I may just give up, buy some bigger panels, better NiMH cells and connect the panels straight to them via a diode. :-)
One of the things I want to make sure I have in place is a number of fixed nodes with decent batteries and passable antennas to do the heavy lifting of infill coverage.
I built ten of these and they worked but battery life with cheap NiMH cells was disappointing so I'm doing a second iteration where I'm throwing more serious batteries, better efficiency and top-up solar charging into the mix. The hope with this is that they will run for 2-3 days at least.
For the batteries I've purchased twenty brand new 2500mAh 18650 LiPo cells, planning to put them together in pairs. A quite naive calculation on battery life, assuming the nodes use about 80mA gives me 60 hours, but I know it'll work out less than this.
For efficiency I'm looking at an efficient PAM2301 switching regulator recommended to me by Mike, who's used them in some of his projects. This will generate the 3.3v needed for the ESP8266.
I'm also going down to ESP8285 modules with no status LEDs or clutter, which should help a bit. I've yet to measure their typical load.
The solar charging is a whim that may not deliver. I've picked up ten 1W 5.5V panels from China and after a bit of reading round the subject settled on using an MCP73871 charger chip and bought an official development board to play with.
With LiPo cells you can't just connect a charger to the batteries at the same time as the load. The charging algorithm for LiPos has constant current/constant voltage modes to ensure safe charging and attaching the load directly during charging messes with that.
The MCP73871 was very specifically chosen because it's not a simple charger but a power management device designed to supply power to the load as a priority, charging the battery if there's excess current available from the supply. It also manages switching the load from the incoming supply to the battery when there's no incoming supply. It's not an MPPT charger but it does reduce charging current when the supply voltage drops and tries to stabilise it. Which should achieve a similar end.
If I've read the datasheet correctly all this means it should fairly transparently 'top up' the 18650s if the solar cells can provide enough current.
There's a LOT of IF coming off this plan. One of the 1W panels delivered 100mA in the morning sun to an LED so I may not be completely out of luck.
I've got some INA219 current monitoring modules coming too so I'm hoping to get some fairly true readings of how this all behaves by putting them into the proof of concept build. I may be able to monitor the panel, charger and battery individually at the same so I can see what's going on and do fairly good efficiency measurements.
Or I may just give up, buy some bigger panels, better NiMH cells and connect the panels straight to them via a diode. :-)
Don't shoot the nuclear weapons
This weekend I was off to our anthology LARP event and I was going to spend the whole time as 'crew' where you're the 'baddies' or 'extras' needed to make the story happen.
The Saturday was a Legends of Tomorrow-esque setup with the players travelling through time to chase down a temporal conspiracy. So we had a Victorian military demonstration, 70s CND protest and 23rd Century spaceship launch in one story line.
Games like this often need props and I volunteered to make something. As part of the 70s section I ended up putting together a 'suitcase nuke', the sort of thing beloved of 90s action movies. The game organiser built a WWI tank and replica of the HG Wells time machine out of wood, carpet roll tube, random household junk and Correx sheet. I got the easy job.
This prop is a big pile of old-school Arduino stuff: a matrix keyboard, hand-wired LEDs for the 'plutonium core' and a 32x8 LED matrix driven by MAX7219 chips to show the countdown timer on. All housed in an equipment case a friend gave to me and accessorised with some 3D printing. It was a bit last minute and I made a deliberate effort to use up a bunch of stuff that was sitting in my storage boxes. The only thing I spent money on was a sheet of MDF and some spray paint.
It does the LED countdown thing and if you unscrew the display it conforms to the "help I'm being disarmed" trope of the counter speeding up, but you can quite easily switch it off.
It was quite a simple from a technical perspective but good fun in the game and there's plenty of scope for it to be re-used.
The Saturday was a Legends of Tomorrow-esque setup with the players travelling through time to chase down a temporal conspiracy. So we had a Victorian military demonstration, 70s CND protest and 23rd Century spaceship launch in one story line.
Games like this often need props and I volunteered to make something. As part of the 70s section I ended up putting together a 'suitcase nuke', the sort of thing beloved of 90s action movies. The game organiser built a WWI tank and replica of the HG Wells time machine out of wood, carpet roll tube, random household junk and Correx sheet. I got the easy job.
This prop is a big pile of old-school Arduino stuff: a matrix keyboard, hand-wired LEDs for the 'plutonium core' and a 32x8 LED matrix driven by MAX7219 chips to show the countdown timer on. All housed in an equipment case a friend gave to me and accessorised with some 3D printing. It was a bit last minute and I made a deliberate effort to use up a bunch of stuff that was sitting in my storage boxes. The only thing I spent money on was a sheet of MDF and some spray paint.
It does the LED countdown thing and if you unscrew the display it conforms to the "help I'm being disarmed" trope of the counter speeding up, but you can quite easily switch it off.
It was quite a simple from a technical perspective but good fun in the game and there's plenty of scope for it to be re-used.
Creality Ender 2
I've been having some issues with my old RepRapPro Ormerod 2 3D printer, lots of it because I've run it hard and it's ageing badly.
Various chassis parts have cracked and needed replacing and a while back I had to replace the Duet3D controller board when the MOSFET for the heated bed burned out.
So on a whim a got a second printer
This Creality Ender 2 is an astonishingly cheap FDM 3D printer that a whole bunch of people have been picking up recently. You can get one for ~£100 which is amazing given they turn out good quality prints.
Overall design is similar to my Ormerod with a single upright, making for a very compact printer. The only cheesy bit is the PSU which is one of those generic silver box ones and the safety cover is functional but naff.
Annoyingly, it proved to be DOA as the PSU trips out as soon as the hot end starts to heat. It's a drop-ship direct from China and I have asked for a replacement PSU rather than try and get the whole thing replaced.
Various chassis parts have cracked and needed replacing and a while back I had to replace the Duet3D controller board when the MOSFET for the heated bed burned out.
So on a whim a got a second printer
This Creality Ender 2 is an astonishingly cheap FDM 3D printer that a whole bunch of people have been picking up recently. You can get one for ~£100 which is amazing given they turn out good quality prints.

Annoyingly, it proved to be DOA as the PSU trips out as soon as the hot end starts to heat. It's a drop-ship direct from China and I have asked for a replacement PSU rather than try and get the whole thing replaced.
Resurrecting the Tilda MKe - part 2
Some time back I got interested in unravelling the set of libraries/board definitions for the 2014 EMFCamp badge so I could use it with modern versions of the Arduino IDE and associated libraries.
Well I had another fiddle over the last couple of days and now have the display working which was the last big hurdle. This was really just poking through other peoples' work from 2014 and working out where to stuff the information in a different library to make it work.
The display controller is supported by the common U8g2 library as it's an ST7565, but there's very little info about the JHD12864-G13BSW screen itself. So I initially got a visible image but with unusably low contrast and viewing angle. Wading through the old library showed up the settings needed to set the bias voltage on the display and a quick read of the U8g2 FAQ showed me how to feed this to it without having to change anything in the library. So now here's a working demo of one of the example sketches that come with the library.
I really need to build a demo sketch that does all the functions but in the meantime here's something that will drive the screen if you've got one of these and want to play with it.
Well I had another fiddle over the last couple of days and now have the display working which was the last big hurdle. This was really just poking through other peoples' work from 2014 and working out where to stuff the information in a different library to make it work.
The display controller is supported by the common U8g2 library as it's an ST7565, but there's very little info about the JHD12864-G13BSW screen itself. So I initially got a visible image but with unusably low contrast and viewing angle. Wading through the old library showed up the settings needed to set the bias voltage on the display and a quick read of the U8g2 FAQ showed me how to feed this to it without having to change anything in the library. So now here's a working demo of one of the example sketches that come with the library.
I really need to build a demo sketch that does all the functions but in the meantime here's something that will drive the screen if you've got one of these and want to play with it.
/*
HelloWorld.ino
Universal 8bit Graphics Library (https://github.com/olikraus/u8g2/)
Copyright (c) 2016, olikraus@gmail.com
All rights reserved.
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list
of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or other
materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include <Arduino.h>
#include <U8g2lib.h>
#ifdef U8X8_HAVE_HW_SPI
#include <SPI.h>
#endif
#ifdef U8X8_HAVE_HW_I2C
#include <Wire.h>
#endif
/*
U8glib Example Overview:
Frame Buffer Examples: clearBuffer/sendBuffer. Fast, but may not work with all Arduino boards because of RAM consumption
Page Buffer Examples: firstPage/nextPage. Less RAM usage, should work with all Arduino boards.
U8x8 Text Only Example: No RAM usage, direct communication with display controller. No graphics, 8x8 Text only.
This is a page buffer example.
*/
// Please UNCOMMENT one of the contructor lines below
// U8g2 Contructor List (Picture Loop Page Buffer)
// The complete list is available here: https://github.com/olikraus/u8g2/wiki/u8g2setupcpp
// Please update the pin numbers according to your setup. Use U8X8_PIN_NONE if the reset pin is not connected
#define BOARD_SPI_SS2 (52u)
#define LCD_CS BOARD_SPI_SS2
#define LCD_POWER (40u)
#define LCD_BACKLIGHT (35u)
#define LCD_BACKLIGHT_ON HIGH
#define LCD_BACKLIGHT_OFF LOW
#define LCD_A0 (38u)
#define LCD_RESET (34u)
#define CMD_SET_BIAS_9 0xA2
#define CMD_SET_BIAS_7 0xA3
//Screen is JHD12864-G13BSW and ST7565 controller
U8G2_ST7565_ERC12864_1_4W_HW_SPI u8g2(U8G2_R0, /* cs=*/ LCD_CS, /* dc=*/ LCD_A0, /* reset=*/ LCD_RESET); // - Works well!
void setup(void)
{
//Turn on the display
pinMode(LCD_POWER,OUTPUT);
digitalWrite(LCD_POWER,LOW);
//Turn on backlight
pinMode(LCD_BACKLIGHT,OUTPUT);
digitalWrite(LCD_BACKLIGHT,LCD_BACKLIGHT_ON);
//Start display
u8g2.begin();
//Set the bias so it's legible
u8x8_cad_StartTransfer(u8g2.getU8x8());
u8x8_cad_SendCmd(u8g2.getU8x8(), CMD_SET_BIAS_9);
u8x8_cad_EndTransfer(u8g2.getU8x8());
//Set some contrast now the bias is OK
u8g2.setContrast(32);
}
void loop(void) {
u8g2.firstPage();
do {
u8g2.setContrast(32);
u8g2.setFont(u8g2_font_ncenB10_tr);
u8g2.drawStr(2,14,"Hello World!");
u8g2.drawFrame(0,0,128,64);
} while ( u8g2.nextPage() );
}
Size matters more than ever
A few years ago I commented on how a smaller board makes more projects possible. Then it was comparing an Arduino Uno with a Nano.
Now I'm looking at the ESP8266 boards I've been using and thinking about the practicalities of building a wearable sensor/tracker. While I can never hope to replicate the level of integration in a commercial project I am looking for something to keep it as small as possible.
I had been working on some sneaky use of the pins on an ESP-01 module in my first prototype but it's still quite chunky and the 8-pin header makes it quite tall.
Time marches ever on and now decently packaged ESP8285 modules have appeared in the usual places. These are a minor update to the old faithful ESP8266 with integrated flash memory but otherwise backwards compatible. The integrated flash makes for a slightly smaller module and offers a certain guarantee of the quality of that flash as it's coming straight from Espressif. Some cheap ESP8266 based modules come with questionable quality flash memory.
Here's a Wemos D1 Mini, ESP-01 and the new ESP-M2. It doesn't save you much over the ESP-01 but it delivers a ton more pins and can be surface mount soldered onto a board.
Now all I need to do is make a breakout board so I can do some testing with it before I have some boards made.
Now I'm looking at the ESP8266 boards I've been using and thinking about the practicalities of building a wearable sensor/tracker. While I can never hope to replicate the level of integration in a commercial project I am looking for something to keep it as small as possible.
I had been working on some sneaky use of the pins on an ESP-01 module in my first prototype but it's still quite chunky and the 8-pin header makes it quite tall.
Time marches ever on and now decently packaged ESP8285 modules have appeared in the usual places. These are a minor update to the old faithful ESP8266 with integrated flash memory but otherwise backwards compatible. The integrated flash makes for a slightly smaller module and offers a certain guarantee of the quality of that flash as it's coming straight from Espressif. Some cheap ESP8266 based modules come with questionable quality flash memory.
Here's a Wemos D1 Mini, ESP-01 and the new ESP-M2. It doesn't save you much over the ESP-01 but it delivers a ton more pins and can be surface mount soldered onto a board.
Now all I need to do is make a breakout board so I can do some testing with it before I have some boards made.
D1 Mini breakout
I'm a big fan of the Wemos D1 Mini and Mini Pro as the basis of microcontroller projects.
They're cheap, the ESP8266 chip is powerful and can be used with several development environments/languages. You can program them in C/C++ with the official Espressif SDK, but also the Arduino IDE where support is excellent. They'll also run more modern interpreted languages like MicroPython and Lua, again with good support if some memory limitations.
Most of the time, people consider ESP8266 boards for IoT type projects but you don't have to use the WiFi, it can be switched completely off and at heart they're a 80/160Mhz 32-bit device with enough GPIO to handle many small projects. About the only thing they suck at is low power/sleep which is poorly implemented by comparison with other modern boards.
What they do lack is such a large ecosystem of 'shields' and breakouts. Wemos make their own but they're all a bit 'Arduino sensors 101' type things.
I saw these chunky screw terminal breakout boards mentioned on Twitter and while I have no immediate use for them I picked a couple up because I know they'll be great for prototyping stuff.
They're cheap, the ESP8266 chip is powerful and can be used with several development environments/languages. You can program them in C/C++ with the official Espressif SDK, but also the Arduino IDE where support is excellent. They'll also run more modern interpreted languages like MicroPython and Lua, again with good support if some memory limitations.
Most of the time, people consider ESP8266 boards for IoT type projects but you don't have to use the WiFi, it can be switched completely off and at heart they're a 80/160Mhz 32-bit device with enough GPIO to handle many small projects. About the only thing they suck at is low power/sleep which is poorly implemented by comparison with other modern boards.
What they do lack is such a large ecosystem of 'shields' and breakouts. Wemos make their own but they're all a bit 'Arduino sensors 101' type things.
I saw these chunky screw terminal breakout boards mentioned on Twitter and while I have no immediate use for them I picked a couple up because I know they'll be great for prototyping stuff.
Subscribe to:
Posts (Atom)