hi all
I recently migrated my IoT infrastructure to AWS IoT Core for Lorawan. I managed to implement everything we had related to the old lns for AWS, except downlink for class A devices.
The tests were carried out with Dragino devices, specifically RS485LN, LDDS20 and LHT65.
Below is information I have about the tests
RS485 declared as class A device (but it is a class C endpoint), AU915:
Downlinks are executed correctly via the console and the Boto 3 SDK. Message goes to the downlink queue, remains for a few seconds and disappears from the queue, confirming sending and the change sent via downlink takes place such as changing the data transmission interval. What was curious to me: Even though it is declared as class A in AWS, the downlink message remains in the queue until an uplink from the device arrives. However, as it is class C and reception is always open, everything is ok for downlink.
LDDS20 and LHT65, both class A devices, declared as class A device in aws, AU915,
using the same device profile for the RS485LN:
Both through the console and through the SDK the downlink goes to the message queue, stays for a few seconds (sometimes 1 or 2 seconds) and disappears from the queue, just like for the RS485LN, the downlink leaves the message queue before an uplink arrives. Strange for a device declared as class A. However, my command sent via the downlink is not executed. And when I activate acknowledge mode, I receive an error message in the network analyzer, as shown in the json below
The logs I got for this problem with class A devices
network analyzer
{
"ResourceId": "-------------------------------------",
"Timestamp": "2023-11-06T20:33:09.462288823Z",
"CustomerLog": {
"wirelessDeviceType": "LoRaWAN",
"resourceId": "---------------------------------",
"logLevel": "ERROR",
"resource": "WirelessDevice",
"messageId": "--------------------------------",
"event": "Downlink_Data",
"message": "Downlink message failed. MessageId: bee0508f-81f3-43be-8d97-d529a862303a. Downlink metadata: {\"FPort\":1,\"ParticipatingGateways\":{\"DownlinkMode\":\"SEQUENTIAL\",\"GatewayList\":[{\"GatewayId\":\"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\",\"DownlinkFrequency\":923900000}],\"TransmissionInterval\":1}}",
"wirelessDeviceId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"devEui": "xxxxxxxxxxxxxx",
"timestamp": "2023-11-06T20:33:09.462288823Z"
}
}
The impression I have is that lns is not managing the downlink sending for class A devices. It may have to do with the non-synchronization of the downlink sending at the physical layer in relation to the time interval in which the device is able to receive the downlink , the intervals rx1 and rx2.
Some curious points:
-
I migrated the same class A devices that I'm having problems with downlink to helium LNS and kerlink LNS and I didn't have any problems with downlinks. Through the logs, I can track MAC command downlinks where synchronization is done with class A devices and their respective rx1 and rx2 ranges for downlink receptions. In AWS I have never seen logs with downlinks to MAC commands.
-
In the AWS LoraWan workshop, the example for running downlinks is done with the LHT65 device, which is exactly what I'm having problems with.
-
I didn't find anything and no one on the internet talking about similar problems
-
I tested the downlinks for class A using 2 different gateways, a Kerlink iStation and a Dragino LPS8. Both have the same error behavior
Questions:
-
How do I get more logs compared to what I have in the network analyzer? as shown above.
-
Regarding sdk boto 3, the parameter TransmissionInterval (integer) – [REQUIRED] (The duration of time for which AWS IoT Core for LoRaWAN will wait before transmitting the payload to the next gateway) Is it related to the intervals rx1 and rx2?
On the Helium console, the time difference between uplink arrival and downlink confirmation is approximately 0.41 seconds. The TransmissionInterval parameter, in addition to being an integer, has a minimum value of "1". I didn't find anywhere what the time unit is for this parameter. As not informed, I conclude that it is in seconds, according to the international system of units. If it is in seconds, in relation to receiving the downlink after 0.41 seconds, my class A endpoint would not be supported.
This problem I am facing has a critical impact on the company's operations. I would be very grateful if you could help me. Any additional information needed I can add here. Thank you very much in advance.
Greg, I finally understood what the problem was. I will make a comment below explaining this outcome. Tks.
@GREG , What if we have a device we want it operate as Class A at certain times and Class C at certain times ? FYI i am running into the same issue here , i get the downlink failed message as shown in this post above on every other downlink (i.e not all of them, some do go through) and when turn off classC support i don't see that happening , but i want to support class C also.