Utilizing Meshtastic for tracking patrol boats in the Amazon

Hey Meshtastic Community,

Happy to come back experimenting with LoRa after some years innactive in the community. We’ve learned alot from Meshtastic to connect isolated villages and Meshtastic to connect remote villages: Deep in the Amazon, and would like to try something much simpler but for a very real use case, that could have very meaningful impact for indigenous patrols guarding their territories from illegal activities in the Amazon.

We are planning to employ Meshtastic to aid patrol boat operations. Given the challenging terrain and limited connectivity, Meshtastic could be useful in ensuring safety, communication and coordination. Our key use cases are:

  1. Boat Tracking:
  • Objective: To provide real-time location tracking of patrol boats.
  • Implementation: Each patrol boat is equipped with a Meshtastic device that connects to the boat’s Starlink WiFi and constantly sends its GPS location to an online MQTT server. This is the main request which has little to do with LoRa but enables a centralized monitoring system to enhance operational oversight and safety.
  • Hardware: We are considering the T-Beam Supreme for this use case due to its WiFi, GPS and backup battery.
  1. Patrol Tracking:
  • Objective: To track the movement of personnel on patrol activities.
  • Implementation: A person in a patrol group is provided with a Meshtastic device that continuously publishes their GPS location to the mesh network. This setup enables us to monitor patrol routes, ensure the safety of personnel, and coordinate teams effectively even in dense forest areas.
  • Hardware: T-Echo
  1. Extender Node:
  • Objective: To extend the range of the mesh network across challenging terrains.
  • Implementation: We deploy mesh nodes that can be elevated temporarily along patrol paths. These nodes act as extenders, relaying data over greater distances and ensuring that all patrol units remain connected. This solution addresses the connectivity gaps and ensures uninterrupted communication by strengthening the mesh network.
  • Hardware: T-Echo

We are keen to validate whether Meshtastic is indeed the best solution for our specific requirements, particularly for the critical boat tracking aspect (Use Case 1). Additionally, we’d appreciate any recommendations on the devices mentioned or other potential hardware that might better serve our use cases.


I honestly can’t say much about the T-Beam/Echo devices as suitability for ‘client’ devices (1/2), no experience. But assume they ‘work’ fine.

Except maybe for the ‘Extender Node’ (3), if you intended that to be ‘remote’, and not connected to ‘grid’ or other power source (eg a village grid). Ie you want to run it with a ‘solar panel’ just for the node, and a small battery. Implication would be a tree top, or hill top etc.

I dont think ‘client’ devices like this are the most efficient power wise, so less suitable for long term remote usage. (the Supreme does intergrate a battery but again, not great long term)

Again no direct experience, but certainly what seen on the community RAKwireless Wisblock devices are considered most suitable for extender/repeater or router nodes, some of their devices even integrate solar chargers.

So you could run a T-Echo as ‘solar’ extender (nearly any Lora device can do it), but there are probably more suitable devices available.

You Might run into issues, if you want really big networks. Not sure if talking about small local networks, or a big big wide area network. Bigger networks will start running into issues with hoplimit, messages wont make it all the way though the network.

If really big, might consider using MQTT to ‘bridge’ networks. Have ‘local’ lora meshes, for direct connection between ‘clients’ devices (1/2 in your list), but then ‘backhaul’ networks to connect the small area netwroks. This could be MQTT over the internet if there connectivity available in a few places (could even be ‘satellite’ internet!)
… or maybe could consider Lora for long range ‘point to point’ bridges. eg lora devices with high-gain directional antennas, setup for long range links.
The local networks, and long range networks could be connected together with MQTT (running on local devices eg RiPi type devices)

1 Like

That’s great feedback @barryhunter! I don’t think we’re thinking of large networks, I would say a maximum of 5 nodes.

Thanks for the suggestion on the Rak devices, I bought one some years ago expecting it would get support, but never did, so ended up never getting to test it. Looking at this new release seems pretty interesting. I love the idea of using MQTT to bridge networks.

So just to confirm, by configuring Meshtastic MQTT and smart position broadcast we should be able to achieve use case #1, boat tracking, correct?

for #1 please dont forget, that t echo and rak devices dont have wifi, so for the boat it is advices to use some esp32 like t-beam supreme, or maybe some heltec tracker device.

for #2 t echo and rak devices are a good choice, i would prefer longer battery runtime, so for the t-echoes you could carry an extra powerbank to recharge if necessary. ( i think t echo runtime can be less thatn 24 h sometimes.) or some solution with a more hardened rak device, also with bigger battery.

for #3 Some Rak device is best choice, just some medium sized housing with antenna, rak-device and some 10.000 or 20.000 mAh batterys and you have weeks of runtime, even solar is easily possible, if sunhine is available. so this one could even be set up and left at that place for some months for the next mission. t echo is possible here too, but no solar input, will also need extra housing to make watherproof and you have to have functional external power source (like powerbank that does relyable provide constant power) etc.

1 Like

You don’t NEED MQTT for that as such. MQTT would just help if a ‘local mesh’ gets too big.

Normal clients can broadcast their position over the Lora network, and any there device in range (directly or via repeaters etc) will see their latest position report in the Node List.

The ‘smart position’ in general will make it more reliable in that it cuts down on clutter (broadcasting lots of repeat locations). The most important bit would be enabling ‘periodic’ broadcasts of the location (again in Position configuration section)
… you could experiment with the smart position resolution to get ‘optimal’ balance between accuracy and network utilization.

MQTT is only needed, if dont get good long range comms with Lora alone. Its not really about the ‘number’ of nodes as such, its how ‘wide’ the network gets.

5 or even 20 nodes, or even more in all relative close primoxity (that messages can tranverse the entire network with 3 hopes), should be ok with relative ease.

But if you find that to get communication along the river, need say 20 repeaters, messages wont actully make it end to end. Thats where would need to split into ‘zones’ with bridging.

@kilroy those are really good tips on hardware, thanks! I remember when Echos came out, they were publicized as having over a week of battery life, that’s why I thought they would be a good choice. But seems like the Raks are the way to go.

@barryhunter the MQTT in this case would be for keeping track of the sent GPS positions in a cloud database, that makes sense right? I love the bridging idea, but again, don’t think that would be necessary for this specific use-case, as mesh would probably be small.

Ah right I didn’t realize wanting to keep a ‘database’ or log of position reports. Rahter than just sharing current location with the ‘network’.

MQTT itself does not provide that. It just a live ‘relay’ of messages. (not storage)

Would still need a database somewhere (that is subscribed to the MQTT topic), to store the logs. And probably a (possible web based?) interface to provide a view of the data.

So MQTT would facilitate messages being ‘copied’ from devices (either via Lora or direct) - to a ‘centralized’ database somewhere. (and possibly the reverse, could send messages from the centtalized system, to a mesh and devices connected to the mesh. )

1 Like

maybe dont buy the complete rak device for the routers, this is not what you need for routers.
better buy:
all from rak store website:
rak19003 baseboards,
rak4631 module
(or similar in frequency that is the rigth one for brasil?)
maybe rak temp sensors for the router devices to make it more interesting
some big antennas and connectors for the routers (also from rak store )
some 5V solar panels or bigger, but need power managment, as available trhu this forum)
rak battery- and solar- connector cables (from rak store)
and some 18650 batterys and holders ,

put these in some nice electronics housings you can buy or have printed,
big housing with solar for the routers.
or have a look in this forum, there are some ready built very good solar routers availabe by some of the people here ! on etsy or so.

for the personal device, with gps, the complete rak device seems to be nice !

the t-echo devides are very nice too , i have some of these, but original they come with a very small battery,( i think it was around 700mAh) that can be changed to a bit bigger one ( i changed to 1200) , but you cannot expect a week of runtime, specially, when gps is very active.
so the rak device with some 3000mAh gets you more than triple runtime.

1 Like

This system is not safety-of-life reliable. I’ve been working with it since 2021 in an attempt to make a deployable kit that would be suitable for uses like this, and the fact is that it is simply not there.

The hardware (with the sole exception of RAK) is hobby grade, and QA/QC is spotty at best. There is no hardware watchdog, and nodes can and do fail silently all the time.

The mesh algo is not designed to handle critical messages that CANNOT fail to be delivered. it can become flooded with messages, and its failure modes are not graceful- it will simply fail to complete a message delivery, or crash nodes requiring a hard reset.

These are only a few of the problems that currently exist. I know there are people who are trying to use it for life-safety applications like fire service communications, but no competent authority having jurisdiction would approve what are essentially experimental toys for such use.

if you can’t afford anything purpose built, i’d seriously rethink whether you should be doing what you’re doing at all.

(I know the realities of working in the Third World, and I know this advice will fall on deaf ears…but it needs to be said.)

I’d love for this project to become a true open source option for serious use…but it isn’t there yet.