SpreadingFactor

[thl-mot]

Hi,
I testet this library regarding focused on SF. In my first test I discovered, that the library increases the SF when using ACK. Even if the Gateway is just as far as 1m away the SF is increased to SF12 and not lowered afterwards. When not using ACK this does not happen. Did I miss some LoRaWAN basics?
Another question, is it possible to watch the current SF at the device, how LMIC 2.3.2 is trying to send its data to the Gateway.

PS: is there a dedicated discussion/forum somewhere about LMIC or is it valid to ask here?

Thomas

[terrillmoore]

Support questions are ok to ask here for now. I have plans for a discourse site, but...

If you're using 2.3.2, there are numerous issues in this area. You might try updating to head and repeating your experiments. The LMIC by default enable LinkADR, and the networks now days use that.

If you look at the example compliance sketch, you'll see how I grab data about what's going on in an "event log". At EV_TXSTART, the variable LMIC.rps is the "ground truth" about what the LMIC is going to do for transmit. You can then decode and display as shown in the sketch.

Very important: don't print anything in the event handler. The LMIC (any version) is exquisitely sensitive to timing in that function, and strange problems will arise. It is best not to print at all while sending a message (or processing the RX downlinks). Because of potential MAC traffic from the network, you can't really rely on elapsed time; you need to do something like what the compliance sketch does to figure out if it's safe to print.

[thl-mot]

Did I get it right, when looking at compliance-otaa-halconfig.ino event-handling changed. there is no longer an onEvent().
I switched to head. Now the same source does no longer work. Logging says (from onEvent) onknown event with id 20

[terrillmoore]

onEvent is no longer required. If supplied, it will be used (unless you set a very obscure flag at compile time). The compliance sketch doesn't use onEvent both in order to test the new way, and to show how the registration is done. This is somewhat documented in README.md.

Unknown event with id 20 is because of the new EV_JOIN_TXCOMPLETE which means that join has finished a cycle. There was formerly no central list of event names, so each of the onEvent instances needs to be updated. It seems I missed one. Which sketch are you using?

Also please let me know which region you're using, which platform, etc.

[thl-mot]

I am in region EU

[thl-mot]

How do i migrate to the new pin mapping from the old way:
// Pin mapping const lmic_pinmap lmic_pins = { .nss = 18, .rxtx = LMIC_UNUSED_PIN, .rst = 14, .dio = { 26, 33, 32 } };

[cyberman54]

@thl-mot i migrated my app from original IBM LMIC to MCCI LMIC, HEAD version. Look here for a working example.

[cyberman54]

@thl-mot

class MyHalConfig_t : public Arduino_LMIC::HalConfiguration_t {

public:
  MyHalConfig_t(){};
  virtual void begin(void) override {
    SPI.begin(LORA_SCK, LORA_MISO, LORA_MOSI, LORA_CS);
  }
};

MyHalConfig_t myHalConfig{};

// LMIC pin mapping

const lmic_pinmap lmic_pins = {
    .nss = LORA_CS,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = LORA_RST == NOT_A_PIN ? LMIC_UNUSED_PIN : LORA_RST,
    .dio = {LORA_IRQ, LORA_IO1,
            LORA_IO2 == NOT_A_PIN ? LMIC_UNUSED_PIN : LORA_IO2},
    // optional: set polarity of rxtx pin.
    .rxtx_rx_active = 0,
    // optional: set RSSI cal for listen-before-talk
    // this value is in dB, and is added to RSSI
    // measured prior to decision.
    // Must include noise guardband! Ignored in US,
    // EU, IN, other markets where LBT is not required.
    .rssi_cal = 0,
    // optional: override LMIC_SPI_FREQ if non-zero
    .spi_freq = 0,
    .pConfig = &myHalConfig};

[thl-mot]

Ok fine. I got my device running as you might have seen in my other thread.
Just another question concerning the SF. Am I right, that the SF is only adjusted during runtime when using ACK? When not using ACK the SF will be kept after the Join. Or is there any mechanismthat adjusts the SF after a join?

[cyberman54]

SF is controlled remotely by the network, if you enable ADR. Regardless if you send payload ack'd or non-ack'd.

It depends on the network provider's server side settings what actually happenes. With TTNv2 i see ADR requests often shortly after join.

[terrillmoore]

this looks like a discussion thread rather than a bug thread. No activity for three months, so I'll close for now.