RAK2749 ignoring downlinks

mohsin · October 17, 2019, 3:24pm

Hello,

I am connecting a Seeeduino LoraWan board to RAK2749 gateway which is using Semtech UDP Packet forwarder to forward the messages to hosted loraserver.io instance in the cloud.

In summary:

Node sends a confirmed uplink to gateway
Gateway forwards this confirmed uplink to loraserver instance
loraserver processes the uplink
loraserver sends an downlink with ack: true down to gateway
gateway recieves the said downlink

Here the problem lies. The gateway doesn’t informs the Node about the confirmed downlink at all. This is a problem since the node doesn’t recieves the “ack” and thinks the packet didn’t reach the server at all. Where in real life it has.

Untitled

Here is the gateway packet logger, with the downlink details opened:

Here is the loraserver live lora frames showing the downlink being sent down to the gateway:

The system log constantly is saying “[up] Receive Downlink Packet! Drop it”. Here is the screenshot. I think this has something to do with this problem. But can’t seem to find any setting related to this. Here is screenshot:

Here is the log from my seeeduino’s Serial monitor:

+VER: 2.1.15
+ID: DevAddr, 00:50:BB:11
+ID: DevEui, 47:68:B2:69:00:20:00:3C
+ID: AppEui, 52:69:73:69:6E:67:48:46
+KEY: NWKSKEY 2B7E151628AED2A6ABF7158809CF4F3C
+KEY: APPSKEY 2B7E151628AED2A6ABF7158809CF4F3C
+KEY: APPKEY 192B37530EE3C8B4C0C42E86304BA14A
+MODE: LWABP
+DR: AU915
+DR: DR0
+DR: AU915 DR0 SF12 BW125K
+CH: 0,916800000,DR0:DR5
+CH: 1,917000000,DR0:DR5
+CH: 2,917200000,DR0:DR5
+RXWIN1: 0,916800000
+RXWIN2: 917200000,DR8
+LW: DC, OFF, 0
+LW: JDC, OFF
+POWER: 14
Completed Initialization
Starting script

Message: H:51.27,T:26.58,P:95138.00,A:528.86,

Failed to recieve ack. Trying again
+CMSGHEX: Start
+CMSGHEX: Wait ACK
+CMSGHEX: Done
Failed to recieve ack. Trying again
+CMSGHEX: Start
+CMSGHEX: Wait ACK
+CMSGHEX: Done
Failed to recieve ack. Trying again
+CMSGHEX: Start
+CMSGHEX: Wait ACK
+CMSGHEX: Done
Failed to recieve ack. Trying again
+CMSGHEX: Start
+CMSGHEX: Wait ACK
+CMSGHEX: Done
Failed to recieve ack. Trying again
Couldn’t send payload 1, giving up

The code is sending a confirmed uplink with data to the gateway. I am actually receiving these packets as expected on the gateway and server. The only problem is that the acknowledgement is not sent to the seeeduino (node).

The questions are:

Is there any setting which I have to enable to allow the gateway to send this acknowledgement to the node?
What does the message “[up] Receive Downlink Packet! Drop it” mean in the gateway system logs?

Nicholas · October 18, 2019, 1:40am

I am very sorry that I did not understand what you mean. After sending data with RAK811 node, when sending confirmation package and non-confirmation package, he will have different responses to the node.

mohsin · October 18, 2019, 12:01pm

Kindly refer to the updated question above. I have edited it with more information.

cstratton · October 18, 2019, 2:27pm

That might be what is happening, or it might not be.

The key thing to understand is if:

the gateway does not transmit for some reason
the gateway does transmit, but the node does not receive because it is listening with different settings
the gateway does transmit but the node does not receive because it is listening at the wrong time.

The system log constantly is saying “[up] Receive Downlink Packet! Drop it”.

That message is indeed mysterious, as it is not in the upstream Semtech code but rather seems unique to RAK’s binary builds. It seems to imply some sort of protocol mismatch resulting in the upstream thread somehow ending up with a downlink packet, instead of the downlink thread that is supposed to receive it. But it may be that only the person who wrote those customizations would really know.

Either that, or the gateway actually is transmitting, but is hearing itself, and filtering those packets out rather than uselessly reporting them to the server. That is something that does seem to happen if uplink and downlink frequencies are the same as they might be in your setup.

As for frequencies and matching settings…

Your server view of the situation shows a transmission on 923.9 MHz.

In contrast, your node firmware seems to claim it would listen at:

+RXWIN1: 0,916800000
+RXWIN2: 917200000,DR8

These settings do not match, and would lead to failure

You node firmware also implies it is using “AU915” but its settings do not match that.

AU915 RX1 should be:

Downstream – 8 channels numbered 0 to 7 utilizing LoRa 500 kHz BW at DR8 to DR13) starting at 923.3 MHz and incrementing linearly by 600 kHz to 927.5 MHz

and RX2 would be

The RX2 (second receive window) settings uses a fixed data rate and frequency. Default parameters are 923.3Mhz / DR8

My suspicion here is that your node firmware is incorrect and needs to be fixed. Do that first, then worry about any remaining gateway issues.

(If I had to guess, your node firmware is trying to use EU868 logic with the AU915 uplink frequencies, which is completely wrong. I seem to recall someone on another forum being proud to have created such a disaster about a month ago, perhaps you were unlucky enough to copy their broken code)