General Signal Problems
- Height is Might. The higher up your node, the better it can see others.
- Don’t overthink buying a higher power device. 1w / 2w nodes can be illegal in some areas (europe), or straight up harm the mesh with nodes that everyone can hear, but are in a bad position and cannot hear anyone else.
- Cable Length is important. Don’t use cheap coax to run from your node to your antenna. the losses on the 915mhz frequency is insane.
- With a 10m cable run of LMR-200, you’re losing 55% of your broadcast power.
- LMR-240 - 45%
- LMR-400 - 27%
- LMR-600 - 18% (I’d say this is the bare minimum you should use, and only for short <5m runs)
- LMR-900 - 13%
What roles to use?
NO CIRCUMSTANCES to use Repeater, it’s essentially a router that’s hidden from the node list, with some additional quirks that make it useful for super long range mountaintop relays, (potentially a melbourne to bendigo relay path?)
NEVER use Router (unless you’re on a mountaintop / large radio tower)
DO USE:
- Client: Rooftop nodes with good connections, Moving nodes (cars, people, whatever), pick this if you don’t know.
- Client_Mute: Nodes that don’t add any new relay points to the mesh. Indoor nodes and nodes that always have good connections to other nodes. These do not extend the mesh in any way.
- Router_Late: This is less harmful to the mesh, but not perfect. Use it only for rooftops and towers that cover shadowed areas (Rooftops where you cannot read any nodes due to terrain/shadowing)
Any other nodes are more specific to the device and read the Roles Documentation
KEEP UPDATED
If you’re not on 2.6 or above already, pull that node down and update it. Fixed nodes generally should be on the ‘stable’ / ‘beta’ versions for more reliability, and less need to pull the node down and reflash. Mobile nodes: do whatever you want, either stable/beta or unstable/alpha. Both work, depending on how much you want to see new features, and are happy to report bugs.
Broadcast Settings
For nodes you own but don’t use to read messages, set as “Infrastructure Node”. This disables messaging on the device, acting only as a relay and monitoring.
Broadcast Seconds
Node Info
For fixed 24/7 nodes, set to 24 hours (86400)
For Mobile nodes, leave default, or up it a few hours depending on connection quality.
Position
For fixed 24/7 nodes, set to 24 hours or higher. For mobile nodes, up it to 12 hours, but leave smart position on to send more frequent updates when moving.
Device Metrics
For most nodes, set to 1 hour. (This is just a general battery saving / mesh packet spam reduce)
Hop Count
3 - For nodes with good access to the routers and wider mesh. (City and inner suburbs) 5 - For nodes with a ‘acceptable’ access to the wider mesh. (Outer suburbs and nearby rural areas) 7 - For nodes with a poor connection to the wider mesh. (Rural areas and long distance towns)
VNA Testing
https://old.reddit.com/r/meshtastic/comments/1h53ffg/just_got_a_vna_now_what/
Bridge multiple channels
https://github.com/pdxlocations/ChannelLink-for-Meshtastic
MeshMap
MQTT without the spam
Home Assistant
https://github.com/broglep/homeassistant-meshtastic Potentially have it send sensor data over mesh to adam/cameron?
Automations
- Ping on phone / auto reply when receiving a direct message from portable node
- critical server alerts
Extreme Power Saving Settings
Okay, Please use these tips as a guide, not all nodes will use all settings. You’ll definitely want to tweak them. This is adapted from my VLKE (T-Echo) device, where I personally still want all features to work, but saving battery as much as possible.
LoRa Settings
RX Boosted Gain: This only matters if you’re using a SX126x chip. It consumes a tiny amount of power for increased RX Sensitivity. I haven’t done any tests but I’ve left it on, especially when RXing is pretty important, especially in a portable node where it’s not mounted in a perfect spot.
From the docs: we’re talking about a -118 → -115 Sensitivity.
TL;DR: Enable
Transmit Power: This isn’t too important, lower values will dramatically lower your communication range. I’m not sure the tradeoff is worth it, we have better ways to reduce the # of transmits.
TL;DR: 0 (Defaults to maximum allowed)
Device Settings
Device Role: CLIENT_MUTE is what you want. This means you don’t contribute anything to the mesh, but it means you’re never wasting power repeating packets that other nodes can handle better. If you need to have it repeat packets, leave it as CLIENT.
Node Info Broadcast Interval: 14400 (4 Hours). Not ideal for being seen by other nodes, but for a portable node, I imagine you’ll be sending packets out when you do want to be seen. It is just one packet, so if you realllly want to see more fine-grained nodeinfo (external logging or whatever), feel free to do so, but it’s not very powersaving-maxxing of you.
LED Heartbeat: LEDs are bloat.
Position Settings
This is a little more difficult to optimise, since everyone’s needs are different, and everyone’s hardware is very different.
For semi-permanent nodes (nodes in trees/roofs/homes):
- GPS Mode: If you don’t have a GPS, set to
NOT_PRESENTand set a fixed location, remember to update, otherwise, enable it. - GPS Update Interval:
2147483647. MaxInt will only update the GPS once on startup. Perfect for nodes that don’t change too much. - Broadcast Interval:
86400- 1 Day. This lets other nodes still see locations… eventually, fine for nodes that don’t change daily. - Smart Position:
off- Node’s not changing location.
For portable nodes that change location fairly regularly (Cars/EDC):
- Broadcast Interval:
3600. This isn’t very useful because you’ll be most likely leaving Smart Positioning on anyway. Note: Why does this send out a empty position packet if no GPS was fixed?? I get needing to see bad gps fixes, but it could be a warning over BLE or a once-of. or disabled if you don’t care. - Smart Position:
ON. This increases Position packets only when a large (100m) movement has happened. Much better than spamming 96 packets per day. - (Smart Position) Minimum Interval:
300. 5 Minutes seems like a relatively decent tradeoff between higher accuracy gps tracking and power saving. - (Smart Position) Minimum Distance:
100. Left at default. Timing is more important.
For tracker nodes (Dog/Balloon/Drone/HighAccuracy Car/person):
Basically leave everything default, it’s fairly accurate, any more will spam packets needlessly and waste battery for a slightly better looking track. Anything more should be covered by a dedicated gps tracker.
Power Settings
Honestly, I’ve left Power Saving mode off. Power Saving does NOT work [well] on NRF52 powered nodes; they do technically work with it, but the power savings are almost nothing considering the usablity tradeoffs.
If you’re not connecting to the node over BLE much, and have a usr button to wake the node, By all means enable it. It’s perfect for small rooftop nodes with underpowered batteries, not so much for devices that stay connected over BLE all day.