LoRa Data rates

Using Arduino Project Guidance
1

Has anyone had any luck in coding adaptive data rates?

I tried changing the SF, which I got working but found out the Rx must be on the same SF to receive the packet.
Is there another way to have changing data rates?

I’m building a high altitude balloon and I don’t really want or need SF12 for the start of the flight as it’ll be in close range, but once it’s potentially hundreds of km away it would be useful.

I’m using rfm9x module on 433MHz with the Radiohead library.

2

Do you actually have a problem using SF12 at close range?

3

Not a problem as such, but it’s taking 4.5s to send the packet, meaning I can only send one every 45s to stay within 10% duty cycle. I’d much rather send a quick packet, 200mS every 10s until I need SF12 for the range.

I’ve got the transmitter to count how many replies it gets or doesn’t get from the ground station, then it changes SF. Problem is once it changes, the receiver doesn’t know if it’s out of range or just on a different SF.

4

The solution is to negotiate the changeover, so that both ends remain compatible.

On the other hand, balloons don't move very quickly, and a once-a-minute update seems reasonable. Or choose a compromise SF. Lots of useful info on this site!

5

Nope.

For LoRa comms to work you have to match;

Frequency, Spreading factor and bandwidth.

For a high altitude balloon; have it send out every few minutes a very short 'request' packet at the long range settings. It then waits 5 seconds or so for a reply which contains the LoRa settings it should use in future.

The ground based receiver just needs to be set up to go into 'request' listen and send the appropriate LoRa settings (in long range mode) when it receives the 'request'.

Also not difficult to arrange for the balloon to TX mostly at short range fast settings and then once a minute TX at long range.

6

I wonder how much data you need to transfer.
You should minimize your payload.
When you post the structure of your payload, you might get hints what and how could be reduced.

P.S.: an airtime calculator:

7

Thats an airtime calculator for LoRaWAN and there is a circa 13 byte header for LoRaWAN packets. So a 1 byte payload is actually sent as circa 14 bytes.

Semtech provide a 'LoRa Modem Calculator Tool' that will give you the airtime for a LoRa packet.

1 Like
8 
struct payload{
  uint32_t Secs_since_launch;
  int32_t Lat;
  int32_t Long;
  uint16_t GPS_Alt;
  uint16_t GPS_Speed;
  int16_t VS;   
  int16_t Temp_in;
  int16_t Temp_out;
  uint16_t V_batt;     
  uint16_t Max_Alt;

I guess the only things really 'needed' are Lat, Long and Alt, but the others are interesting and if I lose the payload I can recreate a good portion of the flight from the ground station.