Downlink problem on Adafruit Lora M0 and TTN-GW-868

TTN Network and Services
1

My device does not receive any downlink messages.

Here is my configuration:

  • Device: Adafruit Feather Lora M0
  • Gateway: TTN-GW-868
  • Join: ABP
  • European frequencies
  • Uplink is working fine

I trigger a downlink through the TTN console. The gateway shows that the message is sent with the same SF and frequency as the before received uplink.

I am also able to connect to the gateway with OTAA.

The debug message of the LMIC library show:

    7:52:19.607 -> start single rx: now-rxtime: 9644
    07:52:19.607 -> 9770839: RXMODE_SINGLE, freq=867300000, SF=7, BW=125, CR=4/5, IH=0
    07:52:19.993 -> rxtimeout: entry: 9794728 rxtime: 9761208 entry-rxtime: 33520 now-entry: 3 rxtime-txend: 62126
    07:52:20.767 -> start single rx: now-rxtime: 19280
    07:52:20.767 -> 9842790: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
    07:52:21.162 -> rxtimeout: entry: 9866681 rxtime: 9823458 entry-rxtime: 43223 now-entry: 4 rxtime-txend: 124376
    07:52:21.549 -> 9890746: EV_TXCOMPLETE (includes waiting for RX windows)
    07:52:22.112 -> 9926613: engineUpdate, opmode=0x900

I use LMIC_setClockError(MAX_CLOCK_ERROR * 10 / 100); I am not sure were I can see the extended receive interval in the debug messages. Anything, I can do to further debug the situation?

After some more tests, I was able to send some data. BUT: it requires

LMIC_setClockError(MAX_CLOCK_ERROR * 40 / 100);

and

#define LMIC_ENABLE_arbitrary_clock_error 1

in the lmic_project_conf.h

This is probably not the way it should be. Any idea?

2

So, OTAA works without the very large value for LMIC_setClockError?

The OTAA Join Accept also uses a downlink. The differences with a “regular” downlink:

  • RX1 is 5 seconds instead of 1 second
  • RX2 is 6 seconds instead of 2 seconds
  • For EU868 RX2 uses SF12 instead of SF9 (which is communicated in the Join Accept message)

For EU868, that indicates it’s using RX1. If you’re seeing 869.525 MHz in EU868, then that’s RX2.

So, I’d start investigating there: what’s different for the OTAA Join Accept to make that succeed, while apparently subsequent downlinks fail?

3

Thanks for your reply. I am now not able to reproduce the OTAA case. The accept is sent but the device blocks. Nevertheless, the uplinks with 40% error works.

From the numbers in the debug output

rxtime-txend: 62126
rxtime-txend: 124376

seem to be correct. With an 62500 osticks/sec, this is exactly 1 and two seconds. Since the uplink is sent in rx1 and with 40% error it works, it might be too early or too late. Can this be a problem of the TTN-GW-868 gateway?

4

Downlinks, I assume. The uplinks should work regardless any setting of LMIC_setClockError.

Well, assuming that value is correct, and assuming an extremely accurate clock: yes.

I doubt the gateway will have timing issues. Maybe it would suffer the ERROR: Packet REJECTED, unsupported RF power for TX - 24 but that would not be fixed using LMIC_setClockError, so unlikely that’s also your problem. Or maybe network latency makes the downlink arrive at the gateway too late. Make sure the gateway’s router and application’s handler use the same region.

(Aside: “TTN-GW-868” is too vague. TTN Kickstarter “The Things Gateway”, “The Things Indoor Gateway” or “The Things Outdoor Gateway”? And if it’s the outdoor one: ethernet or 3G/4G?)

I’m afraid there is not much else to investigate. You’ll need an extra gateway or an extra device for more testing. Or peek into the gateway’s log. (See the FAQs in the documentation.)

5

The uplinks works very reliably.

I trigger the downlink through the TTN console. I see that it is first scheduled in the data of the device and with the next uplink, the message is sent.

I tried with two Adafruit feather boards. It is exactly the same.

The gateway is this one https://de.farnell.com/the-things-network/ttn-gw-868/the-things-gateway-eu/dp/2675813. I will order a UART adapter and try to see the debug messages from the gateway.

I will do some test with the gateway at our compute center. But, due to Corona this cannot be done now.

I will post news as soon as there are some. Thanks for your time.

6

Yes, but just to be sure you understand: those are unrelated to using LMIC_setClockError. Uplinks cannot suffer from any timing issues.

Aside, as I doubt this will fix anything: there are many LMIC implementations. GitHub - mcci-catena/arduino-lmic: LoraWAN-MAC-in-C library, adapted to run under the Arduino environment seems to be best maintained and supports the M0 LoRa for 900 MHz.

Also make sure to test with a sketch that does no real work, to ensure LMIC gets enough processing time in loop.

7

Well, we seem to be having very similar problems! Feather M0s, dodgy downlinks, can’t easily test with another gateway until covid goes away…

Is your gateway’s backend mobile network, wifi, or ethernet?

I’m glad you pointed out the #define that is required to enable the clock error to be defined. I was wondering why setting the clock error did not seem to have any effect. Having said that, I’m still not sure it’s making a difference.

I deleted all the versions of LMIC I had lying around, and the Arduino IDE to be sure, and then installed the latest version of the MCCI variant using the library manager. This time I did not make any changes except to set the region to as923, and these lines after LMIC_reset:

LMIC_setClockError((MAX_CLOCK_ERROR * 10) / 100);
LMIC_setLinkCheckMode(0); // Is this necessary?

Joining and downlink performance increased noticeably after going to the latest version of MCCI LMIC. Joining could take 40 - 60 minutes before, now usually less than 10.

I’m asking for downlinks to be ack’d so I don’t have to keep resending them myself and am getting them in between 1 and 4 uplinks usually, occasionally 5 or 6.

I’m checking for changes in LMIC.radio.rxlate_count, and have not logged one yet.

My gateway is mobile network backed and I’m hoping going to a wired or wifi gateway will sort it out.

The point about the gateway and TTN application having the same region is interesting too, but not something I can check because I have no access to the gateway config.

8

For other readers: note that for many regions LMIC joining uses a scenario to decrease its data rate if a join failed on all channels for a given data rate. So, joins taking some time might also indicate that the Join Request uplink was not received, hence no Join Accept downlink would be sent at all.

In your case, for AS923, it seems it always uses SF10 for the OTAA Join Request. Still, the Join Request uplink might not be received of course.

So, in any case, make sure you see the orange Activation icon in the device’s Data page in TTN Console (or the timestamp after the device’s Status label in TTN Console), to confirm that the Join Request uplink was received.

9

I see a bunch of messages with I think little lightning flash icons. I have been assuming those are join attempts from the node.

I’m wondering if I should just go to ABP instead. I can’t see why pre-shared keys would be a problem. If you’re only supposed to join as little as possible, what is the difference between saving and using the OTAA negotiated keys for as long as possible, even over reboots, and ABP? Sorry if I’m messing up some concepts, you can tell I’m new to LoRaWAN.

10

Given your other forum posts, you want the downlinks to work properly anyway. Also, one may want ADR, which needs downlinks too. So, no, using ABP is just ignoring the real problem. (And it would introduce different problems, like if the device does not properly persist state between restarts.)

For the sake of completeness:

…and: accepted. TTN might reject it if the configuration is wrong (in which case it would never accept it), or if its random LoRaWAN 1.0.x DevNonce was used before (which can be mitigated if one has done a lot of testing).

In the TTN Console Data page, those are OTAA Activations, so: the Join Request (which is only shown in the gateway’s Traffic page) was accepted by TTN, and a new DevAddr and secrets have been assigned. Hover your mouse over the icon to see “activation”.

1 Like