Arduino LMIC: cannot receive downlink messages

End Devices (Nodes) LMIC
11

Hi,
As per the topic I am not receiving download messages on my Adafruit Feather 32u4 + LoRa 868mhz board.
When I provisioned the Feather board on the Thingpark backend I defined it as a Class A device which means that the download payload is only sent once the upload is finished.

I am using Postman to issue the download data via the Thingpark IOT server rather than the TTN backend.

The payload is a 0x05 since all I want to do is switch a relay controlled via the Feather board.

From the Thingpark backend I can see the data packet being sent at SF9, Subband G1 and in RX2 window.

At the bottom is lists the delivery error “Delivery Failed Cause on RX1: Class A: LRC selected RX2(C0)”
The full transmission report is as follow:

mac data 2018-07-18 10:11:19.812 2018-07-18 12:11:19.812 SF9 G3 RX2

Mtype: UnconfirmedDataDown

RX1/RX2Delay: 2000

Flags: ADR : 0, ADRAckReq : 0, ACK : 0, FPending : 1

Mac (hex): 0301ff0001

MAC.Command.LinkADRReq
MAC.LinkADRReq.DataRate_TXPower : 0x01
MAC.LinkADRReq.DataRate_TXPower.DataRate : 0
MAC.LinkADRReq.DataRate_TXPower.TXPower : 1
MAC.LinkADRReq.ChMask : 0x00ff
MAC.LinkADRReq.Redundancy : 0x01
MAC.LinkADRReq.Redundancy.ChMaskCntl : 0
MAC.LinkADRReq.Redundancy.NbTrans : 1

Data (hex): 05

Data size (bytes): 1

AirTime (s): 0.144384

Delivery Status: Sent

Delivery Failed Cause on RX1: Class A: LRC selected RX2(C0)

ISM Band: EU 863-870MHz

AS ID:

Joining is not a problem once I added the clock correction but made it a 2
LMIC_setClockError(MAX_CLOCK_ERROR * 2 / 100);

My code does not use sleep since it is a externally powered application.
I have set up a 1 minute clock that results in the data upload every 15 minutes of the relay state.

I sent the download control listed above just prior to upload.

When I look at the detailed LMIC log from my device I get the following with no indication of any download data being detected after

The log is as follows:

Switch = 45 // My 15 minute cycle upload run
.
18087204: engineUpdate, opmode=0x908
18087308: Uplink data pending
18087393: Considering band 0, which is available at 21793521
18087565: Considering band 1, which is available at 14513135
18087734: Considering band 2, which is available at 1183284
18087902: Considering band 3, which is available at 0
18088057: No channel found in band 3
18088161: Considering band 0, which is available at 21793521
18088333: Considering band 1, which is available at 14513135
18088504: Considering band 2, which is available at 1183284
18088680: No channel found in band 2
18088784: Considering band 0, which is available at 21793521
18088955: Considering band 1, which is available at 14513135
18089128: Airtime available at 14513135 (channel duty limit)
18089295: Airtime available at 15689717 (global duty limit)
18089460: Ready for uplink
18090174: Updating info for TX at 18087307, airtime will be 20609. Setting available time for band 1 to 1877934080
18090558: TXMODE, freq=868500000, len=19, SF=10, BW=125, CR=4/5, IH=0
Sending data to backend:
=== Switch index = 46
18465556: irq: dio: 0x0 flags: 0x8
18465672: Scheduled job 0x341, cb 0x1c9c ASAP
=== Switch index = 47
18840853: Running job 0x341, cb 0x1c9c, deadline 0
18841009: Scheduled job 0x341, cb 0x1caf at 18527673
=== Switch index = 48
19216150: Running job 0x341, cb 0x1caf, deadline 18527673
19216372: RXMODE_SINGLE, freq=868500000, SF=10, BW=125, CR=4/5, IH=0
=== Switch index = 49
19591573: irq: dio: 0x1 flags: 0x80
19591691: Scheduled job 0x341, cb 0x1cb7 ASAP
=== Switch index = 50
19966870: Running job 0x341, cb 0x1cb7, deadline 0
19967025: Scheduled job 0x341, cb 0x1cce at 18588381
=== Switch index = 51
20342168: Running job 0x341, cb 0x1cce, deadline 18588381
20342389: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
=== Switch index = 52
20717461: irq: dio: 0x1 flags: 0x80
20717579: Scheduled job 0x341, cb 0x1c22 ASAP
=== Switch index = 53
21092885: Running job 0x341, cb 0x1c22, deadline 0
Event = 10 EV_TXCOMPLETE (includes waiting for RX windows)
21096181: engineUpdate, opmode=0x900

==========================================================
Summary:
The download control is sent to the RX2 window at SF 9
There appears to be a 2 second delay between the upload and the download as based on the

Question: What do I have to do or change to make sure that the RX 2 window is open to receive the download data on my device?

12

I don’t know the Thingpark backend, so I cannot say much to that.

The TTN uses 869525000 for the RX2 Window. When the response is sent in the g2 subband the frequency is in this range:

g2 (868.7 – 869.2 MHz): 0.1%

This might explain why your board doesn’t get the message in the rx2 window.

13

Many thanks,
on closer examination of the data I see that I was incorrect, the transmission band is in fact G3 for the download and not G1.

Based on your initial comment about the frequencies for subband G1, can you shed some light on the situation if the band is in fact G3?

Question:
Is there any way of getting the exact time when the RX1 and RX2 windows are actually opened after the upload is completed?

14

I was able to confirm that the expected download subband is in fact G3.
In the Lorabase.h file the following assignments are made:

// Default frequency plan for EU 868MHz ISM band
// Bands:
//  g1 :   1%  14dBm
//  g2 : 0.1%  14dBm
//  g3 :  10%  27dBm
//                 freq             band     datarates
enum { EU868_F1 = 868100000,      // g1   SF7-12
       EU868_F2 = 868300000,      // g1   SF7-12 FSK SF7/250
       EU868_F3 = 868500000,      // g1   SF7-12
       EU868_F4 = 868850000,      // g2   SF7-12
       EU868_F5 = 869050000,      // g2   SF7-12
       **EU868_F6 = 869525000,      // g3   SF7-12**
       EU868_J4 = 864100000,      // g2   SF7-12  used during join
       EU868_J5 = 864300000,      // g2   SF7-12   ditto
       EU868_J6 = 864500000,      // g2   SF7-12   ditto
};
enum { EU868_FREQ_MIN = 863000000,    EU868_FREQ_MAX = 870000000 };

enum { CHNL_PING         = 5 };
enum { FREQ_PING         = EU868_F6 };  // default ping freq
enum { DR_PING           = DR_SF9 };       // default ping DR
enum { CHNL_DNW2         = 5 };
enum { FREQ_DNW2         = EU868_F6 };
enum { DR_DNW2           = DR_SF12 };		//	Was DR_SF12 - RBC
enum { CHNL_BCN          = 5 };
**enum { FREQ_BCN          = EU868_F6 };**
enum { DR_BCN            = DR_SF9 };
enum { AIRTIME_BCN       = 144384 };  // micros
15

Yes, the time for the RX1 and RX2 windows is at 1 second and 2 seconds after the transmission has finished:

https://www.thethingsnetwork.org/docs/lorawan/

16

I was assuming that the reason why I am not receiving the download packets is that there is something wrong with the way my code is working.

Would I be wrong to assume, for now, that receive portion of the code is not waking up in time for the download message to be processed or is closing too quickly.

That said, I was wondering how I could track the start and end times when each window opened once the TxDone function was completed.

17

In each line of the log from the application there is the os tick when this log message was generated. You can check and print the value for OSTICKS_PER_SEC which is a define of the library. For my Arduino this is 62500, but it might be different for your board. With this value you can calculate the actual time value from the ostick value.

Start of the transmission is the TXMODE line and RX1 and RX2 are the RXMODE_SINGLE lines.

Are you sure the backend is using the frequency you expect in the RX2 window? When the band g2 frequency is used, you cannot receive it in the RX2 windows with the current configuration.

18

That is a very good question and one that needs to be confirmed.
I assume that the only indication of the frequency is the G3 value in the Thingpark log as shown below:

image

Also the fact that there is an error makes your question extremely valid

image

19

There is also the

RX1/RX2Delay: 2000

If this is the total value it seems to be ok, but if this is the delay per window, then it is too long. The software on the device uses 1 second delay for each window.

1 Like
20

Do you by any chance know how the downlink data is collected?
By that I mean, is there an interrupt, that has to be triggered during the RX 1 and Rx2 window open time, for the data to be download data to be read in?

21

No. When LMiC prints RXMODE_SINGLE it’s actually listening for a short time, to see if it can recognise the “preamble”, and if it finds that, it will just read the downlink for you. (Actually the LoRa chip will do that for you, when LMiC tells it to.)

As the clock of the node might not be very precise, using MAX_CLOCK_ERROR one can make LMiC start listening a bit earlier, and listen a bit longer.

22

Also, don’t ignore:

And what did you intend to write here?

23

Hello,
First, apologies for the interruption.
Second,
I have been trying to figure out how to receive downlink messages, but I am not able to receive anything. Uplink works fine with no problems. The build I am using is the Dragino kit (LG01-P Single-Channel Gateway, Arduino Uno + Dragino LoRa Shield) for US915 MhZ. The IoT server is TTN, activation mechanism is ABP, and the library used is LMIC.

Gateway configuration →

47
47968×1026 64.4 KB

TTN Gateway Traffic →

45
452112×754 117 KB

As Bernd first mentioned (our setup is similar), the gateway packet forwarder code seems to support downlink, and it is indeed receiving downlink from the TTN and transmitting what has been received. →

44

Node logs →

32
321156×758 110 KB

As shown in the images, I am using 903.3 (SF7BW125) for uplink, and 923.3 (SF12BW500) for downlink.

I have tried incorporating

LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);

in the code, but it didn’t solve the problem.
From what I have observed, the gateway seems to report receiving the downlink and transmitting it just as the node’s log report the second

RXMODE_SINGLE

Thus, I thought of trying to increase the delay value of the RX_1 receive window from the lorabase.h file, but that didn’t help.
Any suggestions? :sweat_smile:

Thanks in advance

24

Please don’t post logs as images. Now I’ll leave it up to you pinpoint that some of your setup mentions SF9 for downlinks, while the gateway logs shows TTN uses SF12 instead.

See also https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#us902-928

25

Thank you for your reply Arjan. Sorry about the image logs!
I believe you’re referring to the gateway transmit spread factor? I changed it to 12, but no luck.

I just tried changing the SF of the first RX_WINDOW to SF12 to test if it changes anything, but I am still nothing. However, the gateway’s log now reports receiving a downlink and transmitting it just after the node’s serial monitor shows the first RXMODE_SINGLE (I guess the timings are more aligned now?).
Regarding the TTN frequency plans page - am I missing something?

I am quite new to all of this, forgive the ignorance :slight_smile:

26

Too bad your single channel gateway is apparently using a fixed frequency and SF for downlinks (if I understand the setup screen correctly); for downlinks it could easily use whatever TTN tells it to use. I’m not sure how to read the frequency plan, but TTN and your node are probably using the same settings, while your single channel test gateway seems to use specific settings.

You can see if RX1 or RX2 is supposed to be used by comparing the tmst of the uplink and the downlink. The difference is the time in microseconds. For your previous screenshot it was 2 seconds, hence RX2 indeed.

27

Hi, one thing that I am still checking out, based on an earlier question of " Are you sure that the backend is broadcasting on the expected frequency?"

It seems that, in my case, we are using the 868 MHz specification, but the Thingpark backend is using, according to their specification, the G3 subband which operates at 434.04 - 434.79 MHz…

28

So based the fact that you are also not receiving downloads, I would suggest that you also make sure, that the backend is using the expected download frequencies.

29

TTN frequency plan shown in the link you provided me displays 8 channels for uplink, each channel corresponding to a downlink as well (903.9 → 923.3… 904.1 → 923.9… etc). All un-used ones were disabled (as I am using a SCG).

Therefore, I think specific settings are applied on all 3 sides (TTN, gateway, and node). Logs from the gateway show that every time a downlink message is received, it is received in the same configuration as the ones before.

Then I assume that if I set RX1 & RX2 to (SF12BW500), I’d be guaranteeing receiving it every time if timing is correct? (Since all downlinks coming from TTN seem to be using the same SF, BW, and frequency. Only difference in windows used).

Thanks for your reply sir. I first checked the LMIC library’s lorabase.h file to confirm what frequency is used for downlinks if CFG_915 is used (since I am using US915), and it matches what I specified for downlinks. Also, I have taken a look at the gateway traffic in the TTN console, TTN also seems to be using 923.3.

lorabase.h file

// Default frequency plan for US 915MHz
enum { US915_125kHz_UPFBASE = 902300000,
US915_125kHz_UPFSTEP = 200000,
US915_500kHz_UPFBASE = 903000000,
US915_500kHz_UPFSTEP = 1600000,
US915_500kHz_DNFBASE = 923300000,
US915_500kHz_DNFSTEP = 600000
};
enum { US915_FREQ_MIN = 902000000,
US915_FREQ_MAX = 928000000 };

Downlink messages seem to have (288 - 329ms) airtime. Is this normal? Uplinks average at 66ms.

Thanks in advance

30

The devices I have seen operate either in the 868 MHz band or in the 433 MHz band, because the HF part has to be tuned to the specific frequency range. Therefore I think it is highly unlikely that the backend responds in the 433 MHz range when the join request and the uplink operates in the 868 MHz range.

But, as I don’t know the Thingpark backend, I cannot say this for sure.