RAK4631 - AWS - IoT - Downlink Fail

Issue:
LoRaWAN Node will not receive downlink message from AWS-IoT

Setup:
Gateway Rak7258
Node Rak4631
Use basic arduino app LoRaWAN_OTAA_ABP.ino

LoRaWAN Server:
AWS-IoT

Details:

  • Gateway is able to connect and authenticate with AWS-IoT
  • Node is present in AWS-IoT, and appers in the aws-iot list as a LPWAN-device.
  • Node is able to send telemetry messages to AWS-IoT.
  • We can view Node’s uplink messages in both AWS-IoT, and Gateway logs.

When I go to AWS-IoT LPWAN device Traffic tab (in AWS-IoT), I can click a button to “Queue a Downlink Message”. I fill in the FPort as “2”, the message as “QTEK”(which is base64 message-“A1” encoded as Base64), and chose the Acknowledge checkbox.

I can see the message listed in the queue summary on the AWS-IoT “Traffic” screen, but it NEVER is sent to my Node, although the Node continues to successfully send its telemetry into AWS-IoT.

My Node operates in Class-A, is situated right next to my Gateway.

Is there some additional setting I need to make, in order to enable the Node to receive? I have not made any changes to the lorawan_rx_handler() callback.

There is no additional setting required to receive downlinks.
I tested with your message, same and different fPort and it works.
But I do not have access to an AWS-IoT LNS. I can only test with Chirpstack and TTN.

This is from the “unchanged” example code (just adjusted DevEUI, AppKey and LoRaWAN region):

Do you see the downlinks in your gateway logs?
Are there any error messages in the AWS LNS log?

Thank you Beegee. Your response adds a lot of confidence that my Node is coded correctly.

  • AWS LNS logs? No. Amazon is totally silent. My message remains untouched in the Downlink message queue. Amazon documentation states that the AWS LNS should automatically attempt to send the next downlink message from the Queue, as soon as it receives the next message from my Node.

QUESTION I have a theory. I could be possible that AWS-IoT is working properly, and attempting to send, but due to network latency the Node’s Class-A 1.0-sec Receive-window has already expired when this downlink message eventually propagates through these latencies??

Is there a way to extend the Node’s Receive Window from 1.0-sec to maybe 3-sec?

UPDATE–

  • Gateqay logs? Yes, I just noticed data coming from AWS-IoT. (Sample below). I remind you that my Node is placed within a meter of my Gateway. For some reason, the Node is missing these downlink messages.
Thu Oct 10 12:50:20 2024 user.info basicstation[5020]: [SYN:INFO] Mean MCU drift vs SX130X#0: -1.1ppm
Thu Oct 10 12:50:21 2024 user.info restify: 127.0.0.1 - - [10/Oct/2024 12:50:21] "GET /diag/syslog HTTP/1.0" 200 -
Thu Oct 10 12:50:23 2024 user.info restify: 127.0.0.1 - - [10/Oct/2024 12:50:23] "GET /diag/syslog HTTP/1.0" 200 -
Thu Oct 10 12:50:25 2024 user.info restify: 127.0.0.1 - - [10/Oct/2024 12:50:25] "GET /diag/syslog HTTP/1.0" 200 -
Thu Oct 10 12:50:27 2024 user.info restify: 127.0.0.1 - - [10/Oct/2024 12:50:27] "GET /diag/syslog HTTP/1.0" 200 -
Thu Oct 10 12:50:29 2024 user.info restify: 127.0.0.1 - - [10/Oct/2024 12:50:29] "GET /diag/syslog HTTP/1.0" 200 -
Thu Oct 10 12:50:30 2024 user.info restify: 127.0.0.1 - - [10/Oct/2024 12:50:30] "GET /diag/syslog HTTP/1.0" 200 -
Thu Oct 10 12:50:32 2024 user.info restify: 127.0.0.1 - - [10/Oct/2024 12:50:32] "GET /diag/syslog HTTP/1.0" 200 -
Thu Oct 10 12:50:32 2024 user.info basicstation[5020]: [RAL:INFO] RX mod=LORA f=904100000 bw=113 sz=78 dr=8 40ADFF800100B30402DC4B7A002928C73C58792AC1100226416159326B97B90A858B894028281681FCA962BD53B4F8595288633BD75303D35ACA76EB144911646DA33FCD9FB42073B799E40B653E
Thu Oct 10 12:50:33 2024 user.debug basicstation[5020]: [LOG:DEBU] rrd_statistic_up-357 uplinkTqByAirtime: dr=2, timeonair=246, tm=1728564632
Thu Oct 10 12:50:34 2024 user.debug basicstation[5020]: [LOG:DEBU] rrd_statistic_up-359 uplinkTqByPkt: dr=2, tm=1728564632
Thu Oct 10 12:50:34 2024 user.debug basicstation[5020]: [LOG:DEBU] rrd_statistic_up-361 ChanBusyByAirtime: chan=1, timeonair=246, tm=1728564632
Thu Oct 10 12:50:34 2024 user.debug basicstation[5020]: [S2E:DEBU] ::1 diid=38777 [ant#0] - next TX start ahead by 499ms543us (06:17:32.639269)
Thu Oct 10 12:50:34 2024 user.debug basicstation[5020]: [S2E:VERB] ::1 diid=38777 [ant#0] - starting TX in 49ms662us: 923.9MHz 26.0dBm ant#0(0) DR12 SF8/BW500 frame=A0ADFF800180010002284710CE671CFE (16 bytes)
Thu Oct 10 12:50:34 2024 user.info basicstation[5020]: [RAL:INFO] RAL_LGW: lgw_send done: count_us=2873480547.
Thu Oct 10 12:50:34 2024 user.debug basicstation[5020]: [LOG:DEBU] rrd_statistic_down-421 downlinkTqByAirtime: dr=4, timeonair=21, tm=1728564633
Thu Oct 10 12:50:34 2024 user.debug basicstation[5020]: [LOG:DEBU] rrd_statistic_down-423 downlinkTqByPkt: dr=4, tm=1728564633
Thu Oct 10 12:50:34 2024 user.info basicstation[5020]: [S2E:INFO] TX ::1 diid=38777 [ant#0] - dntxed: 923.9MHz 26.0dBm ant#0(0) DR12 SF8/BW500 frame=A0ADFF800180010002284710CE671CFE (16 bytes)
Thu Oct 10 12:50:34 2024 user.debug basicstation[5020]: [S2E:DEBU] Tx done diid=38777
Thu Oct 10 12:50:35 2024 user.info restify: 127.0.0.1 - - [10/Oct/2024 12:50:34] "GET /diag/syslog HTTP/1.0" 200 -

I don’t recommend changing the RX window timings. It is very rare that this is required.
And on the node side, there are two RX windows, one of them should receive the packet.

Can you place the node farther away from the gateway. Only 1 m distance can lead to an over-saturation on the node antenna, which can lead to a damaged packet that is ignored.

UPDATE—

The situation has FIXED ITSELF

After a Gateway reboot and trying again the next day, AWS-IoT messages are finally arriving at my Node.

This is Great!

For-What-It-Is-Worth: here is my callback function:

/**@brief Function for handling LoRaWan received data from Gateway
 *
 * @param[in] app_data  Pointer to rx data
 */
void lorawan_rx_handler(lmh_app_data_t *app_data)
{
//    Serial.printf("LoRa Packet received on port %d, size:%d, rssi:%d, snr:%d, data:%s\r\n",
//          app_data->port, app_data->buffsize, app_data->rssi, app_data->snr, app_data->buffer);

    Serial.printf("(Rx)\r\n");
    Serial.printf("(Rx)\r\n");
    Serial.printf("(Rx)\r\n");
    Serial.printf("RX: Port:  %d\r\n", app_data->port);
    Serial.printf("RX: Size:  %d\r\n", app_data->buffsize);
    Serial.printf("RX: RSSI:  %d\r\n", app_data->rssi);
    Serial.printf("RX: SNR:   %d\r\n", app_data->snr);
    Serial.printf("RX: Data:  %s\r\n", app_data->buffer);
    Serial.printf("(Rx)\r\n");
    Serial.printf("(Rx)\r\n");
    Serial.printf("(Rx)\r\n");
}

Hello jonovos!

AWS LNS has indeed log information about the IotWireless devices (LoRaWAN and SideWalk) in their Amazon CloudWatch logs, you can use this guide for it → Configure Logging for AWS IoT Wireless - AWS IoT Wireless

regards!

1 Like