OTAA accept not received when in reach of multiple gateways

Or your device is exceeding the allowed/expected transmission power, which also makes “connections” with a gateway asymmetric? Assuming your TTGO T-Beam uses some LMIC code, see LMIC_setDrTxpow.

While changing code: to mitigate any downlink timing problems, see LMIC_setClockError. (Though I’d guess that usually gateways do okay with their side of the timing. So if the TTIG Join Accept is received, then the node’s timing might be just fine, and the other gateway’s Join Accept should be received too, when using the same SF? I’m not sure though, and @cslorabox already explained that timing might be an issue if the SF changes. So, you might want to use a fixed SF as well? TTN Mapper recommends SF7.)

Without even making changes to the code: what if you move closer to the other gateway? Getting one proper Join Accept from the other gateway will tell you if it is actually transmitting any. You’re mapping anyway. :wink: Or maybe you can even become a collaborator of the other gateway, to see its traffic; see also How to contact a gateway owner?

Oh, and I guess that powering down the TTIG does not make any changes? Then it’s not really related to multiple gateways, but just the combination of your node’s position and the other gateway.

Some asides: for moving (mapping) nodes, ADR is not recommended; see Why is ADR only relevant for nodes at fixed positions? Also, a DevAddr is not a secret (and not even unique, and will change for every new OTAA Join anyway). Same goes for the AppEUI and DevEUI.

1 Like

I have the same issue observed before. Downlink issue (observed at OTAA)
It is something that happens in the core infrastructure of TTN

1 Like

Offtopic, but… - how did you get your TTIG send time in metadata? My one doesn’t :frowning:

No idea.

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

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

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!

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

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.)

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

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.

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

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.

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…

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

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

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.

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

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:

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

1 Like