OTAA accept not received when in reach of multiple gateways

Gateways
6

No idea.

7

Wow, the amount and depth of all your answers is awesome! :smiley:

Let me try to summarize the topics:

  • The tracker is my first toy project to learn about LoRaWAN/TTN and to test my TTIG. The SW is based on https://github.com/kizniche/ttgo-tbeam-ttn-tracker, but forked to https://github.com/grillbaer/ttgo-tbeam-ttn-tracker to make it compilable with PlatformIO and to make experimenting easier. Now it’s “real” C++, but the libs are still the Arduino ones, running on a ESP32.

  • I tried SF9 after the first tests with the default (and recommended) SF7 to get a feeling for the range.

  • LoRa lib: MCCI LoRaWAN LMIC library@2.3.2 = https://github.com/mcci-catena/arduino-lmic
    BTW, does anybody know a better one for HPD13A or RFM95W? There seem to be many of them out there… difficult to choose from.

  • Timing indeed was an issue in my first OTAA tests with SF7 near my own GW. LMIC_setClockError(MAX_CLOCK_ERROR * 5 / 100) seems to solve it. Of course, I’m not sure if it is really solved in all situations…

  • The SW uses LMIC_setDrTxpow(sf, 14) to set the TX power to 14 dBm = 25 mW. That’s what I would have expected.

  • Ok, I understood that OTAA should better be used with ADR on, which is not well suited for moving devices. There is no problem to go back to ABP for me, but I read so many times to use ABP only for development and to prefer OTAA instead. However, this should be no problem for this test and anyway, the LMIC lib seems to reset my ADR=off after joining with OTAA, so that I have to set ADR=off and SF=x again. Maybe this hacky re-setting before every send() is part of the problem… Going to ABP would also remove the rejoins. It looks like they are triggered by the LMIC lib automatically.

  • As suggested, I’m going to take the tracker into the vicinity of the other GW and see, what happens… but probably not before the week-end. Great tip!
    I could also try to log RSSI and SNR on the device’s side to see, if the values are near those of on the GW side.

  • I was wondering if posting EUIs and DevAddrs in the forum is considered a problem, because I saw it blacked out in several posts. Thanks for the info. Now my first post is another bad example which will lead more people to anonymize it :sunglasses:

  • Is there an easy way to retain the Console App/GW traffic logs without a permanently open browser? Sending app data to integration “Data Storage” drops the meta-data. The CSV from TTN Mapper keeps at least some meta-data.

So, the next steps for me are a) to test OTAA near the other GW, b) to compare RSSI/SNR between node and GW and c) to drop OTAA for this node and use ABP.

Thanks again for all your support!

1 Like
8

For the application you could use mqtt, that includes all meta data. There is no such alternative for the gateway. However, if you search the forum you might find a message where someone saves the data from the browser.

1 Like
9

If I understood the docs correctly from a quick first look, there is already a MQTT server from TTN up and running and I only have to subscribe to the relevant topics as client. That’s great!

10

Yes, for node data you just subscribe. No need to run your own mqtt server.

11

Not my cup of tea, but it might depend on the antenna gain as well? Are you using any special antenna? (Also, I recall that some LMIC- based libraries actually stated setting the power did not even have any effect, so you might not even be able to change it…)

And maybe test with the TTIG disabled, to ensure it’s not related to, e.g, the following?

(You always seem to get a value for gtw_id, so I’d assume the above does not apply to you. But it might help to be sure. Maybe you can even reach the other gateway from home when using a much higher SF.)

12

This is the current LMIC reference library for the Arduino framework and SX1276 based modules like HPD13A and RFM95W. But version 2.3.2 is not the latest version.

1 Like
13

No. I expect a small helix inside the <40 mm plastic cover:
image
Shouldn’t antenna gain have a quite symmetric effect on TX and RX? But I don’t know to much about HF…

That would be a simple way to test it. I’m going to do some more tests at the week-end, perhaps they give some more insights.

14

Gain, yes. But something like digital or power supply noise from the local system is more likely to be an issue for receiving than transmitting.

That said LoRa has a LOT more immunity to such things than other sub-GHz schemes (OOK remote controls are very susceptible for example)

1 Like
15

Oh, thank you :smiley: I only looked at the github releases, not the tags. Then I’ll switch to MCCI LoRaWAN LMIC library@3.0.99.

Is this lib a good choice for ESP32? It needs not necessarily be based on the Arduino libs for me.

16

Sounds possible. I could try to have a look at the LoRa power supply with the oscilloscope. This revision of the T-Beam board has some mighty multi-purpose AXP192 power management chip on it, the big chip between display and antenna with nearly as much pins as the µC, which is covered by the display. Who knows, what its output looks like…

17

Another fun fact that might affect/help your testing of downlinks transmitted by remote gateways, after the device has joined: (at least) in the EU868 frequency plan, a downlink in RX2 uses SF9, regardless what SF was used in the uplink. And that uses an increased power:

This does not apply to the OTAA Join Accept (as at that point the device does not yet know about the TTN-specific settings, which it actually gets in the data of that very Join Accept). But after joining, or when using ABP, you might turn off the close-by gateway, schedule a downlink in TTN Console, and transmit a SF11 or SF12 uplink to increase the chance that TTN will tell the remote gateway to use RX2 with SF9 and a higher transmission power for a downlink.

I’ve no idea of any of the above is useful for debugging the topic at hand. :slight_smile: However, testing for RX2 is good anyway!

1 Like
18

So, this is the noise on the 3.3 V supply voltage of the LoRa module:
image
Lots of bursts of spikes with at least 30 mV peak-peak.
On spike zoomed in:
image
And this is with a 100 nF capacitor soldered directly to the power supply pins:
image
Much better :slightly_smiling_face:

I have to stop the modifications before doing some more testing, now. Otherwise I won’t know what was the cause.

1 Like
19

Bypass capacitors are of course important.

I have to say my first guess is not that local digital noise is your problem - I mentioned that with regard to the antenna reciprocity question, but don’t mean to encourage getting too sidetracked.

My actual suspicion is that some software issue, either in the node or on the infrastructure side, is meaning that you aren’t ending up with a LoRa radio transmitting and receiving with compatible settings at the same exact time.

20

Yes it is, but if you prefer to use Espressif ESP-IDF instead of the Arduino framework, the same library has been ported to ESP-IDF.

See ttn-esp32 here:
Overview of LoRaWAN Libraries [HowTo] - #7 by blem

1 Like
21

We will see … hopefully :slightly_smiling_face:

Trying to figure out, why things don’t work as expected, is a great way to learn and get more insights in my eyes. Learning by debugging :wink:

22

Perhaps I can employ this hint, but I’ll first try to go step by step. Thanks :slightly_smiling_face:

1 Like
23

Today, I did some more testing.

The t-beam now displays RSSI and SNR for all downlink messages. Unfortunately, I don’t know how accurate the readings from the HPD13A registers on this board are. I used the conversion from the SX1276 data-sheet, since it’s a clone and I did not find a separate data-sheet. This does not take board specifica into account. The LMIC lib itself seems to contain some hardcoded conversions for RSSI, which do match for this chip.

I also added some shielding to the board. With this, I was able to get some successful joins at locations, where it did never work before.

The MQTT messages on my mobile phone were of great help!

Tests:

  1. My TTIG off, so only the other GW was within reach. Joins were possible, but the success rate was 50% at best. It almost always received the join requests (visible in MQTT app log), but the device did not always receive the response. Even when I was only some hundred meters away, only about every second attempt succeeded.
    The RSSI/SNR values at the GW were always better than those displayed on my device. Some samples:
    location A: GW -108/8 vs. dev -112/4
    location B: GW -72/12 vs. dev -82/7.5
  2. My TTIG on, the device in the same house. I saw the join accepts coming from my GW. Joins were almost always successful, only sometimes the responses were not visible on my GW traffic log. RSSI/SNR about GW -68/10 vs. dev -80/9.
  3. I tested with a second T-Beam, same revision, also with shielding. The behavior and RSSI/SNR readings were not much different.

Looks like a mixture of multiple issues for me:

  1. My t-beam still has some problems with the other GW, even if RSSI and SNR are very high. Reason unknown, SW/HW/timing on device or other GW or …
  2. My t-beam has only rarely join problems with the TTIG, if it is close to it.
  3. The t-beam seems to have some issues on the receiving side, which can slightly be improved by additional shielding.
  4. The other GW seems to be more sensitive than my TTIG with the internal antenna, so the problems start not too far away from my TTIG.
  5. For tracking/mapping, I could simply switch to ABP and all problems will be gone because there will be no downlinks any more, then.
  6. When I find the time for it, I’d like to do some tests with an interrupt based lib variant. Timing looks like a likely cause for me.

I’ll keep you informed when I get more findings. :slight_smile:

1 Like
24

Were you able to determine if a join accept was generated? LMiC for example likes to randomly guess for a join nonce, and if it hits one that’s been used before, no accept will be generated until it increments to a not previously used value. Especially if your RNG is not very random, the more tests you run, the more likely it is that it will take some time to get to fresh values.

I’d like to do some tests with an interrupt based lib variant

It’s not entirely clear how that would help, unless you mean that you’d use a slightly less than one second hardware timer to enter receive mode the correct duration of time after transmitting.

Even if you are polling for the transmit complete, you should be able to poll rapidly enough to to notice it with low latency (just don’t do something like print the polled status - that would likely cost time)

2 Likes
25

Another thought/line of enquiry… what do you know about the remote GW? As has been suggested earlier timing can be an issue and if the remote GW is e.g. on a cellular backhaul it is poss that associated latency esp wrt 3G can be enough to push the system out on timing missing the window. That might explain why even relatively close to it & with reasonable Rossi/sir values you still hit & miss response. Can you contact the owner & enquire? Knowing the gw - type/model/packet forwarder may help also as there is some variability in speed of operation between systems…

2 Likes