LoRaWAN: How to set spreading factor, output power, bandwidth?

[Krulknul]

Following discussion #1169, I noticed something else that confused me regarding the radio controls in RadioLib.

Summarizing that other discussion, I was able to connect my device to the things network and upload data. Right now I would really like to test the performance under different radio settings and see how often I can transmit under those settings according to law and FUP.

I have the following program:

#include <Arduino.h>
#include "utilities.h"
#include "RadioLib.h"
#include "LoRaBoards.h"
#include "SparkFun_Ublox_Arduino_Library.h"
SFE_UBLOX_GPS myGPS;

// !!!!! APP EUI
#define RADIOLIB_LORAWAN_JOIN_EUI [redacted]
// !!!!! DEV EUI
#define RADIOLIB_LORAWAN_DEV_EUI [redacted]
// !!!!! APP EUI
#define RADIOLIB_LORAWAN_APP_KEY [redacted]
// !!! APP KEY
#define RADIOLIB_LORAWAN_NWK_KEY [redacted]

uint64_t joinEUI = RADIOLIB_LORAWAN_JOIN_EUI;
uint64_t devEUI = RADIOLIB_LORAWAN_DEV_EUI;
uint8_t appKey[] = {RADIOLIB_LORAWAN_APP_KEY};
uint8_t nwkKey[] = {RADIOLIB_LORAWAN_NWK_KEY};

const uint32_t uplinkIntervalSeconds = 5UL * 60UL; // minutes x seconds

const LoRaWANBand_t Region = EU868;
const uint8_t subBand = 0; // For US915, change this to 2, otherwise leave on 0

SX1276 radio = new Module(RADIO_CS_PIN, RADIO_DIO0_PIN, RADIO_RST_PIN, RADIO_DIO1_PIN);

LoRaWANNode node(&radio, &Region, subBand);

void debug(bool isFail, const __FlashStringHelper *message, int state, bool Freeze)
{
  if (isFail)
  {
    Serial.print(message);
    Serial.print("(");
    Serial.print(state);
    Serial.println(")");
    while (Freeze)
      ;
  }
}

void encodeCoordinates(byte *buffer, long latitude, long longitude)
{
  // Store first long (4 bytes)
  buffer[0] = (latitude >> 24) & 0xFF;
  buffer[1] = (latitude >> 16) & 0xFF;
  buffer[2] = (latitude >> 8) & 0xFF;
  buffer[3] = latitude & 0xFF;

  // Store second long (4 bytes)
  buffer[4] = (longitude >> 24) & 0xFF;
  buffer[5] = (longitude >> 16) & 0xFF;
  buffer[6] = (longitude >> 8) & 0xFF;
  buffer[7] = longitude & 0xFF;
}

void setup()
{
  setupBoards();

  Serial.begin(9600);
  while (!Serial.available())
    delay(1000);

  Serial.println(F("Starting up"));

  Serial1.begin(GPS_BAUD_RATE, SERIAL_8N1, GPS_RX_PIN, GPS_TX_PIN);
  if (myGPS.begin(Serial1) == false) // Connect to the Ublox module using serial port 1
  {
    Serial.println(F("Ublox GPS could not start."));
    while (1)
      delay(1000);
  }

  int state = radio.begin();
  debug(state != RADIOLIB_ERR_NONE, F("Initialise radio failed"), state, true);

  node.setADR(false);
  if (radio.setSpreadingFactor(8) != RADIOLIB_ERR_NONE)
  {
    Serial.println(F("Error setting spreading factor"));
  }

  while (1)
  {

    Serial.println(F("joining TTN"));
    node.beginOTAA(joinEUI, devEUI, nwkKey, appKey);
    state = node.activateOTAA();
    if (state == RADIOLIB_ERR_NONE || state == RADIOLIB_LORAWAN_NEW_SESSION)
    {
      Serial.println(F("Join successful"));
      break;
    }
    debug(state != RADIOLIB_ERR_NONE, F("Join failed"), state, false);
    delay(10000);
    Serial.print("Retry ");
  }
}

void loop()
{
  // get a GPS fix
  long latitude = myGPS.getLatitude();
  long longitude = myGPS.getLongitude();
  Serial.printf("%d %d\n", latitude, longitude);

  Serial.println("Sending uplink");

  byte payload[8];
  encodeCoordinates(payload, latitude, longitude);

  // Perform an uplink
  int state = node.sendReceive(payload, sizeof(payload));
  debug((state != RADIOLIB_LORAWAN_NO_DOWNLINK) && (state != RADIOLIB_ERR_NONE), F("Error in sendReceive"), state, false);
  Serial.printf("Uplink complete, next in %d seconds\n", uplinkIntervalSeconds);
  Serial.printf("Allowed in: %d\n", node.timeUntilUplink());
  Serial.printf("Last uplink: %d\n", node.getLastToA());

  // Wait until next uplink - observing legal & TTN FUP constraints
  delay(uplinkIntervalSeconds * 1000UL); // delay needs milli-seconds
}

As you can see, I am using node.setADR(false) to free myself from ADR, and then I try to set the spreading factor to 8. However, when I observe my uplinks on the TTN dashboard, I see the following:

"settings": {
  "data_rate": {
    "lora": {
      "bandwidth": 125000,
      "spreading_factor": 10,
      "coding_rate": "4/5"
    }
  },
  "frequency": "867900000",
  "timestamp": 3218191924,
  "time": "2024-07-25T15:58:27.557965040Z"
},

The spreading factor observed by TTN seems to still be 10. This is also confirmed by the duration of my uplink as reported by RadioLib:
Last uplink: 371
371 ms of airtime; which corresponds pretty clearly to an SF of 10 as per this airtime calculator

I have also tried an SF of 7, with a high bandwidth of 250 as specified by that airtime calculator, but I get the same result in the TTN dashboard.

How do I change these settings? It doesn't seem like this is working right now, judging by the values reported by TTN and even RadioLib itself.

Moderator note: Some values changed after discussions had started.

[HeadBoffin]

Your code breaches legal power output and the TTN FUP and if it ever gets to SF12, duty cycle.

We can't assist those that deliberately break the law &/or cause unnecessary interference to the shared ISM band &/or breach FUP on the shared community resource that others rely on.

[Krulknul]

Please consider that I am aware of those facts and that this is an example piece of code, Illustrating the fact that I cannot change the parameters. I do not plan on running this code in this state. If you want, I can edit the original post to include an example that fits within legal requirements. I did not consider it to be very important to comply in this theoretical example, but I understand that it may be better to do it anyway.

I have no intention of breaking FUP or legal constraints, as mentioned in the OP (trying to experiment for the best settings for my use case within FUP and law)

[StevenCellist]

Please consider that I am aware of those facts and that this is an example piece of code

Unfortunately that won't cut it, here nor in university. You say you know how it works, but are not demonstrating your knowledge in the actual examples you provide. You can't make an exam saying "suppose we can construct a binary tree in linear time" and afterwards tell the examinator "I know how it works, it was just easier this way".

Or, if you are working on an assignment, using some odd value for easy debugging thinking "I'll change this when I hand it in" - I've heard many peers and students go "Oh balls, I handed it in with the wrong value".

Thirdly:

I can edit the original post to include an example that fits within legal requirements

This is generally not done, since it completely ruins the flow of this Discussion, making it look completely derailed to visitors learning about the same problems, putting them onto the wrong track. So please, demonstrate your knowledge by posting an improved follow-up - because we do see you are doing research.
As we say: "jong geleerd is oud gedaan": learn it now and you'll get solid answers on all most of your questions later. Cheers!

[HeadBoffin]

Please consider that I am aware of those facts and that this is an example piece of code

We only know what we see, which is the code, which doesn't speak to that knowledge. In addition you reported that the TTN LNS was reporting payloads at SF10 when you were expecting SF12 and realistically there is only one way you'd have got those.

LoRaWAN is like Shrek onions - many layers - it takes time to absorb the more subtle details, some of which you can't see until you "level up". This is totally normal and people are here to help you on your journey, subject to you using the materials provided and if you have any sense of stepping outside the circle, asking first about where the boundaries lie - so much quicker than debugging written interactions after the fact.

The typical use case for LW is a static device run off batteries that reports sensor readings every hour for several years to static gateways. To learn LW it would be best to do exactly that first, before complicating matters with finding the right balance of SF vs battery life vs range when you currently don't have your own gateway to facilitate this. If you do this you run the risk of graduating with enough knowledge in this area to be instantly employable. If you focus too much on your use case there will inevitably be gaps in your understanding that may not allow you to be obviously competent. Creating three or four devices, documenting them and putting them up on GitHub outclasses anything you can write on a CV.

I did not consider it to be very important to comply in this theoretical example

The TTN community rather does because of the problem of Copy & Paste. Code spreads and those not fully informed do not understand the consequences of implementation. No actual puppies are harmed as such, but there are demonstrable instances of inconvenience and denial of service due to simple things like changing one parameter because it appears to work better.

And with all the hard work that @StevenCellist & @jgromes have put in on RadioLib, none of us want to be "those guys that let people run riot on the airwaves" - we have a moral responsibility to not be the delivery mechanism of a jammed up ISM band.

My first response was curt & to the point - it has to be to get the message over - and as we are all volunteers, our time is precious & we are not always able to be warm & fuzzy. And I'm the old bastard / bad cop so sure, this is likely to sound like a lecture to ears more than half my age. But I only type all this because I give a damn.

I note you have edited your post, to ensure continuity I'll put a message to that effect on it so some or all of this continues to make sense.