Adaptive modem preset for higher speed comms

Development
1

I couldn’t find any related topics, but I believe an adaptive mesh would be highly beneficial, especially as the community grows. So here we are! :grin:

I understand that for communication, all Lora modems need to use the same Lora settings (Bandwidth, Spread factor, Coding rate). However, I also think the ability to change these settings automatically based on distance could not only speed things up (possibly opening up new possibilities, more on this later) but also decrease congestion.
I hope that covers the “why.”

Now, onto the challenging part - the how.

First Approach:
My knowledge about Lora is limited, so there might be some mistakes in this part. One solution I considered is hopping between presets using an algorithm, something like:

  • Check if all the known nodes are accessible; if so, use a higher speed preset.
  • Periodically set to a lower speed preset and send a discovery ping.
    (Any new node would listen for that preset and send an ACK message back, so they are aware of each other’s presence.)
  • If the newly discovered node is farther away or has obstacles on the way (requiring a lower speed), every node on the mesh would drop to that preset and continue communicating there.

A Somewhat Different Approach:
A Lora modem can only be set to listen to a specific frequency range. I get that because when using my SDR, I can only see a set frequency range too. But if I understand correctly, Lora modems also listen for a specific list of settings (Bw, Sf, Cr). This part is a bit unclear to me.

With the SDR, when listening to a frequency range, if I receive any transmissions on that range that are not colliding and I can decode, it doesn’t matter if the encoding parameters are the same. Knowing the used parameters is all I need to decode. I assume for a Lora module, detecting the used encoding parameters is the challenging part.

Now, I’m wondering: Can Lora modems detect what preset is used? If not, is this a software problem or a hardware one? I think it must be a software problem, considering that different frequency band usage on different modems is a hardware issue because of frequency-specific complementary hardware used alongside the main chip. However, detecting the preset using the preamble should be possible with software.

**Some Notes:**
SDR(Software-Defined Radio), ACK(acknowledge), 
New-Possibilities(being able to send short voice messages and other higher data rate-needing stuff...)

Damn, that took a long time to write. Hope you guys like it! :blush:

1 Like
2

For the first approach: Nice idea, but it’s very hard to control this simultaneously to all nodes in the mesh. Maybe node A can reach node B using a high speed preset, but not C. How do you communicate to everyone to use the lower speed preset? Each node has to be time-synchronized to receive the control messages at the right time on the lower speed preset, but time synchronization is very hard in a low-bandwidth mesh.

Also, if using a higher speed preset you need to go over a hop to reach a node, while with a lower speed preset you could reach one directly, it might even be slower.

For the second approach: unfortunately it’s a hardware issue. The LoRa chip needs to know the SF, otherwise it cannot even detect the preamble. There are LoRaWAN chips with 8 channels that work simultaneously to receive packets with different SFs, but those are not supported by the radio library Meshtastic uses.

2 Likes
3

Yep its hard but would be nice if we make it work.
As this is a new idea there are some very important pieces missing from a full implementation.

Here is what was on my mind:
Every node keeps track of what preset the other nodes it communicates with are on.
Lets say 3 presets (short_fast[1], long_fast[5], long_slow[7]) are set to be the main ones
and an asynchronous system is used.
Its like using a hand held and checking in on a friend on another channel and hopping back to your main channel to let the others know what channel you are going to use)
Hopping back and forth would bring a lot of delay to the system so this kind of active preset changing would prob be activated when each node is reachable with a high RSSI for an hour or two (the numbers are arbitrary as you can guess :slight_smile: )
So that they don’t constantly change presets every few mins(diminishing any gain made by the faster preset)

An example:

Every node starts this way:

  1. All radios start on [7] long_slow

  2. 10 minutes of discovery (send discovery messages every 30 seconds)
    (can be skipped by the user anytime, jumps to 3)

  3. If all known nodes have a above the threshold RSSI send a start message
    If no node is found stay on [7] to continue discovery

  4. wait for ack from all known nodes

  5. If everything is well, set preset to [5] long_fast

  6. Send a test message

  7. wait for ack from known nodes

If a start message is received:

  1. Check RSSI
  2. Check if discovery time is complete
  3. Send ack
  4. Set preset to one speed higher
  5. If test message received: send ack

For nodes that have auto_discovery set to on:
repeat every 30 minutes:

  1. set modem preset to [7] long_slow

  2. wait 1 min to listen for a discovery message

  3. If discovery message is heard tell the newly discovered device to go to preset used by the mesh

  4. return to current_mesh _preset

  5. wait 1 min to listen for a hello message by the new node (the new node sends hello messagesfor that duration)

  6. If hello message is not received: Set preset to one speed lover
    If hello message is received: send introduction message so that every other node knows about the new node

  7. wait 1 min to listen for a hello message by the new node

  8. If hello message is not received and If preset is not [7]: Set preset to one speed lover
    If hello message is not received and If preset is [7]: give up and go back to normal operation
    If hello message is received: skip to step 11

  9. Wait 1 min to listen for a hello message by the new node

  10. If hello message is not received: give up and go back to normal operation

  11. Go back to current_mesh_preset

  12. Announce preset drop to the one hello message is heard

Ok this isnt complete but Im too tired to continue and I need to study for my upcoming finals so I’ll check this for errors later. (I’m guessing there are a lot of errors)

1 Like
4

While I don’t want to discourage you from implementing something like this, I think it’s way more complicated than how you envision it. Besides, every step you propose adds some overhead and quite some time where no normal communication can take place because you need to send a lot of control messages. The difference between e.g. LongSlow and LongFast is not so big and you always need to use the lowest rate such that all nodes can be reached, so it’s likely you cannot gain much.

You must realize that there is no central controller in the mesh. So how do the nodes now when the 10 minutes of discovery starts? They do not start up at the same time and if they don’t have a GPS or RTC, there is no reliable time source.

What happens to nodes that do not do auto discovery and use a high speed preset? They won’t notice when others change from preset.

If you do the auto discovery every 30 minutes, it means that in some cases it might take up to 30 minutes before a node that just moved out of range can communicate again.

1 Like
5

I’m loving the passion and enthusiasm. Definitely something I’m sure always welcomed by everyone in the community. However as stated by others, I think the added complexity and overhead is just too much. There’s good reason in the KISS design principle.
Good luck with your finals! Afterwards you’ll maybe have time to fork the project? :wink:

1 Like
6

Thanks :slight_smile:
Tbo I’m a bit over excited. This project is pretty much what I dreamed of in middle school but back then I knew I could never create such a project. Seeing it already built with such professionalism is incredible. (First saw meshtastic in Andreas Spiess’ s original vid (3y ago) but back then I taught the project would die like most ambitious open-source projects :face_with_diagonal_mouth:)

Oh and as a mechatronics engineer that has worked with a ton of projects over the years, I know when you’re new to something you dream big and don’t see the huge potential problems. So as @GUVWAF stated this idea is prob too much problems for too little gains but regardless I’ll continue tinkering around. I’ve already started reading the source but honestly I’m no where near forking and changing stuff. (at this stage I would just fork thing up :))

Right now my hope is that someone to be inspired after seeing this topic and coming up with a better solution for an adaptive system.
Cheers…

1 Like