Hi dear friends, i need some help.
I have a class C device, and i need to constantly send data to it, minimum 2 sec,
I’ve check that that this is configurable on chirpstack.toml
i did this
Scheduler settings.
[network.scheduler]
# Scheduler interval.
#
# The interval in which the downlink scheduler for multicast, Class-B and
# Class-C runs.
interval="1s"
# Class-A lock duration.
#
# This defines the lock duration between receiving a Class-A uplink and
# the next scheduler-run for a device. The purpose of this lock is to
# avoid collisions between Class-A and Class-B/C downlinks.
class_a_lock_duration="5s"
# Class-C lock duration.
#
# This defines the lock duration between scheduling two Class-C downlink
# payloads for the same device. The purpose of this lock is to avoid
# overlap between scheduling Class-C downlinks and / or spreading the
# downlink capacity load on the gateway.
class_c_lock_duration="2s"<-HERE
# Multicast Class-C margin.
#
# This defines the minimum margin between scheduling multiple multicast downlinks
# (within the same multicast-group). This value must be equal or greater than the
# scheduler interval.
multicast_class_c_margin="2s"<-HERE
# Multicast Class-B margin.
#
# This defines the minimum margin between scheduling multiple multicast downlinks
# (within the same multicast-group). This value must be equal or greater than the
# scheduler interval.
multicast_class_b_margin="5s"
Without any logs (perhaps at the debug/trace level), it’ll be difficult to tell what happened for you.
But I have these comments:
How did you determine that Chirpstack takes 10s to send the data?
If you send a downlink, does this cause the device to send an uplink in response? If so, then perhaps this also triggers the Class A lock duration? I guess it will first send a downlink via RX1/RX2 before blocking for 5s, before the next Class-C styled downlink can be sent.
You’re using EU868, whereby duty cycle restrictions exist and may be enforced by the implementation. Whatever you do, you need to keep within your regulations for both the device and the LoRa gateway. Some devices have mechanisms to prevent themselves from violating the duty cycle restrictions.
Some gateways are only capable of half-duplex communications. When transmitting, no uplinks can be received.
Hi, thank you for the prompt answer, we have a endpoint with a terminal port. we can mesure the moment we put data on the qeue, until the device display that the data arrived with a timestamp and a stopwatch.
I was thinking of logs from every components. But anyway, the logs from the gateway show a few things.
13:07:04 - Class C downlink sent
13:07:08 - Uplink sent by node via 867.1MHz
13:07:09 - Downlink sent via RX1, 867.3MHz (possibly for another node)
13:07:09 - Downlink failed to be sent via RX1, 867.1MHz due to the earlier one.
13:07:09 - Chirpstack attempted another downlink via RX2, 869.525MHz. This also failed due to the overlap.
13:07:11 - The frame is finally sent.
Every gateway can only sent 1 message at any time, to a device. There are two downlinks overlapped, at these concentrator counter values (just 8ms apart):
3473616499
3473616507
Are you using multiple devices? If you have multiple devices, you need to stagger their uplinks or to even use multicast.
Your frames are all being sent at DR0, for both the LNS and the node. I hope that you normally have ADR enabled to let the devices use as high datarates as possible. Do consider configuring the LNS RX2 datarate as high as reasonable for your deployment. The default is a very conservative setting of DR0, but this can result in very long messages.
I have only one device OTAA. how i enable ADR? can you please give me the recomendations for the datarate? consider this device as it is reach up to 6km, we test it, and now the request is to make it faster, yesterday i change the firmware a bit, so it responds in 5 sec.
I am afraid I cannot assist in the detail of this. However, upon reading your requirements (quoted above), I immediately thought that I would not have chosen LoRaWAN for this (especially on EU868 duty cycle limitations).
My concern is not the speed of response; my concern is why the command is not being sent immediately. I can manage the firmware responding at any time with no problem, but why does it take too long for the command to be sent once I send it? i can eve see it in the debug terminal on my endpoint.
You can check whether ADR is enabled on the device’s side, by checking the LoRaWAN frames logger. If the “adr” bit is set to true, it is enabled on the device’s side.
The DataRate should be set according to your project’s requirements. From what I know, link budgeting should be done. For example, compute the difference between the RSSI of the received frame and the node’s sensitivity. This is the budget, which roughly determines how many obstacles the signal could possibly pass through before it becomes impossible for the node to demodulate.
The other way I know of, is trial-and-error. Just try the DRs until you find the highest DR that you can comfortably use for your project’s needs. For example, start from DR3 and move up/down.
That is the thing. You are using DR0, which is the lowest datarate. The LNS is also using DR0 for RX2/RXC (immediate) downlinks. DR0 will result in long air time, which could be even as long as a few seconds. A gateway would normally be only able to transmit one frame at a time.
The spreading factor does not affect the RSSI, from what j know. But the chip in the node is less sensitive towards transmissions st higher datarates.
