Arduino LMIC: cannot receive downlink messages

I’m using an arduino uno with a dragino lora shield and a dragino single channel gateway. The gateway is connected to the TTN and the uplink is working fine.

When I create a downlink message in the TTC console, it is received by the gateway and it gets transmitted. I verified this by a second arduino with a dragino shield which just receives packets a writes the the serial port.

The arduino node is never receiving the downlink message. I have tried to use the #define DISABLE_INVERT_IQ_ON_RX but still no luck.

This is a log produced by the arduino node:

168618426: TXMODE, freq=868100000, len=17, SF=8, BW=125, CR=4/5, IH=0
Packet queued
168623911: irq: dio: 0x0 flags: 0x8
168623955: Scheduled job 0x2be, cb 0x4d9 ASAP
168624014: Running job 0x2be, cb 0x4d9, deadline 0
168624286: Scheduled job 0x2be, cb 0x73e at 168811476
168811478: Running job 0x2be, cb 0x73e, deadline 168811476
168811604: RXMODE_SINGLE, freq=868100000, SF=8, BW=125, CR=4/5, IH=0, RXSYMS=5
168811943: irq: dio: 0x1 flags: 0x80
168811990: Scheduled job 0x2be, cb 0xe18 ASAP
168812076: Running job 0x2be, cb 0xe18, deadline 0
168812347: Scheduled job 0x2be, cb 0x755 at 168873976
168873979: Running job 0x2be, cb 0x755, deadline 168873976
168874104: RXMODE_SINGLE, freq=868100000, SF=8, BW=125, CR=4/5, IH=0, RXSYMS=5
168874379: irq: dio: 0x1 flags: 0x80
168874426: Scheduled job 0x2be, cb 0xe2f ASAP
168874512: Running job 0x2be, cb 0xe2f, deadline 0
168874782: EV_TXCOMPLETE (includes waiting for RX windows)
168875101: Scheduled job 0x24f, cb 0x595 at 172625099

I have noticed that the RX timeout IRQ is called about 6ms after the receive is started. This seems a bit short to me as the receive window should be around 1 second. I have added the RXSYMS value to the log which is used as the timeout value for the receive.

Is the timeout supposed to be just 5 symbols for the RX window? I think this should be calculated from the length of the rx window or do I get something completely wrong here?

Cheers
Bernd

1 Like
  • arduino uno with a dragino lora shield
  • dragino single channel gateway

So what’s the difference between arduino1 + draginoshield that don’t work and arduino2 + dragino shield that seems to work ?

The second one isn’t a LoRaWAN node using the LMIC, but just receices LoRa packets and logs them. This one is in an endless receive loop, so there are no timeouts.

which single channel forwarder do you use… not all support downlinks

I use the packet forwarder for the dragino gateway:

It supports downlinks, but this support seems to be in a more experimental stage.

With the second arduino I see the packtes which are transmitted by the gateway and they seem to be in the correct timeframe.

have a look at this one https://github.com/matthijskooijman/arduino-lmic/

This is the LMIC library I use for the arduino node which produces this very short timeout IRQ.

ok but it must function on the node too

did you check the dragino topic(s) ?

Okay, uplink.

Okay, RX1, for EU-868 using the same settings as the uplink. However, nothing was received, so the node will listen again after a second.

Not okay. RX2 should not use the same settings. Instead, for EU-868 it should listen on 869.525 with SF9BW125.

TTN Console should tell you if RX1 or RX2 is used, by looking at whether the downlink is scheduled 1 or 2 seconds after the uplink. (But even if it’s RX1, you should fix the settings for RX2 as well.)

Also see LMiC’s MAX_CLOCK_ERROR.

2 Likes

I changed this just for the testing to see if I can receive any downlink message.

Setting this actually did the trick. Allowing for a greater clock error increases the timeout value for the receive window for the downlink message.

The implementation of the downlink feature of the dragino packet forwarder isn’t very precise with the timing to put it mildly. It seems it needs a bit more work to be really useable.

Thanks!

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?

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.

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?

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

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/

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.

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.

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

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

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?