Is it feasible that we could create an ultra low power node that wakes every X hours, sends any information it has, routes for other nodes and goes back to sleep? Every node could be time sync’d from a master exit node that has cellular or sat connectivity to the outside world.
I’m thinking of a use case in pest control where remote trapping stations are checked monthly regardless as to whether they have been set off or not. Nodes would only have a tiny amount of data to send, maybe status, voltage and some environmental data if deemed useful.
Nodes would often be only 100m apart, in dense bush and undulating terrain and form lines many kilometres long. Some nodes could likely “see” 20 nodes ahead, others only one.
Power could be supplied by a solar charged super capacitor with energy harvesting to eke as much out of the sun as possible in shady situations.
I imagine a traditional hub and spoke model is more suited for ultra low power nodes as they only wake on an event but then are limited to each node being able to “see” the hub. If a mesh architecture could be implemented I reckon it would enable a lot of “smart” devices out in the wilderness.
Now if these nodes could also log the RSSI of a “ping” transmitted from radio tagged wildlife and estimate its position…I would be fizzing!
Oh yes, but even better than that. I think the following two things are feasible:
Since all nodes have a shared notion of the common time, it is super feasible to have nodes stay completely powered down 95% of the time (even including the radio rx which - for the time being - is always powered, but that will change). Because they know time we can (eventually) do cool stuff like “all nodes in the mesh stay completely asleep for 14 out of every 15 seconds.” During that magic second if anyone has messages to send they start sending, and as long as the network is still chatting away all nodes keep forwarding messages as needed. This will dramatically increase battery life - I’ve got some test configurations in the power management spreadsheet which you might find interesting. (There are some other notes about this in docs/software/TODO.md). I’m super excited to work on this someday (or even better - have other folks also work on it )
But even without this optimization, one of the reasons I’m excited about @Syed’s product/board is: This board should be able to do exactly what you describe even without having the mesh sleep (because the nrf52 and the sx1262 have absurdly low power draws while in receive mode). According to my spreadsheet his board should be able to run indefinitely as a “router” with a quite small solar cell. So you could place one of these devices (discreetly) in a tree that has good line of sight for a region and it would happily route packets for that whole area (using just a tiny solar cell).
This sounds like it could really be a game changer for low power, low cost nodes!
I assume there is significant communication overhead with a mesh network to establish the network, build routing tables etc? Would a periodically waking network handle discovering new nodes and the like? I guess it all comes down to how much power is available at the node to keep it on long enough.
Also after having another look at it, super caps aren’t as energy dense as I thought although they do have insanely high cycle life. A better option it seems would be LiFePO4 batteries. Cycle lives in the 1000’s even 10,000’s if cycled to a low depth of discharge and good temperature range (-20c - +70c). With a suitable solar setup it could mean decades of operational use.
I see the NRF52840 has 1 MB Flash, 256 KB RAM. There is a product by Insight SiP, the ISP4520, that combines the NRF52832 with the SX126X LoRa modem. The NRF52832 is only 512 kB Flash and 64 kB RAM. Is Meshtastic feasible on the NRF52832 with less Flash and RAM?
re: isp4520
Interesting! I hadn’t heard of that one. Mostly I proposed nrf52840 because it had room to grow but that is a great find. Flash capacity would not be a problem. RAM would be ‘okay’ - the current meshtastic load on nrf52 uses about 32KB, so it would be a little tight but doable (if you assume future possible desires for that RAM/new features).
Yes They are expensive but nowadays it is not hard to produce such circuits with new assembly service from PCBWAY & JLCPCB. The custom pcb can include all other modules such as Lora, GPS , battery charging circuit , display etc. in small package.
There are some open source miniature ESP32 devices too.
I’m no expert, but I remember when I worked in ITC integration time sync was a big deal. GPS was used as a backup to set the clock if network time was unavailable. I guess this was because most systems had inherent inaccuracy and drift in their internal clocks. I think accounting for the potential time variability between devices would limit how short any communication window could be for devices with no internal gps.
The trick might be to get enough battery power in that form factor to be useful. Time will tell I guess and would depend a lot on how transmit intensive the specific mesh is.
@happytm Meshtastic in Slater Mini form factor could be usable, especially if equipped with GPS, a PIFA (Planar Inverted F Antenna), a SMA connector (for external antenna), a small battery, and a USB connector.
You could then use the device as a tiny mesh communicator (mainly for receiving to save battery), or as a full featured mesh node, if equipped with a good antenna and a decent power source.
I’m sponsored by JLCPCB and friends with the Lilygo people so can probably convince them to make and burn firmware to any stable hardware we think will do decent numbers on Aliexpress. Best, cheapest way to get a lot of them out into the wild.
This spreadsheet might be useful for you. Measured values are in bold. You can plug in whatever battery you want and get estimated meshtastic battery life. The current figures might be slightly better/worse - it has been about a month since I last measured:
ESP32 usually is not considered as low power device.But in following link Stuart Robinson did some experiments running at low cpu frequency and he came to conclusion that they are not as bad at a lower frequency.
)