Range Test Across Multiple Nodes? Why not?

Development
1

I understand why the range test packets would not route, as that makes perfect sense for testing the range between any two nodes, and only those two nodes.

However, I’m curious if there’s a reason why that enabling multi-hop (within reason) range testing isn’t possible in the current iteration of the software.

I know Range Test pings can be “expensive” on channel airtime, but I’m wondering if there’s any other reason not to allow routable range-testing. As I understand it presently, unless a node is configured to participate in range tests, it ignores those packets.

This wouldn’t be a change to that, rather, just an ability to set range tests to obey normal hop-count rules, while still only being processed by those nodes with the range test module enabled.

The range test module is a really useful feature, but I’d love to be able to use it to create coverage maps across multiple nodes.

Thanks for any insight, best to all,
Pol

1 Like
2

My gut feeling is that it wouldnt be that useful, beucase still wouldnt be able to tell what route the packet took, eg if there are multiple routes it could of taken, can’t tell which any partucular packet took.

But also there are plenty of other ways of sending regular (routable) packets if you want, eg telemetry or position packets.

Part of the ‘power’ of the range test module, its to easily send specifically non-routable packets, without having to change your ‘normal’ hop limit setting.

you still get non range-test packets, in rangetest.csv, so can still inspect that to see reception

2 Likes
3

Thanks, @barryhunter I hadn’t been visualizing it that way, but it makes sense. If I had a solid map of A ↔ B, and wanted to know if adding C to the “far end” of B would work out…I’m really not needing to test A ↔ C.

If I already know the performance characteristics of A ↔ B, I really only need measure that of B ↔ C to have a sense of how that impacts the overall mesh.

I hadn’t thought of using position and/or telemetry packets as a way of creating those data points in the rangetest.csv

Thanks! You’ve helped clarify and given me more to ponder!

Have a great day!
Pol

2 Likes
4

I think a use case for hoppable range test is the ability to test the coverage of a mesh of nodes. Right now the hop limit is 0 for “seq” messages. If we could have a setting to respect the hop limit for those messages too.

5

As noted above can use Telemetry or Position modules to send regular routable packets.

There is another thread, specifically talking about ‘test the coverage of the mesh’ Have we Stress-Tested the LoRa Mesh?

… The big thing is going to be coming up with software that can analyse data from multiple nodes, to actually get some metrics. Either gathering multiple rangetest.csv, or MQTT messages.

1 Like
6

Was a disaster, got turned off because it got horribly misused

2 Likes
7

Interesting. By ‘misused’ do you mean would get left enabled long term, and tend to overwhelm or saturate local meshes (and/or MQTT topics)?

8

Yes has taken a year to stop, not come back lol