LoRaWAN uplink latency

a bit of background on this would be that im running a project with LoRaWAN and chirpstack and i was asked a question and im struggling with giving a direct answer on this

i did a small test with an uplink from an end device to gateway, from the second the uplink was sent from the end device to the gateway i timed 3 seconds, this was regardless if the distance was 1km or 1m between them and im wondering if someone can explain whats going on and if its possible to lower this latency
im running the end-nodes with gnicerf sx1276 modules and esp32 boards and for the gateway i use rpi3B+ with RAK5146
for the code side im running gatewayOS on the rpi

i want to lower the latency to 1 sec, is that even possible?
maybe the issue is that im looking at the webapp ui to see when the packets arrive?

another question i have is how do i setup TLS certificates with gatewayOS? i really couldnt find the place and even when connecting to the gateway via SSH i couldnt find the directory where to put it

the final question i have is with the gateway
i tried running 7 simultaneous end nodes that transmit in the same time
im using SX1302 which has 8 channels but when running the system in various formats i see only 2 frequencies appear
im trying to understand how the frequency division works as in is each frequency associated with a different SF? what happens when 2 devices have same SF? are the uplinks received in different frequencies?

What is the frequency inverval you want to send? Every 1 second?
If you want to send every 1 second then LoRaWAN may not be suitable for you.
Why / what is the use case you want to send an uplink every second?

Sometimes, your esp32 needs to wait for sensor to reply to send the uplink.

Are you using ABP for your nodes? If yes, then try to use OTAA.

The SF is usually used / set for different ranges.
If your node is far, the node will be likely to use smaller Data rate (DR) e.g high SF 12.

Uplink can be in 8 frequencies and 6 SF(7-12).

my main idea was having several types of end nodes, one sends data to the gateway while other receives it from the gateway so my idea was to use class A for node that needs uplinks and class B/C for nodes that need downlinks but i cant seem to get class b to work
as for the 3 second delay i figured it out that its only from the webUI, the uplink arrives earlier according to MQTT event so that explains it

im running an i2c sensor, all i do is read data from a register so the issue isnt at that part

OTAA, thank you for reminding me

yea i get that but i was wondering if my SX1302 has 8 channels, how are the channels defined? is it possible for an event like that to occur? why dont it have 8 antennas? is this something similar to OFDM?
like is there a Fmux for different frequency channels and another mux for SF? so each SF gets a freq at any time so that an event of 2 devices with different SF can transmit over the same frequency?
thats basically my main question

It is defined in your LoRaWAN server and gateways according to the LoRaWAN specification.

I think it is not neccessary.
WiFi also has many channels but the WiFi router may have 1 antenna too.

As you may want to understand the radio aspect.
You may want to watch/read about “chirp”.

And

Yes, two devices can send in the same frequencies but with different SFs at the same time.
There will be NO inteference in this case.

As long as there is a single difference in [frequency, bandwidth (125kHz, 250kHz…) or SF (7-12)], there will be no signal inteference.

For LoRaWAN, they define DR0-5 based on bandwidth and SF.

Hope it helps.

Why you want lower latency? I think it’s out SPEC. LoRaWAN is not WiFi, or Bluetooth for bi-directional communication.

bi-directional communication is only advisable for important commands, not for application level communicatioon.

1 Like

Radio signals travel at approximately the speed of light, so the LoRaWAN uplink latency is zero to the human perception. But then there’s a whole bunch of processing to check the CRC, find the DevAddr, find the corresponding list of devices, try all possible decryptions to find out which one is correct given the MIC. And then there’s some processing for it to show up on your console.
I am not a Chirpstack power-user so can’t really tell the usual end-to-end latency, but the uplink processing usually takes up to a second, and then you should add 1-2 seconds for it to show up on your screen.
If you were to look at the gateway logs, you should see near-instantaneous reception, with the only real delay being the gateway’s Serial output being buffered. But the gateway just dumps the raw info and doesn’t know to which device it belongs or what the decrypted payload would be.

1 Like

thanks, i got the result i wanted by listening directly to the MQTT forwarder

i use chirpstack OS and when i set the parameters i usually choose 1.0.3

1 Like