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. 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.
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
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.
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.
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!
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.
No. I expect a small helix inside the <40 mm plastic cover:
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.
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. However, testing for RX2 is good anyway!
So, this is the noise on the 3.3 V supply voltage of the LoRa module:
Lots of bursts of spikes with at least 30 mV peak-peak.
On spike zoomed in:
And this is with a 100 nF capacitor soldered directly to the power supply pins:
Much better
I have to stop the modifications before doing some more testing, now. Otherwise I won’t know what was the cause.
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.
Or maybe you can even become a collaborator of the other gateway, to see its traffic; see also How to contact a gateway owner?
I only looked at the github releases, not the tags. Then I’ll switch to MCCI LoRaWAN LMIC library@3.0.99.
However, testing for RX2 is good anyway!
