Need help getting a repeater to work

Support
1

Hi everyone. I am using LilyGo T-beam sx1262 lora board, RS485 sensor to ESP32 board. Right now I have 2 lora boards successfully receiving data from the sensor and ESP32 board and sending that to their channel which my 3rd lora device at homebase receives. My next step was to test how the repeater works to help cover a wider range for my sensor to homebase. I wanted to take one of my senders and configure it to be a repeater.

What I want it to do:
-Sender sends data message to the shared channel.
-If the homebase is too far away, have the repeater take the message in the channel received from sender and send it again to the channel.
-Homebase then receives the repeaters message as if it was sent from the sender.

This is in theory what meshtastics repeater should be doing correct?? So far the repeater is not doing anything and the homebase is still just receiving the message from the sender.

If all 3 devices are within range of each other, will the homebase receive 2 messages? One from the sender and one from the repeater.

Does the repeater have some sort of check that if the message was sent to the other devices in range properly then it just doesnt repeat the message?

2

This is probably the main code to look at to figure out repeater behaviour

Havnā€™t managed to decode all the exact behaviour.

but in general a REPEATER will rebroadcast most packets. But it might abort it, if its already seen a ACK. (if direct messages are obseved, and it already seena reply, it doesnt need to continue forwarding - the receiver already got it!)

Also a more general explanation

ā€¦ in particular normal cleitns (not just routers/repeaters) do partipate in a mesh, so often you might not need to explicitly setup one a repeater. The ā€˜flood routingā€™ will work with normal clients.

1 Like
3

Oh okay thank you! Thereā€™s so many pages to look through, I must have missed that one.

So I should be able to leave them both set up as clients/senders and configure them to have a hop limit > 0. That should in theory do what I want it to with them already being able to participate in the mesh. Though if they try to send their own message at the same time it will show as already busy and probably not hop correctly and rebroadcast the further away message. (Is what Iā€™m thinking, so just donā€™t let them send at the same time.)

I guess I will have to go for a walk and figure out how far they can reach and hop. What do you think a good range to put them apart would be?

4

The default ā€˜hop limitā€™ is usyually 3. Which is usually enough for many meshes, of at least modest sizes. Really big meshes might need bigger.

ā€¦ with the hop limit of three, should get reasonable behaviour pretty much of of the box.

If multiple messages try to be sent at once, they should pause and wait for the network to clear. Sending devices should od ā€˜actitity detectā€™ on the channel to make sure the channel appears clear by sending.

ā€¦ so unless your network is heavily congested shouldnt have to worry about ā€˜sending at same timeā€™

1 Like
5

Not sure but I think in ā€œrepeaterā€ mode with no decode - apart from not being visible it does not increment the hop count. or maybe I am wrongā€¦

6

All repeaters/nodes using offical Meshtastic firmware will decrement the hop_limit when forwarding
visible here ttps://github.com/meshtastic/firmware/blob/7bcb8f1fee51ee100c4883350d85a24ce406a692/src/mesh/FloodingRouter.cpp#L49

There is separate talks of alternate repeaters that dont decrement the count for use in special circumstances. (eg in a cave, that may need LOTS of repeaters, as there is little direct line of sight) - but wonā€™t be using the offical firmware.
ā€¦ there is lots of fear uses would enable such a setting when its unwarented.

7

It would make sense - but this means the hop count is stored ā€œoutsideā€ the encryption ?

8

Yes, there is a 16 byte ā€˜headerā€™ that is not encoded, see: Mesh Broadcast Algorithm | Meshtastic

Allows repeaters (or any node really) to be able to forward the packet without being able to decode it.

9

Levy,
Iā€™m very interested in your RS485 > ESP32 > Meshtastic.
Iā€™m experimenting with reporting Extreme Rainfall and Flood Height via Meshtastic.

The rainfall is at present Patrick Egloffs GitHub - tk5ep/WX-station-LoRa-WiFi: An APRS LoRa weather station with a TTGO module. but later will be off-the-shelf Wx station via (parts of) https://docs.openmqttgateway.com/ and GitHub - NorthernMan54/rtl_433_ESP: Trial port of the rtl_433 Library for use with OpenMQTTGateway on a ESP32 and a CC1101 Transceiver

The flood height will be some type of ultrasonic sensor, and one of these I am testing is https://www.seeedstudio.com/RS485-750cm-Ultrasonic-Level-Sensor-p-5587.html

So I am interested to learn more of your project, and the code you use to process the RS485.

Regards
Greg

10

Hi @greghall-au
For my project I have a RS485 sensor connected through a max3485A to my ESP32 board. I am using #include <ModbusMaster.h> to handle the register commands between my ESP32 and the RS485 sensor.
For the lora tbeam side of it. I have the ESP32 and my lora wired together through serial. You have to make sure to have your lora board configured to accept serial and have its TX RX set up to the ones you wire.

For my project I have the sensor reading data. Then sends that data to the ESP32 which can print it onto PC serial monitor. I take those values and create a ā€œMessageā€ of what I want to send serially to the lora to have it send that message to the mesh channel that all my lora boards are connected to.

ESP32 Pinout:

#include <ModbusMaster.h>
#include <HardwareSerial.h>

#define MAX_DE_RE 4
#define SENSOR_RX_PIN 26 
#define SENSOR_TX_PIN 22 
#define LORA_RX_PIN 16
#define LORA_TX_PIN 17

Useful website I used to find the modbus functions to readholdingregs()

1 Like