painlessMesh testing

Yesterday I had a go at testing six painlessMesh nodes in a similar situation to the one I need them for. As per usual this is for a LARP prop and we almost exclusively play outdoors in heavily wooded areas. As I discovered with the last networked thing I made, trees are very good at blocking Wi-Fi so you really need to do testing out in the woods.

For this test I invested a chunk of effort into building these nodes fairly robustly into the IP55 box you can see in my first post about them.

Testing based off almost finalised builds has a risk of being a dead end where you've wasted that time in making them almost complete. However if you're going to put them up in the air on poles spread across a wood
and you can't guarantee it won't rain, they need to be robust and vaguely weatherproof.

Putting them on poles was an attempt to make them inconspicuous to passers by but more importantly to stop the signal being blocked by low level obstacles. I had several sectional aluminium poles that allowed me to get the nodes out of eyeline without being so high they were in the canopy of the taller trees. You really don't notice the ones on poles wandering about and I lost one a couple of times before I made the sensible decision to take waypoints with my phone.

After a little experimentation with node placement I got a corridor along the main play area of our game covered. Once the full mesh was up I was able to send packets across painlessMesh from one end to another. So six nodes isn't enough for what I want to do but now I've seen how it scales I know it can be done without getting overly expensive.

I have ordered another six Wemos D1 mini Pro which should allow me to cover as much of this site as I need. My plan for these nodes is to cover a 'corridor' up the middle of the site linking the key locations, but as this is a mesh, once you add in the nodes carried by players and crew it should only get better.

Node placement was done with the useful behaviour of one of the painlessMesh example programs, where it flashes an LED counting out the size of the mesh, like in the video below. I chopped this example code around a little to include an activity LED and remove the 'hello world' stuff but as these nodes exist just to be part of the mesh the code is essentially done now.

The easily visible node count means you can extend coverage by walking away from the last node and when the count drops back to one, just retrace your steps until it rejoins. This gave me a mostly stable mesh really easily without tons of planning or having to consult a screen.

I'm going back to the site again in October and I plan to have at least ten nodes ready by then, mostly limited by having run out of the nice IP55 boxes I got cheaply from Maplin when they were closing down.

Building a painlessMesh ecosystem

I've spent the last week or so messing about with painlessMesh and it's been a mostly straightforward exercise.

As this is all based around microcontrollers, building any kind of monolithic device with multiple roles requires careful thought so I've stuck with an ecosystem of simple single purpose things.

The idea is also that if these are spread around in use then it extends the mesh, instead of having some central server everything speaks to, too far away to be reached.

The main one is pictured here, it's a combination Lasertag sensor & GPS tracker. OK that's two functions but the whole point of what I'm doing is for this thing to be usable. I need to know where people are and what state they're in.

I've also chucked together the following...

• Two relay nodes, as seen before, vaguely weatherproof with external Wi-Fi aerials and the option to connect big Yagis.
• Three compact painlessMesh to USB serial dongles, which allow you to interact with it by sending commands and viewing messages from a computer. These may eventually end up connected to a Raspberry Pi.
• A logger that writes everything it sees to CSV files on an SD card, one file per node, with timestamps.

All this has been chattering away quite happily but I've got a few minor issues...

• The Sensor & GPS node gets a bit overwhelmed and rebooted by the ESP8266 watchdog timer, especially if it's printing a lot of debug information over serial. It can manage 8 or more hours active so ditching the debugging info will I hope render it 100% reliable.
• The USB dongles seem to die when the computer goes to sleep for a long time, which I'm assuming is due to it putting the USB to sleep in some way that they won't recover from.
• Sometimes things just don't join the mesh until you power-cycle them.

None of this seems at all insurmountable, compared to writing my own mesh network library (again) so I'm sticking with painlessMesh for this project.

Going forward I really need to do some range testing of this and I've got a week to get ready for that.

Depending on how much range I get then I may need to do 'caching' of status messages to presently unreachable nodes. So as things move around they get delivered when they come into range. This is not a feature of painlessMesh so I'd be layering it on top, probably using the SPIFFS filesystem on the ESP8266 as storage if there's not enough free memory. Given these nodes will be attached to people moving around it'd basically be automated sneakernet.

I'm still using human readable, verbose messaging but that may have to go. Or perhaps send semi-readable codes with numeric values encoded as hex. Doing a load of parsing of things like latitude and longitude to/from readable strings, something that's kind of trivial on real computers, starts to chip away at available resource when playing with microcontrollers, especially if you want to buffer these up and store them for later delivery. When I wrote my mesh network for Ciseco xRF radios I agonised over whether to use 12 or 16 byte packets and settled on 12.

You had one job

For my ESP8266 mesh project I plan on using ESP-01S modules if I can as I've got at least 16 of them kicking around, maybe more.

Should I need more they're the cheapest way to buy an ESP8266 module, especially with through-hole connections.

They're also very compact. The flipside of this is they only have a couple of conventionally usable GPIO pins and are a pain to work with in other ways. You can't use them in a protoboard because of the double row connector layout. You also need to pull several pins high for them to boot up, change that for programming and so on.

Which is why I've got a load of ESP-01S modules kicking around, I now use WeMos D1 mini boards most of the time I want to use use an ESP8266 in something.

With a view to using this stash of components up I bought these little special purpose USB-Serial "ESP-01S link" adaptors.

Which didn't work.

I was surprised as the stuff I get from Banggood is almost without exception good, I don't think I've ever had anything completely duff from them apart from this.

A bit of poking around showed they don't pull the CH_PD pin high, which is needed for the ESP-01S to boot. So I've soldered a little link on the bottom (see picture) and now they're perfect. With a button and a couple of more links they could be configured for programming the ESP-01S but I'm not fussed about that. I want these as diagnostic tools.

I've written some minimal code that lets you use one as a 'bridge' to painlessMesh over a USB serial port. It prints any incoming packets from the mesh in a simple text format and you can send unicast or broadcast packets. An ESP-01S in one of these adaptors makes for a nice tidy little 'dongle' to work with.

I might cook up a simple UI to get a list of nodes, topology and so on, but this is all I need for now.

Is painlessMesh really painless?

I should blog more, I have been doing stuff, honest.

Anyway I have plans for more mesh networked, location aware stuff. While I am going to try and sort out the Tilda EMF badges I have, the proprietary Ciseco radio tech in them is obsolete. It's great but I can't buy any more so need a new, cheap, way to put things together. Then maybe bridge the two technologies together.

Going back to the time when I was using the Ciseco radios, Wi-Fi on microcontrollers was a pain and expensive. Then the ESP8266 arrived and changed that. It's now cheap as chips and a very mature platform for tinkering with. Wi-Fi has loads of downsides for the sort of things I want to do but it is ubiquitous. So I'm going to do some evaluation of it as a basis for my next project of this sort.

I've settled on using the painlessMesh Arduino library to do the lifting for me and have just built a test node comprising of a WeMos D1 mini Pro with external antenna in a waterproof box along with battery, charging connector and some indicator lights.

You can configure painlessMesh nodes as being 'static' so they are more likely to be a hub in the mesh and my plan is to have a few boxes like this to help keep the wearable nodes in touch.

The painlessMesh API also includes some nice functions for finding out what nodes there are and how they're connected so I aim to build a tool that prints that out allowing me to check how well connected the mesh is and also 'ping' things to check them.

If ESP8266/32 and painlessMesh doesn't stack up I'll try LoRa, which should be better suited in some ways. However LoRaWan means playing nicely with the standard for gateways and this is very limited in bandwidth and talk time etc. Using just dumb broadcast LoRa radios would be antisocial to any nearby LoRaWAN and mean writing my own mesh network code. Again.