Existing sensor network - upgrading in Emergency to Meshtatic - Questions

[Neon22]

Shape of the existing network

I have a Lora network of sensors. Underlying it is Radiolib (which I believe meshtastic also uses).

The network topo is a single master and N widely distributed slaves which do the sensing.

• The sensor is checked once every N minutes and if changes are detected then the frequency of checking is increased (sleep less) and messages are sent back to the master for evaluation.
• The master uses Seeed XIAO S3 with the sx1262 lora module. This S3 uses its wifi to communicate locally to a house network or phone app to indicate sensor network status to owner. Uses home electrical power and 18650 backup. Sleeps very little.
• Individual sensor nodes are Seeed XIAO nRF52840 (and same lora module) which run on solar/18650 (ble, no wifi, mainly sleeping).
• These are widely distributed (approx 1km from each other)
• Neither node uses a display - black boxes. (setup using ble/phone app.)
• These sensor networks are located only in rural communities but have a wide geographic overlapping spread.

Change

I am considering changing the underlying lora comms to use meshtastic instead of my own simple direct comms because:

• it looks like I can add my specific sensor using examples in the meshtastic github repo (returns single float and uses a UART for sensor comms)
• If an emergency occurs, then the user (network owner) could choose to allow all the sensor nodes to enable meshtastic comms for emergency duration.
  • in my area, we are getting increased number of atmospheric rivers and the flood/erosion damage can take out the region for up to 11 days in a row before power can be restored.
  • Of course there is not much solar availability at the beginning of these events.
  • local cell towers last for only a few hours before failing and all comms is lost as copper network has been removed by telcos.

Advice

If anyone thinks this is a good idea, then please comment with advice:

• would I enable this by dynamically changing the role of the nodes or ?
• my current network sleeps often, what wakeup options do I need to consider ?
  • what effect does sleeping have on message passing in meshtastic?
  • I could try to synchronise the wakeups of nodes so a lot of sleeping can be done and energy conserved, and still get messages passed. Is this even a good idea ?
• primary external network connection points are the base stations but many of the distributed sensor nodes do overlap the networks of other owners and can see other people's networks (they are widely distributed).
• The nRF52840 are quite power efficient but not sure how traffic volume affects battery lifetime.

Any other things people can think of about how to do this, whether its a good idea or not.

[mverch67]

If your sensor logic could trigger a GPIO pin directly then your nodes could sleep all the time (even deep sleep) and wake only up by GPIO (or other time based events e.g. if you want to transfer the battery status every 6h).
If I understood your scenario correctly then you have a star topology and not a mesh topology, i.e. the slaves are not repeating the sensor data of other nodes. If you don't make use of this mesh functionality then meshtastic does not give you much more functionality besides the available ecosystem of apps and flashers, GPS positioning, etc.
For your sensor scenario the current meshtastic "detection sensor" role could fit. However, for an optimised scenario (with GPIO enabled sensors) I would see a new role ("alarm" node) which basically always sleeps (see above) to achieve maximum battery lifetime ( ... ten years ...) in case it opts out from listening/forwarding other sensor packets.

[Neon22]

Thanks for your feedback.

1. Topology
   Its not really a star because some of the nodes are so far away they relay through other sensor nodes before they reach the "master". So I would say its a mesh - but its not a mesh where some nodes may move

2. Alas my sensor cannot run independently. A calculation needs to occur, so the sensor node needs to wake up, do the sensing and calculation, if there has been a change - send a message. The comm protocol is simple because the master is only a couple of hops away and the topology is only just stable enough to cope with occasional sensor dropouts/failures/low battery

3. The main reason of considering moving to Meshtasticis for when an local emergency happens and all kinds of comms could be facilitated using an existing comms mechanism (Meshtastic)

4. Solar and a battery is ok for sensor node lifetime. battery replace once per year (or when failing) is quite manageable.