C Type node using ABP behaves as A type when sending downlink


C type node is working fine when in use OTA method.
But, when i use ABP, then the node behaves as A type even if i configure it as C type i.e. the downlink is sent to the node only after receiving the next uplink.

Any suggestions/comments/feedback.


Please note that when your node is configured as Class-C device, LoRa App Server will request LoRa Server to directly emit this frame:

However, when your node is not configured correctly to operate in Class-C, it is possible that the frame stays in the queue and is re-transmitted (in case of confirmed: true) on an uplink (thus falling back on Class-A receive window).

The C type behavior works fine when the node is configured for OTA but the same node behaves as A type (even when it is configured as C) just by changing the node to ABP method.

Could it be that the issue is related to your node firmware? As far as I’m aware of, for LoRa (App) Server it does not make any difference when sending Class-C data for a OTAA or ABP device.

With OTAA, the node-session is being created on a join-request. With ABP LoRa App Server creates the node-session using the provided data. From there on, all logic is the same for OTAA vs ABP.

My node’s ABP C type code works well with Orbiwise and Loriot. So i believe that the node firmware is working fine.

Any other suggestions ?

When i send the downlink to ABP C type then its goes into queue as shown by the below snapshot:

In the snapshot, the “pending” is shown to be “true”, but in the frame logs section, the “immediately” field is shown to be “true”. This is shown in my next reply (as a new user i cant have two images in a single comment)

Please suggest the remedy.


but in the frame logs section, the “immediately” field is shown to be “true”.


In the snapshot, the “pending” is shown to be “true”, but in the frame logs section, the “immediately” field is shown to be “true”

So it seem from the network-server side, there is no issue. As you sent your frame using confirmed: true, it is set to pending: true until your node acknowledges the frame :slight_smile: The frame has been transmitted to your node as you see in the screenshot above.

Is it not that “pending: true” means that the message is queued and will be sent later ?

On the node, i cant see the downlink message. It only gets delivered after next uplink. And the device is correctly configured as class C.

I am looking into it, will keep you posted. Meanwhile let me know if there is anything testings you would like me to perform.


No, pending: true means (in this case) that the frame has been sent, but that the server is waiting for an ACK from your node. When subscribing to the gateway/+/tx topic, you’ll probably see that it is sent with immediately: true to one of your gateways. The output will be more or less the same as in your screenshot.

What is the RX2 SF for India band “IN_865_867” ?

I believe C-type ABP device is not working due to mismatch in RX2 SF. The RX2 SF for IN_865_867 as defined by LoRa Alliance is SF8 but when i send a downlink to my C-type ABP device then it is sent on RX2 SF12.

Let me know how i can modify the RX2 SF for IN_865_867 .

This is also as specified in:

Please note that you can override these params in Advanced network settings of the node (LoRa App Server).

It worked.

Thnx !!!

1 Like