Sending LoRa packet takes more than 1.5 sec.

[Maciej]

Hi guys,

I'm playing with STM32WL (the Nucleo-STM32WL55JC1 to be precise). Also I'm using the SX1303 LoRa gateway (it's a RPi Hat from Waveshare).

Node is next to the gateway.

When it comes to send of the data, it takes quite long from passing the send command to receive the IRQ from radio:

58s735:MW DEBUG: SEND REQUEST
60s381:MW IRQ radio process...

The ADR is enabled, but anyway I've tried to play with DF, setting it to 5 and turning the ADR but without success.

I plan to use this stuff for light the bulbs and drive the blinders and the 1.5 second for the transmission is a way to long.

Is there any way to speed things up? Has anybody the similar issue? What's even worse - if we are waiting a 1.5 second for the IRQ it may cause a lost of loot of energy in case of battery powered devices.

[Tesla DeLorean]

>>Is there any way to speed things up?

Make the message smaller?

Use a higher bandwidth setting?

Use a lower spreading factor?

[AScha.3 · Accepted solution]

btw

1.5 sec -> How many bytes you transfer ? message + header + preamble + crc ?

check minimum needed time for your setting :

https://www.semtech.com/design-support/lora-calculator

What its telling ?

[Maciej]

Thanks guys for your nice insights.

As supplementation - I'm trying the example project provided by ST, the `LoRaWAN_End_Node_FreeRTOS` The size of data passed to the radio (radio.c:):

static radio_status_t RadioSend( uint8_t *buffer, uint8_t size )

is 28 bytes.

In logs from the concentratord i can see:

2024-10-05T08:08:00.589Z INFO [chirpstack_concentratord_sx1302::handler::uplink] Frame received, uplink_id: 2151208277, count_us: 315216910, freq: 868300000, bw: 125000, mod: LoRa, dr: SF12, ftime_received: false, ftime_ns: 0

So based on this info, i can see that besides I disable ADR in the code:

#define LORAWAN_ADR_STATE                           LORAMAC_HANDLER_ADR_OFF
#define LORAWAN_DEFAULT_DATA_RATE                   DR_5

It's still a SF12 (based on DR_5 should be SF7).

Based on semtech calculator it looks like the air time may be that long with this settings.

So probably the problem is somewhere in gateway configuration or in STM32WL example. Looking through the code I can't see obvious problems.

The configuration of concentratord is as follows:

 [gateway.concentrator]

    # Multi spreading-factor channels (LoRa).
    multi_sf_channels=[
      868100000,
      868300000,
      868500000,
      867100000,
      867300000,
      867500000,
      867700000,
      867900000,
    ]

    # LoRa std channel (single spreading-factor).
    [gateway.concentrator.lora_std]
      frequency=868300000
      bandwidth=250000
      spreading_factor=7

Maybe someone had a similar issue?

[AScha.3]

>Based on semtech calculator it looks like the air time may be that long with this settings.

(I expected something like this...)

But whats the "issue" then ?  LoRa is not "fast" , if you want communication at lowest signal levels.

Check with the calculator, what speed you can get (at low spreading, only 4 Byte payload etc.),

so you see, whats possible at all.

[Maciej]

Thanks, AScha.3. The issue is that the spreading factor (SF) doesn't change to 7, even though I set the configuration to DR_5. This seems to be a problem with the configuration or code rather than the hardware or a LoRa-related issue.

Regarding LoRa transmission speed, I am aware of the technology's limitations—I just need to send a few bytes to signal, for example, that the shutters should start moving. With SF7, the transmission time should be under 100ms, which is ideal for this scenario.

I initially thought the problem might be related to communication between the M4 and M0 cores, with packets queuing in the M0 core and causing a delay before transmission. I was "almost sure" that disabling ADR and fixing DR_5 would set SF to 7, but it doesn't seem to work as expected because on the concentrator I still see SF12.

[Maciej]

Okay, checked and verified!

I’ve overridden the configuration by setting the SF to 7, and now the transmission takes only about 60-70ms -absolutely fantastic!

Turns out the example program was setting the SF to 12, so the issue was somewhere between the keyboard and the chair. :grinning_face_with_sweat:

Thanks so much for the help, for pointing me in the right direction, and for the link to the Semtech calculator - I had no idea about that one!