How to send data from gateway to LoRa node (downlink) using ChirpStack?

ChirpStack Gateway OS
1

Hello,

I am using an Raspberry Pi based WM1302 Lorawan gateway connected to ChirpStack and a Seeed LoRa-E5 Mini as the LoRaWAN end device (Class A).

I am able to send uplink data from the E5 Mini to the gateway and see it in ChirpStack, so the uplink path is working fine.

Now I want to send data from the gateway to the LoRa node (downlink).
I have a few questions:

Sending data

    What is the correct procedure to send a downlink from ChirpStack to my device?

    Should I use the ChirpStack Web UI, MQTT API, or HTTP API for sending?

    What format should the payload be in (HEX, Base64)?

Receiving on the node

    My LoRa-E5 Mini is in LoRaWAN Class A mode. How will it receive the downlink?

    Do I need to trigger an uplink first for it to receive?

    What will the received data look like in the UART output of the LoRa-E5 Mini?

Real-time reception

    If I need the node to receive data immediately, should I switch to Class C?

    What are the commands/settings needed on the LoRa-E5 Mini for Class C?

Basically, I want to fully understand the gateway → server → node downlink path in ChirpStack and how to test it end-to-end with my hardware.

Any detailed step-by-step guide or example commands would be greatly appreciated.

Thanks in advance!
Sandeep S

2

The webUI is the easiest for manually sending downlinks, if you need automation I would recommend gRPC using the enqueueDownlink command of the device service, alternatively MQTT works as well but it can only trigger downlinks whereas you can control all of Chirpstack through gRPC so if you need other automation besides downlinks it would make sense to have them all be gRPC. I would not recommend the RUST HTTP api as it is deprecated in V4.

Through the UI you determine whether it should be base64 or hex.
Through MQTT it takes base64
Through gRPC it takes an array of bytes: Protocol documentation - ChirpStack open-source LoRaWAN® Network Server documentation

As per LoRaWAN standards - if a downlink is queued to a class A device, the network server must wait until the device uplinks. Whereas the device will open it’s receive window shortly after an uplink and the network server will transmit in that period. So yes, it must trigger an uplink first.

Dunno :man_shrugging:

Yes, only class C devices are consistently listening for downlinks.

Again dunno :man_shrugging:

The downlink path goes:

Downlink triggered through integration or UI → Chirpstack → MQTT broker (topic <region_prefix>/gateway/<gateway_eui>/command/down) → gateway bridge → gateway udp or basicstation forwarder → gateway concentrator → device.

1 Like
3

Your questions reveal that you didn’t read about the LoRaWAN network. So I suppose you didn’t realize that a class C device consumes huge amount of energy compared to a class A device.

What do you want to achieve? For what reason you want to send a downlink?

1 Like
4

I understand the energy implications — Class C devices do keep their RX window open almost continuously, which is why they require more power than Class A. In my case, the nodes have a constant power supply, so battery life is not a concern.

My application requires continuous reception capability because the nodes need to receive near real-time control or configuration data from the gateway. This means I need downlink capability without having to wait for an uplink window, so Class C operation is a better fit.

5

@sandeep_sivadas

This link may answer your question
link
I hope your mqtt broker runs in raspberrypi itself.If so you try publishing MQTT downlink from raspberrypi by the below command

mosquitto_pub -h <mosquito ip> -t application/<application_id>/device/<DevEUI>/command/down -m '{"devEui": " <DevEUI >", "confirmed": true, "fPort": 1, "devaddr": "<Devaddr>", "data": "R09PRE1PUk5JTkc=", "port":6}' -q 1

Note: Make sure to add the parameters like DevEUI,DevAddr,Fport of the node where you want to send the data.

Meanwhile
in case of class A device,send an uplink message so to open the Rx window to see data in you node something like below

+MSG: PORT: 1; RX: "474F4F444D4F524E494E47"
+MSG: RXWIN0, RSSI -59, SNR 7.0
+MSG: Done

in case of class C, i think you have to send one uplink(as a trigger) thereafter you will keep receiving the downlink

For automation you can create a python code sending a downlink from gateway to the node and run the same in your raspberrypi

I hope this may help you you

1 Like
6

One more thing you should consider. Most gateways have 8 channels for uplinks but only 1 channel for downlinks, so you can bottleneck the downlinks much faster then uplinks. Typical LoRaWAN best practices is to downlink as infrequently as possible, but obviously there are use cases that require it.

1 Like
7

Hi @Liam_Philipp
is there a payload length limit for the data sending from gateway to lora node

8

Yes, but it depends on your region and datarate. You should be able to find the info in the LoRaWAN spec, but theres probably more digestible resources out there too.

9

Thankyou @Liam_Philipp

My region is IN865 and RXWIN2 data rate is DR2.Can we change it?.i think class c rxwindow 2 has fixed data rate as DR2.