proveskit / circuitpy_flight_software

Flight software for the PROVES Kit.
MIT License
3 stars 8 forks source link

Spreading Factor Hopping #4

Open Mikefly123 opened 4 months ago

Mikefly123 commented 4 months ago

One of the key features of the LoRa modulation is the fact that there are multiple Spreading Factors (SFs) that are "orthogonal" to each other. What this means is that multiple LoRa transmitters can be operating on the same frequency, but as long as the are on separate spreading factors there should be little to no cross talk between them.

Additionally, higher spreading factors are known to have better link budgets than lower ones. This means that when the link margin between space and ground is questionable, it can be advantageous to use a higher spreading factor for a better link margin (at the cost of lower data rate). Once the link margin improves though it can be better to switch to a lower spreading factor for faster data transfer.

We have for a while wanted to develop some kind of system for hopping between different spreading factors and landing on the best one.

Mikefly123 commented 4 months ago

The Link Budget Benefits of Using Higher Spreading Factors

Take for example, this table from the RFM98 data sheet that shows how the receiver sensitivity increases (more negative is better in this context since it is a representation of how faint of a signal can be decoded) as your spreading factor also increases. When we are uncertain as to whether a link can be successfully made we want to try and hedge our bets as much as possible but using the highest possible spreading factor!

Screenshot 2024-07-02 at 11 44 47 PM

The Data Rate Drawbacks of Higher Spreading Factors

We can see from this reference that data rates really tank as we go to higher spreading factors. This is mainly due to the fact that more time on air has to be spent at the higher spreading factors which leads to less bits that can be moved each second.

Screenshot 2024-07-02 at 11 56 13 PM

So How Should We Implement This?

We want a few things:

  1. The ability to guarantee some packets will make it through sometimes through the use of higher spreading factors. These packets should carry the bare minimum data to provide proof of life for the satellites.
  2. A way to use lower spreading factors to more quickly move larger sets of data, such as a comprehensive telemetry packet, or dumping a queued up data file.
  3. If a spreading factor collision is detected (i.e. two nodes are trying to communicate at the same time on the same spreading factor) there is some way for one of the nodes to "hop" away to a different spreading factor and for its destination to follow it there to continue the data transfer.

I think the best way to try and make this happen is to create a LoRa helper class that is able to ingest data from functions.py or field.py (the radio helper class right now) and return values of cubesat.spreading_factor as needed.

Possibly Helpful Documents