Real-time downlink from uplink received

ChirpStack Application Server
1

Hi All,

I have a unique requirement that is time-sensitive.

What I want to do is:

  1. When an uplink packet is received at the lora app server from a device I want to generate a new download message from my application and send this to the device.

The download message contains a time that the end device will use as its internal clock due to drift.

What am seeing it the following

  1. Device sends message to LoraServer
  2. Lora server contacts my application with the devices uplink packet
  3. My application generates the message and uses the Chirpstack api [/api/devices/{device_queue_item.dev_eui}/queue] put the the message on the Q.
  4. Message does NOT get sent to the device on this received uplink, but sits there on the Q until the next upllink message is received and then gets push down to the device, where the time embedded in the message is out and messes up the operation of the end device.

Is there any way to Receive a message --> process on my app server --> and then send in real time to device within the Rx window.

Note

  • The Device is a Class A device version 1.0.2 LoraWAN.
  • Chirpstack server and my application server are installed on same hardware server.
  • Generation of the downlink message on my application completes in uSec.

Any help on how the topology of this should be would be great.
Thanks
Gary

2

https://lora-alliance.org/resource-hub/lorawanr-application-layer-clock-synchronization-specification-v100

3

Hi,

the RTC is for a co-processor that controls the lora module. Our product heatboss is a zigbee solution and are now converting over to LoraWAN and want to keep the same commands for boosting setting the clock etc.

This issue I have explained above happens for all commands i.e. when I generate the command on our application server and push it via HTTP to the Chirpstack serve it does not get sent down right there and then to the device, I have to wait until the end device wakes up and communicated in again.

@brocaar
I am still new to LoraWAN but have lots of experience developing IOT devices using 2.4Ghz. I just need some guidance if the Rx windows of the end device need to be extended or is there a way for the Chirpstack network server to only process the Q after the application server has put something on it.

Any guidance would be great
Gary

4

for immediate sending the downlink you need turn the device into class C, but this class not energy efficient for battery life. Also You can visit this resource, if youre newbe in LoRaWAN
https://lora-developers.semtech.com/resources/lorawan-academy/

5

In your chirpstack api on the confirmed array make it false not true because if the confirmed array value is true the app server will have to wait the next uplink in other to trigger the downlink so make your confirmed array to false and check for me it’s works well

image
image750×462 55.6 KB

6

Hi,

I have the confirmed property set to false.

What I need is some guidance on (and if possible) to make this like a synchronous call i.e

Network server --> app server --> my server app (put mes on Q) --> network server (get msg from Q) --> send to gateway

Thanks
Gary

7

I think you’ve collected all of the available options at this point:

  • Run the device in class C, such that it can always accept a message.
  • Modify the network server code and build the feature you need into it at that level.

I don’t think there are any out-of-the-box ways to do what you want with Class A.

1 Like
8

@brocaar

Is there any way to process the Q after we have sent a message to the app server and it puts it one on there.

Thanks

9

nope, in case of class A device, your app form and put the payload in queue. and it will send from queue after next uplink. queueing is not best way to sync RTC.
my idea is to switching endnodes between classes
switch to classC->sync->switch back to classA

1 Like
10

@eugenev
Thanks for the info, we had thought of that approach and will implement this, this incoming week to test.

I take it that we would have to:

  1. Configure the device in Chirpstack a Class C device and re-join the device?
  2. Will Chirpstack network server process the message to the device as soon as my application puts it on the Q?

Thanks
Gary

11

not only in the Chirpstack device profile, you need to switch the device itself to classC by downlink command, also.
rejoin not rquired.

while classC is enabled, it will send from queue immediately

12

@eugenev

Many thanks for your input. We will test this out and let the forum know how we get on.

Would be nice to have an option on the ChirpStack UI to allow messages to be processed after application server puts a message on the Q.