msws
January 11, 2021, 6:51am
1
How to increase hop_limit to packet sent from Android APP?
I can see all the nodes in the application on the map.
I increased #define HOP RELIABLE from 3 to 5 in “Mesh Types.h”. Now I can also see position and node info packets from Tbeam2 in the Python API using Tbeam1. But I cannot send a text message to Tbeam2.
1 Like
Alas, no ui for this exists in the Android app. But if you add a bug on meshtastic-android I should be able to add this in a couple of weeks.
5 Likes
fvsura
January 16, 2021, 3:18am
3
Hi,
You can change the hop limit by using the Python API.
Here’s the writeup of the mesh algorithm.
# Mesh broadcast algorithm
## Current algorithm
The routing protocol for Meshtastic is really quite simple (and suboptimal). It is heavily influenced by the mesh routing algorithm used in [Radiohead](https://www.airspayce.com/mikem/arduino/RadioHead/) (which was used in very early versions of this project). It has four conceptual layers.
### A note about protocol buffers
Because we want our devices to work across various vendors and implementations, we use [Protocol Buffers](https://github.com/meshtastic/Meshtastic-protobufs) pervasively. For information on how the protocol buffers are used wrt API clients see [sw-design](sw-design.md), for purposes of this document you mostly only
need to consider the MeshPacket and Subpacket message types.
### Layer 1: Non reliable zero hop messaging
This layer is conventional non-reliable lora packet transmission. The transmitted packet has the following representation on the ether:
- A 32 bit LORA preamble (to allow receiving radios to synchronize clocks and start framing). We use a longer than minimum (8 bit) preamble to maximize the amount of time the LORA receivers can stay asleep, which dramatically lowers power consumption.
After the preamble the 16 byte packet header is transmitted. This header is described directly by the PacketHeader class in the C++ source code. But indirectly it matches the first portion of the "MeshPacket" protobuf definition. But notably: this portion of the packet is sent directly as the following 16 bytes (rather than using the protobuf encoding). We do this to both save airtime and to allow receiving radio hardware the option of filtering packets before even waking the main CPU.
- to (4 bytes): the unique NodeId of the destination (or 0xffffffff for NodeNum_BROADCAST)
show original
1 Like
btw: the reason I set the default hop limit at 3 is that the range on these radios (with default settings) is QUITE high. So except for really unusual topologies, for most current small meshes, I think 3 will probably be sufficient
(and every extra hop - since all radios on a channel (currently) share the same frequency - burns up a lot of shared airtime)
I can imagine the “unusual topography” may actually become a real-world use case. Buildings and hills will attenuate the signal quite a bit.
In San Francisco, if I’m going through a block of houses where one node is about 1m from the ground level, it’s difficult to get more than 1/10mi (~0.15km).
1 Like
fvsura
January 16, 2021, 4:55pm
7
Created a thread on the topic, I’ve started studying the stuff, I’ll keep you posted with what I come up with.
Hi, following from a couple of previous forum discussions, I think this topic deserve a thread.
I’m re-reading the source for the message distribution algorithm
And - oh boy - I think there is a lot of room for improvement.
I’m trying to come up with and idea that works in more than one use case, for example hiking and long-range data transmission.
Also I think the algorithm for message distribution should be at the same time energy-aware and inherently robust to guarantee the delivery of t…
msws
January 16, 2021, 5:43pm
8
Can you give me an example, how to change the hoplimit by Python Api?
If you get a helpful reply please add it to the wiki (if it is not already there).
1 Like
