New Application V3 OTAA not working

Today I have tested my lds01 on V3. JOIN is successful with 1.0.3 but V3 keeps scheduling downlinks:


My assumption is that RX1 is not set to 5 seconds and therefor the device does not receive the downlink message.

Fun-fact is that V3 is setting RX1 delay at 4,5 sec ???


1 Like

In (my) case of failed to schedule it is not even sent to the gateway …

I also thought about this, but this should be negotiated with the join.

Assuming that the device responds correctly you may be right. However, the device responce to the ADR request is never received by V3. Therefore I state that the downlink was never received by the device.

1 Like

Yes, I think our devices don’t receive, or process the downlinks.

Sure but the question is if this is caused by the change in timing that is not accepted by de device (dragino ldr01) or by V3 that is not processing MY settings?

As my device works fine in V2, although it seems that the firmware is not processing downlink ok, I would expect that settings in V3 would provide a solution.

E.g. V3 malfunctions and the device needs an firmware upgrade.

Also got major issues with V3 and Dragino Water-detectors (LWL01).

When switching the same device between V2 and V3 it works fine in V2.
But in V3 it tends to run up to SF12 , since it does not seem to get the downlink confirmation.

Also, the downlink commands on LWL01 work perfect in V2, but again no success in V3.

Running a Mikrotik Gateway, but also having issues with a Dragino LPS8 gateway.

Feels like a timing issue with downlinks…?

1 Like

I updated the LPS8 to support V3, so it no longer routes through V2.
This was in hope that it would resolve some timing issues.
It did not

Here something “strange”?
I sent a downlink with two bytes : 0x05 0x00 (should turn off uplink confirmation on LWL01)

But the MAC payload becomes 0A 40 …that doesn’t seem right?
(right click image , then “View image” for full view)

Or what am I missing?


You payload is encoded before transmission, that is why it looks different.

Both LWL01 and LDS01 use the same base firmware which seems to have issues with the downlinks. I’m trying to find time in my schedule to dig into the sources to find what might be causing the issue. (Got too many of them not to be able to use them on V3)


Thanks Jac

Right, after spending a few hours on debugging the LoRaWAN library Dragino based their LDS01 and LWL01 sensor code on it seems there is a serious bug in a binary only part of the library.
After the join reply is processed the RX1 delay is correctly set to 5 seconds, only to be reset to 1 second by some black magic in the binary only part of the library (asrlib.a).

A quick and dirty test with version 4.4 of the library suggests the problem has been resolved. Not sure if it might be fixed in 4.3, not tested by me as tests with different versions take a lot of time to backport to my test code.

Looks like Dragino will need to release updated firmware for their ASR650x based products to make them compatible with V3 (@edwin)


Thanks again Jac!
So I guess that’s why the LWL01 & LDS01 work with V2 since RX1 delay is 1s.

Being curious, what libraries (V4.4, V4.3, asrlib.a ) were you refering to?
I thought that LDS01 and LWL01 were closed source code.

About the debugging: I guess the RX1 values can be viewed with AT +CRX1DELAY
And setting them to 5s just won’t stick …?

The code for Dragino ASR650x sensors is based on code available on github.

That is just the base LoRaWAN code for the chipset (akin LMIC for other hardware). The functionality for the devices is Dragino proprietary code. If you would want to create working code for the hardware yourself you’ll need hardware documentation of the devices as well which is subject to NDA.

Dragino has the LM502 which is based on the same chip and they’ve released their (modified version) of SDK 4.2 on github.

1 Like

Thanks @kersing , We will fix this.


For a temperory fix, user can enter AT+CRX1DELAY=5.


How long will the device keep this setting? Until a power cycle?

Please keep us updated when the new firmware is ready to be deployed! :smiley:

That setting is permanent.

So this would probably solve the issue?

It works around the issue for TTN V3. It can be used as a permanent work around.


If you want that, you’ll be best off subscribing to the GitHub repository as what you are basically asking is for someone to notice and update and then send you a message.