I finally fixed my HackRF One and got to checking out what Meshtastic LoRa traffic really looks like, especially focusing on a network where ~10 nodes are within range of each other. I want to make the case for increased visibility of channel utilization to users so they can make better informed decisions to send a message or understand why they are not receiving ack/responses. Maybe a percentage isn’t the best to show to users; without more thought I would have expected 50% to have plenty of overhead left when in reality you are almost certain to run into collisions and issues at that level.
I have found that although with default 1.3 settings the channel utilization remains around 25%, messages are still handled better than in similar setups with 1.2.
What really surprised me was getting a sense for how much airtime this really equated to visually. The following examples from my SDR highlight how congested a channel can get with just the mesh overhead and 10 nodes. While this may be a large network for many users here, I believe this is a very realistic situation when more local community nodes arise.
The first is a FFT snapshot of the default meshtastic channel with these 10 nodes in a stable mesh. This results in about 25% channel utilization and you can see how there are only a few brief openings where critical channel packets can be sent, i.e. messages.
Here is a snapshot of 10 minutes of traffic with no messages sent. This is just the 10 nodes mesh overhead. You can begin to appreciate how important the message compression is with just how congested the network can quickly become when sending multiple messages. I also appreciate now how 25% channel utilization is actually quite busy and brings budgeting to the forefront of my mind as a user.
I might propose another abstracted value, maybe green/yellow/red, or even just 1-50% scaled to 1-100% channel utilization as a means to better inform users who are coming from smartphones and expecting certain performance.
Any ideas and discussion on how to better inform users of the network are appreciated.
This is great! I was literally just messing with my SDR to try and figure out how to see meshtastic radio traffic. I’ve got an RTL-SDR and use SDRSharp on my laptop. I have a LoRa antenna connected to the RTL-SDR. I’m in the US, so I’ve got the frequency set to 915mhz but I don’t see any noticeable traffic when powering on the nodes and sending test messages. Any other settings that I need to configure to see traffic?
I like the idea about a colour coded green/yellow/red dot, to show the channel utilisation. Perhaps using orange for the highest utilisation, as red often means “not working” or such.
Yeah, this can be a consistent ux feature next to the bluetooth connected node icon.
Not sure how much granularity would make the most sense. A few colors and maybe a ‘signal bar’ type indicator would be really useful as a user.
Part of me is thinking this could be represented on the OLED too as a ‘signal bar’ with only a side column of pixels. I miss not being able to see a realtime channel utilization from the device screen whenever messages or new locations come in. The more visibility the better IMO.
Thank you @kalestew for your observations, and sharp pictures!
How about gathering and listing all information about airtime usage, metrics and settings to one place (here/GitHub site?). Furthermore, we could update/build a airtime calculator on a Excel sheet for example.
Results could then be tested in simulations, to further optimize the usage of our valuable airtime.
