Reciveing Packets in Class C

Hi All,

I’ve been trying to send pakets from a node operating in class A to another one in class C (which suppose to be listining most of the time), I have tried the following:

  • I have set the class A node to send using the Rx2 freq, and Dr and the class C node failed to receive anything
  • I also tried to set the Rx2 parameters in the class C device to match the normal freq in the other node, but it also failed

Any ideas please on how to set a node in class C to receive anything from another node? not a gateway.
Really appreciate your support…


Node to node communications are not part of LoRaWAN and have nothing to do with LoRaServer.

Your issue might be mismatched IQ polarity or bandwidth, but this is really not on topic here…

Thanks @cstratton for your quick response,
you sre absolutely right, but I’m just trying to understand how class C works,
I can’t get the node in class C to receive anything within the second receive window, even when I set everything to default and sent a packet from the server, it fails to get to the node.
within the nodes code, I have inserted a print message at the begining of the function “OnRadioRxDone( )”.
Thus far, the message is only printed when the node receives within the first receive window.
Also on the server side, when I go to the Live Device Data in the device page, I can see the packets I sent from the server as Ack. so does that means the packets are getting to the node but this function is only called when something is recieved at the Rx1?
I’m really confused and will appreciate any help from you guys…


That’s not how class C works.

It is not about receiving during RX2, rather it is about having the radio receiving with the air settings of RX2, all of the time except when it needs to be transmitting or briefly listening for something else (like RX1, etc).

Also it is not clear that your gateway is actually transmitting any class C downlinks…

when I go to the Live Device Data in the device page, I can see the packets I sent from the server as Ack.

What is that supposed to mean?

Hi @cstratton

when I issue the following command from the server:

mosquitto_pub -h localhost -t “application/2/device/1111111111111111/tx” -u user -P user -m ‘{“reference”: “abcd”, “confirmed”: false, “fPort”:7, “data”: “aGVsbG8=”}’

at the gateway it shows up as “UnconfirmedDataDown” and nothing shows up at the device page. However when I change the “confimed” into “true” it will show up as “ConfirmedDataDown” at the gateway and as “Ack” at the device Live Device Data page.

Bottom line, if I want to send a message to the device operating in class C during the listening time (Rx2), what configuration should I use please?


It should not matter, that should only govern if the node transmits an acknowledgement in return, but that can only happen after the packet is received by the node.

It’s a bit odd if an original downlink message is being displayed as an ACK, because it isn’t one.

But the immediate question is if the gateway is actually transmitting or not, and then if the node is not receiving, if the node was actually attempting to receive at that time, and if the settings the node was receiving with (frequency, bandwidth, spreading factor, IQ inversion, etc match those the gateway transmitted with).

Since you are interfacing with the MQTT, monitor the gateway/xxxx/tx channel too and see if a packet send command is issued after your application downlink command…

Note that you have to look into the content of the ack message as it could be either true or false!

@Norman With regards to now seeing the downlink under the device data tab, it only shows the communication from the device to the application (the data that your MQTT subscriber or application integration would receive). If you want to see the downlinks being scheduled, see the LoRaWAN frames tab.

Thanks again guys,
@cstratton please see below the logs from the server side after I issue the command bellow:

mosquitto_pub -h localhost -t “application/2/device/1111111111111111/tx” -u user -P user -m ‘{“reference”: “abcd”, “confirmed”: true, “fPort”:7, “data”: “aGVsbG8=”}’

lora-gateway-bridge log:

INFO[687602] backend: downlink packet received topic=gateway/aa555a0000000XXX/tx
INFO[687602] backend: publishing packet qos=0 topic=gateway/aa555a0000000XXX/ack

lora-app-server log:

INFO[688125] handler/mqtt: data-down payload received topic=application/2/device/ 1111111111111111/tx
INFO[688125] finished client unary call grpc.code=OK grpc.method=GetNextDownlinkFCntForDevEUI grpc.service=ns.NetworkServerService grpc.time_ms=1.36 span.kind=client system=grpc
INFO[688126] finished client unary call grpc.code=OK grpc.method=CreateDeviceQueueItem grpc.service=ns.NetworkServerService grpc.time_ms=27.835 span.kind=client system=grpc
INFO[688126] downlink device-queue item handled confirmed=true dev_eui=1111111111111111 f_cnt=11918
INFO[688128] downlink device-queue item acknowledged dev_eui=1111111111111111
INFO[688128] handler/mqtt: publishing message qos=0 topic=application/2/device/1111111111111111/ack
INFO[688128] finished unary call with code OK grpc.code=OK grpc.method=HandleDownlinkACK grpc.service=as.ApplicationServerService grpc.start_time=“2019-08-21T12:55:39+01:00” grpc.time_ms=2.084 peer.address=“[::1]:39698” span.kind=server system=grpc

loraserver log:

INFO[688178] finished unary call with code OK grpc.code=OK grpc.method=GetNextDownlinkFCntForDevEUI grpc.service=ns.NetworkServerService grpc.start_time=“2019-08-21T12:56:34+01:00” grpc.time_ms=0.943 peer.address=“[::1]:33894” span.kind=server system=grpc
INFO[688178] device-queue item created dev_eui=1111111111111111 f_cnt=11918
INFO[688178] finished unary call with code OK grpc.code=OK grpc.method=CreateDeviceQueueItem grpc.service=ns.NetworkServerService grpc.start_time=“2019-08-21T12:56:34+01:00” grpc.time_ms=28.639 peer.address=“[::1]:33894” span.kind=server system=grpc
INFO[688178] device-queue item updated dev_eui=1111111111111111 emit_at_time_since_gps_epoch=“” f_cnt=11918 is_pending=true timeout_after=“2019-08-21 12:56:34.098157518 +0100 BST m=+688178.237665396”
INFO[688178] backend/gateway: publishing downlink frame qos=0 topic=gateway/aa555a0000000XXX/tx
INFO[688178] device-session saved dev_addr=0718ec7d dev_eui=1111111111111111
INFO[688180] device-queue deleted id=99
WARN[688180] device-queue item discarded due to timeout dev_eui=1111111111111111 device_queue_item_fcnt=11918
INFO[688180] finished client unary call grpc.code=OK grpc.method=HandleDownlinkACK grpc.service=as.ApplicationServerService grpc.time_ms=3.075 span.kind=client system=grpc

As for the receiving parameters (frequency, bandwidth, spreading factor, IQ inversion, etc) it should be matched between the gateway and the node as I haven’t change them. (using the default)

@brocaar the packet sent from the server, at the device in the Live Lorawan Frames page it shows as “ConfimedDataDown” and within that packet the “ack: false”
and in the Live Device Data page it shows as “ack” again with the “acknowledged: false”

I just want to know how to receive a packet within Rx2 in class C node?

Many thanks

Rather than making assumptions, I would want to see the actual air settings either from the MQTT gateway/…/tx message or from the packet forwarder logs

And I’d like to see a printout from the node firmware that it sets the radio to those settings and was attempting to receive during that same timeframe.

Also evidence from the packet forwarder syslog that it actually transmitted.

Do I know that any of those things are the issue? No, but so far you’ve provided no information which can actually rule them out.

Hi Guys,

Can anyone please explain why I’m getting the following error when I issue the same command?

mosquitto_pub -h localhost -t
“application/2/device/1111111111111111/tx” -u user -P user -m
‘{“reference”: “abcd”, “confirmed”: true, “fPort”:7, “data”:

I got this:

1576023710: New client connected from ::1 as mosqpub|25258-debian (c1, k60, u’user’).
1576023710: Client mosqpub|25258-debian disconnected.

I just need to send a downlink from the server to the device