One of the questions was how big does the mesh scale?
Frankly I don't know.
My aim is to support about 40 nodes actively sending data every few seconds because location tracking is my primary goal. This feels achievable.
However to prove this I'll either have to build it or use some network modelling software. I like building stuff.
I have over time bought quite a few ESP8266 modules for various projects, a lot of them speculatively or for things that are over and done with.
- 12x Wemos D1 Mini
- 12x Wemos D1 Mini pro
- 10x ESP-01S 1MB flash
- 10x ESP-01S 512KB flash
So when I allow for a few I've lost, given away or killed that's about forty.
Plugging all this in at the same time would be a pain in the neck. So I've built a little test rig that allows me to get fourteen ESP-01S running off my bench power supply.
Plugging all this in at the same time would be a pain in the neck. So I've built a little test rig that allows me to get fourteen ESP-01S running off my bench power supply.
This circuit is simply a bare minimum of suplying power and a pullup resistor to CH_PD so it boots. In principle you need pullups on GPIO0 and GPIO2 as well but in my experience they boot fine with these pins left floating, at least reliably enough for a little testing.
This took a few leisurely hours to build as there was quite a chunk of soldering, especially as I added individual on/off switches.
Running off my bench PSU it draws 1.1-1.2A which is quite a lot. I need to work on my power efficiency, but given my desired runtime is 'all day' I reckon I can get there. The outdoor nodes lasted about eight hours, which is about in line with this power draw given the rubbish batteries I used.
Compared to a sensor that sleeps almost all the time and draws microAmps when doing so this power usage is awful, but my kit just can't sleep as it has other jobs to do, one of which is always being there to relay traffic for other nodes.
If the nodes were connecting to APs, the various radio sleep modes would reduce consumption massively as the DTIM table means they know when to wake up. Without an AP to manage this I'd have to create my own scheduling algorithm equivalent to DTIM. This is a job for later if I can't make improvements in other ways. I've already got a time sync protocol it might just need to be more accurate.
I did a little video of this test rig running...
No comments:
Post a Comment