Unexplained reception discrepancies between two LoRaWAN Gateways

TTN Network and Services The Things Stack v3
1

In the context of a scientific research project, two antennas were compared. The goal was to evaluate their reception performance and determine whether, in urban areas or the specific area we are investigating, the beamwidth angle is preferable to pure gain measured in dBi. LoRaWAN appeared to be predestined for the precise evaluation of SNR and RSSI.

Therefore, two MicroTik-Gateways LR8 wAP were set up identical in settings and firmware, except for the antennas, to avoid interference. They were placed a minimum distance of one lambda of the 868 MHz wavelength apart, yet close enough to ensure similar conditions, and operated simultaneously. Antenna 1 with 8 dBi has a beamwidth of 10° (ID lorawan-at-hs-flensburg-de), and Antenna 2 with 6.5 dBi gain has a beamwidth of 30° (ID eui-323433362e006200).

LoRa-Antennen
LoRa-Antennen1920×1440 291 KB

Unfortunately, on the first day of reception (August 11), both gateways received a large volume of data, which was traceable in the “Live Data” tab.

After 3 hours, 23 minutes, and 59 seconds, the gateway with the 6.5 dBi antenna stopped receiving anything, while the gateway with the 8 dBi antenna continued to deliver very good reception performance 24 hours a day.

I reset the gateway with the 6.5 dBi antenna on August 14, and the situation did not change; according to the “Live Data” tab in the TTN Console, it received and transmitted only a single packet, then nothing more.

I let it run and restarted the gateway with the 6.5 dBi antenna on September 6, after which it was active for 4 hours, 21 minutes, and about 52 seconds. After that, it again received absolutely nothing.

A reset on November 6 did not change the situation, so it continued to receive NOTHING, leading me to restart it one last time on November 26, after which it received and transmitted sensor data to TTN for 1 hour, 7 minutes, and about 25 seconds.
After that, I was no longer able to get the gateway to receive anything.

Here is the complete log again:

August 11, 2023: Reception was active for 3 hours, 23 minutes, and about 59 seconds.
August 14, 2023: Only one reception time was registered on this day, so the active duration is listed as 0 seconds.
September 6, 2023: Reception was active for 4 hours, 21 minutes, and about 52 seconds.
November 6, 2023: Only one reception time was registered on this day as well, resulting in an active duration of 0 seconds.
November 26, 2023: Reception was active for 1 hour, 7 minutes, and about 25 seconds.

An active duration of 0 seconds means that there is only one dataset on those days, indicating that deduplication or whatever it may be, acted “faster” on those days.

The gateway with the 8 dBi antenna operates continuously without any problems, with very good reception performance…

Can anyone explain how this phenomenon occurred? I am wondering if deduplication or link budget could be the reasons for this phenomenon, but I also don’t see a correlation over time with the duration of transmission into TTN.

2

My 1st suspicion would be unstable GW! so 1st diagnostic action for me would be swap the gW’s, keeping the power, networking and antennas in original place - just swap the boxes - then see if problem follows…

1 Like
3

Jeff-UK, thank you for your quick response. I also exchanged the gateways to rule out the possibility of having a defective unit. Unfortunately, this did not change the situation; it seems that the gateway is not the issue, which I had also thought.

4

First thought: too close when one of them downlinks at max power. Move one antenna above the other to mitigate that risk.

Question: are both gateways on the same NATter network? And are you using the UDP based packet forwarder? If so can you move one of them to a network that has a different public IP (or use a VPN to some other exitpoint on the internet)?

2 Likes
5

So 2nd would be the stability of the network connection to that location? Are you using wired ENet or are you using the MiKrotik WIFi option? …just seen Jac’s post and concur both wrt avoiding horizontal alignment and segregation of IP traffic, can you use BasicStation?
Problem with changing ant arrangements of course is you are then compromising the experiment as physical locations different and doesnt take much to get wildly different results!

Other option is run with same ant/network/GW etc for a period then swap Ant to reflect desired options and then compare data after the fact wrt statistics etc…there is a reason why characterisation tests are usually done in same installation, rather than parallel rigs, in anechoic RF conditions :wink:

1 Like
6

Thank you for your prompt and impressively thorough and helpful responses.

Regarding your first thought: I am hesitant to change the antenna configuration and position one antenna above the other, as I can no longer scientifically claim identical conditions. If the gateways are too close to each other, why don’t they both affect each other? The setup with the 8 dBi antenna runs flawlessly 24 hours a day.

Both configurations utilized the UDP packet forwarder pre-installed on the RBwAPR-2nD&R11e-LR8 - wAP LR8 kit. Both gateways are supplied with power and connected to the same network/internet via CAT cables with PoE, through a Mikrotik Routerboard PowerBox installed specifically for this experiment.

For a while, I spoofed the geolocation of the gateway with the 6.5 dBi antenna and removed positiondata in TTN and fed the data via a VPN, but I discarded this approach due to concerns that, for instance, a slow VPN server could cause delays, and the TTN NS might discard packets due to delay since, after a restart, the gateway often temporarily succeeded in forwarding LoRaWAN data to TTN. Which assumptions are you leaning towards, or what do you think could be the reason that you’re asking these questions? Do you think we can rule out ADR or deduplication?

7

Also, a huge thank you to you for your prompt and helpful input.

The stability of the network connection at the location is assured. The primary, stable internet is backed up with a failover script in the switch with a secondary backbone. And the gateway with the 8 dBi antenna also runs through the switch and continuously transmits sensor data to TTN, so I can rule out the network connection as a source of error.

In this characterization test, I really wanted to try to have exactly the same signal (an Adeunis field test device is used as a tracker) processed by both antennas at the same time, each with its own SNR and RSSI, to have identical temporal and thereby unchanged weather and environmental influences, as no anechoic chamber is available and I wanted to compare under real conditions.

I simply don’t understand why, after a certain, seemingly random amount of time, the packets from the 6.5 dBi antenna stop. I tried to explain it with deduplication, but I am unsure about that and hope for the community, who with more knowledge of TTN and LoRaWAN might better pinpoint the error source. However, I thank you both very much for your effort and look forward to your assumptions about what it could be to write that in my academic paper.

8

I know you have swapped the two gateways around and proved that the gateways are not at fault.

Did you try to just swap the two lan connection points around?

9

The fact is you can’t do that anyway with even just a horizontal displacement! See comments above… indeed it can be argued your deployment is worst than vertical displacement as they’re firing directly into each other’s rf front ends - with not even polar chart mitigation. That leads to a host of effects that I won’t go into here as you simply arent’t paying enough! :rofl:

10

With respect I would suggest this isnt a ‘characterisation test’ but rather a ‘comparison test’ (see comments above) - it may be a language/choice or words thing as I suspect English not 1st language? (German?), and as such there are lots of caveats that need to be considered.

If you search the forum you will see many instances were we decline to do academic’s homework for them :wink:

After working with LoRa/LoRaWAN for >>10 years and RF in general for far longer have seen many academic papers on the subject and many if not all have flaws and or incorrect assumptions that need to be recognised and acknowledged. Real world tests tend to get away from theory in ways that suprise on many occations and the papers either follow a characterisation approach or take a more statistical/mathematics steer. (Former direct repeatable measurements, usually with know ‘fixed’ test set-ups, latter typically needing very large quantities of data to validate and eliminate statistical anomolies, ofetn gathered over a wide area). When considering your set up do research on very near field, vs near field vs far field RF, evaluate how nodes and GW’s identify each other and how GW’s ignore other GW’s (unless on Helium in which case GW-GW comms often more highly prized than node-GW!), evaluate the classic ‘near/far problem’, look at the specifications for the antenna types used (in contect of these comments), look at the specifications of the Semtech and other associated RF parts in the GW systems, look at the previous body of work (both SMTC and other academic) on LoRa modulation characteristics especially wrt error perfromance, interferance (bursty and statistical/steady state) noise floor etc. As noted also look at network direct connections, not just shared backhaul).

What mode are you running

in? Are you respecting both FUP (as on TTN) and legal limits?

Are you using confirmed or unconfirmed messages?

11

That is already the case now. With this wavelength even an horizontal displacement of 9cm might make a difference. In your current setup you risk damaging the input RF circuits of the gateways rendering the experiment worthless anyway.

That is probably a very important factor. I’ve seen multiple occurrences where two UDP packet forwarders originating from the same public IP were not handled correctly. There might be some protection mechanism in the stack that kicks in or another contributing factor like NAT that messes things up (not worth my time to research as I usually don’t use UDP)

Without an anechoic chamber the way I would go about this is to have LoRaWAN sensors at fixed locations transmitting at regular intervals and change antennas mounted at the same spot using the same gateway. If you collect multiple days of data for each antenna and average the resulting signal quality parameters you should have comparable results.
Make sure to use locations that are outside the beam for both antennas as well as the results might surprise you…

And don’t forget to report back on the results. We’re curious as to your findings…

BTW, you could use plain Lora equipment for the tests as well. And if you choose a frequency not used by LoRaWAN users in your vicinity you would be able to use up to the legal limit of airtime which should provide a lot more data in a shorter period.

12

Thank you for this consideration. In TTN, under the Gateways tab with the ID, there is an online status link with a blue button that always indicates to me that the gateway is online. Moreover, in the Live data tab, the “Receive gateway status” messages come in, but unfortunately, nothing else at all… Consequently, I assumed that I wouldn’t need to look for the error in the network or internet connection.

13

Yes, “comparison test” definitely fits better, please excuse my really poor English but it truly isn’t my native language, I’m an old, rusty German who unfortunately rarely takes the opportunity to speak, or to write in English. You were able to deduce my nationality very well. Please forgive me, I promise to improve.

I didn’t mean to imply in any way that you should do my homework for me, I was just hoping for an explanation, since I simply don’t understand technically why one gateway receives incredibly well and the other stops receiving after an undefined period of time and only writes “Receive gateway status” in the Live data. I was looking for an explanation that I could substantiate with literature, I believe “Deduplication” and “ADR” are quite wrong, but they were my only explanations so far.

You have given me very good pointers in many directions, but researching these directions exceeds my completely available time frame. However, I’ll sleep on it to see how I might be able to implement one or another suggestion after all. You seem to be blessed with impressive expertise; I wish for you to be accordingly highly rewarded. Thank you for sacrificing your time here in the forum for free, especially for newbies like me.

1 Like
14

Fascinating approach, thank you, I will have to ponder this further. I haven’t seriously considered this before, as the use of UDP likely means the fastest data packet arrives at the NS, and I want to statistically rule out the possibility of one gateway always “winning” and sending out UDP data faster than the other. I would have guessed that in such a case BOTH gateways would experience packet loss - it also doesn’t explain why for the first few hours it works wonderfully in parallel in both gateways and then suddenly not at all, and only in one of the two gateways, while the other continues to perform outstandingly… But I will continue to look into this area and maybe it is indeed a possible source of error.

15

If you aren’t on satellite links with hundreds of millisecond ping times the network speed is not an issue. Deduplication is hundreds of milliseconds, not a few or tens.

Is the ‘winning’ gateway always the one connected to the same antenna? Or is it always the same gateway?

However, regardless of the two gateway issue, as mentioned before two antennas in different locations invalidates your data. Check Visualizing WiFi With A Converted 3D Printer | Hackaday to see what happens if you move a receiving antenna with regards to the transmitter. The same principle applies with two receivers and transmitters in different locations.

16

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.