Hello everyone,
If i am using two gateways for one device then i am recieving data on both gateways but on things network i am recieving data from that gateway for which i am getting better RSSI.
If i want to recieve data from both the gateways. Is there any way or we can recieve from one gateway only.
1 Like
If both gateways are connected to TTN and receive the uplink and both use a fast internet connection you will get a single uplink in your application with in the metadata the information on both gateways like gateway ID, rssi, snr etc.
You will never get two individual uplink packets in your application.
Hello,
I’m sorry to reply to this months after the last response, but I do have some concerns.
Two years ago i clearly remember (not to mention i have proof about it, lots of logs stored) that TTN would provide a list of maximum 30 Gateways that received the uplink message and forwarded it successfully to the servers.
As the original poster of this discussion mentioned, we now see only one.
That list was necessary for a research that i was planning on publishing.
I wonder therefore:
When was it made the decision to reduce the gateway list to a single one?
Are there any paid plans that would allow me to obtain the full list again?
It has not been decided and it is not the case. I still see uplinks arriving with multiple gateways listed. The last uplink I check was minutes ago and lists 3 gateways.
Hmm, i’ve started to experience the single-gateway thing when using ABP. Not OTAA. I feel like this is the result of using ABP, as in: given the limitations of how ABP works (Frame counter etc…) multiple gateways are not showing because of it?
Given how gateways work and how the TTN LNS works I don’t think ABP is the cause of what you experiencing.
Can you provide us with the location you are running the test(s)? (Not too accurate, but not miles away please)
Coordinates 52, 4.37 or thereabouts. Technological University of Delft Campus, Netherlands.
We used to receive a significant amount of gateways from the point we made these tests from, filling the quota of 30 in rx_metadata object of the uplink message, some up to 60 Km far, when using OTAA.
Nevertheless, now we receive only one with ABP. This test was repeated by providing the sending device using ABP with the same view, but also accompanying him with some 2 gateway of ours connected to TTN placed close to it to see whether the power of the system has changed.
The result, unfortunately, was that the uplink message in rx_metadata merely contained one of them, sometime cycling between the closest TTN gateway in view, with the other two at our disposal, but never more then one at the same time would be provided in the uplink message.
The only change was the use of ABP.
Do you still see only one gateway with OTAA?
Maybe @BNS knows about some weird science going on?
What firmware are you using and what gateways? Vendor & model please.
Hopefully not too close as that will cause reception issues.
Are the gateways behind some kind of NAT gateway?
To my knowledge no weird NAT is employed: we are able to see the gateways in our control receiving the messages from the end node when monitoring the dedicated gateway page (we see the upload occurring via the EUI of the device), yet not always the one of our gateways is shown as the receiving one in rx_metadata (which still displays a single one) in the end node page.
Our gateways are listed in the rx_metadata once in a while, alternating with the other gateways in the area, but still it feels like that there’s only spot in rx_metadata for the first one that successfully forwarded the packet to the TTN server.
We employ a Dragino LG308 and a Browan Minihub.
I’m at profound disbelief it is a matter of firmware.
In the next week some more tests will be done by sending via OTAA to isolate where we believe the issue occurs, I apologize if you may have to wait up until the end of this week or the next to have such results and have a proper response.
The ideal test is to have access to two or more gateways in range of this mystery device of which you have yet to reveal any hints as to its origin.
Then, with both the gateway internal logs and the TTS console for those gateways open, send.
If only one gateway shows the uplink on its internal log, you need to move a gateway until you get two in range. Then you can watch the TTS gateway consoles. And then capture the meta-data.
Ideally you have two of this mystery device, one setup for ABP and one for OTAA. Plus some off the shelf devices setup for ABP and OTAA as well.
It seems deeply unlikely that it is firmware related, if the uplink is being processed OK by one gateway & getting through to the application console, it would be rather odd for it to be discarded by other gateways.
Just to make a note, only one gateway being listed is possible if all the other gateways are on a backhaul that delivers the uplink too late to be included in the processing.
The window for the marking of the same uplinks has to be pretty narrow - at time of writing TTN is receiving 1,183 messages per second from gateways and then going on to deliver 258 messages per second.
So if it hangs around too long, it ends up with far more matching to do before it even gets to decryption, forwarding to the application server with all the steps in between.
That’s the Heltec handle buddy… But last time I visited TU Delft I apparently wasn’t carrying my tracker 
Anyway, as far as TTNMapper is concerned, you’re mostly out of luck on the Delft campus nowadays. Looks like you may have some luck around the Hogeschool or down south to the Schieweg, but you won’t be getting many more gateways at random.
As suggested by @nmcc (take that, Nick), a second device to test this would be useful, preferably a completely different make & model, just to observe what happens. And maybe configure the gateways to use a local hotspot just to rule out any networking issues.
this mystery device of which you have yet to reveal any hints as to its origin.
No need to be dramatic. The device being tested is a SAM R34 Chip. We have both custom boards and dev boards. Lorawan version used is 1.0.4.
Alternative tests via ABP can (and likely will) be performed with the use of an STM STM32WL55JC based board as to find the culprit.
This STM board is another device at our disposal that worked pretty well, despite the issues of STM.
That’s the Heltec handle buddy
We also have heltec end nodes, they work pretty well. But we didn’t achieve enough familiarity with them.
Probably will initiate tests with those as well via ABP to see what is going on.
Setup in general will involve the two gateways at our disposal, and of course any other gateway in range that is not ours but connected to TTN.
Again, both gateways at our disposal would commonly receive the message, but only one of them when employing ABP would result in rx_metadata.
It’s what it took to get a response … always helps to help those helping you out!
The more detail we get up front, the easier it is. Sometimes it ends up like pulling teeth!
That’s a joke about me tagging @stevencellist with his Heltec forum handle, where we answer questions on LW as well.
Well, i’m shocked.
This is from a sending of our Heltec End Node Board via ABP. Right now it displays merely the two gateways that are at our disposal, but also at times it listed some gateways of the area around connected via TTN.
Still, it’s two gateways.
{
"name": "as.up.data.forward",
"time": "2025-04-02T14:55:21.327024877Z",
"identifiers": [
{
"device_ids": {
"device_id": "eui-2032330000888802-heltec-abp",
"application_ids": {
"application_id": "loragpstrack"
},
"dev_eui": "2032330000888802",
"dev_addr": "007E6AE1"
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
"end_device_ids": {
"device_id": "eui-2032330000888802-heltec-abp",
"application_ids": {
"application_id": "loragpstrack"
},
"dev_eui": "2032330000888802",
"dev_addr": "007E6AE1"
},
"correlation_ids": [
"gs:uplink:01JQVFZT0TV4YRQ1RXJNPPAY03"
],
"received_at": "2025-04-02T14:55:21.322309967Z",
"uplink_message": {
"f_port": 2,
"frm_payload": "AAECAw==",
"decoded_payload": {
"bytes": [
0,
1,
2,
3
]
},
"rx_metadata": [
{
"gateway_ids": {
"gateway_id": "eui-a84041ffff2277f8",
"eui": "A84041FFFF2277F8"
},
"time": "2025-04-02T14:55:21.100229Z",
"timestamp": 3344886323,
"rssi": -112,
"channel_rssi": -112,
"snr": 4.2,
"frequency_offset": "15122",
"location": {
"latitude": 51.9964618082499,
"longitude": 4.37768161296845,
"source": "SOURCE_REGISTRY"
},
"uplink_token": "CiIKIAoUZXVpLWE4NDA0MWZmZmYyMjc3ZjgSCKhAQf//Inf4ELPU+7oMGgsI2Z+1vwYQ6tPdNSC4rovWrL7cAQ==",
"received_at": "2025-04-02T14:55:21.101948155Z"
},
{
"gateway_ids": {
"gateway_id": "dragino-644150",
"eui": "A840411CFE644150"
},
"time": "2025-04-02T14:55:21.097416Z",
"timestamp": 81090251,
"rssi": -29,
"channel_rssi": -29,
"snr": 9.2,
"uplink_token": "ChwKGgoOZHJhZ2luby02NDQxNTASCKhAQRz+ZEFQEMut1SYaCwjZn7W/BhD2ptg2IPiR7IquAg==",
"received_at": "2025-04-02T14:55:21.114692982Z"
},
{
"gateway_ids": {
"gateway_id": "eui-58a0cbfffe8055d5-mini",
"eui": "58A0CBFFFE8055D5"
},
"time": "2025-04-02T14:55:21.058933019Z",
"timestamp": 2021900163,
"rssi": -27,
"channel_rssi": -27,
"snr": 10,
"uplink_token": "CicKJQoZZXVpLTU4YTBjYmZmZmU4MDU1ZDUtbWluaRIIWKDL//6AVdUQg/+OxAcaDAjZn7W/BhDT+duCASC4r5CV7Do=",
"received_at": "2025-04-02T14:55:21.121620760Z"
}
],
"settings": {
"data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 7,
"coding_rate": "4/5"
}
},
"frequency": "868100000",
"timestamp": 3344886323,
"time": "2025-04-02T14:55:21.100229Z"
},
"received_at": "2025-04-02T14:55:21.115114344Z",
"confirmed": true,
"consumed_airtime": "0.051456s",
"version_ids": {
"brand_id": "heltec",
"model_id": "wifi-lora-32-class-a-abp",
"hardware_version": "_unknown_hw_version_",
"firmware_version": "1.0",
"band_id": "EU_863_870"
},
"network_ids": {
"net_id": "000013",
"ns_id": "EC656E0000000181",
"tenant_id": "ttn",
"cluster_id": "eu1",
"cluster_address": "eu1.cloud.thethings.network"
}
}
},
"correlation_ids": [
"gs:uplink:01JQVFZT0TV4YRQ1RXJNPPAY03"
],
"origin": "ip-10-100-12-233.eu-west-1.compute.internal",
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_APPLICATION_TRAFFIC_READ"
]
},
"unique_id": "01JQVFZT7FGDPQQSP2CR7QEYB4"
}
I do wonder at this point what issue our SAM R34 boards could have that has it alternate between the two close gateways we positioned around it (and the other gateways in the area), as to be received by the gateways but not be forwarded to the applications server.
Further tests to identify whether the cause lies on the firmware adopted will start as early as next week.
A bit of a guess: your Heltec nodes have a poor antenna and don’t overwhelm the gateways (right on the cusp: RSSI -27/-29 is way too close!) - the SAM boards have a proper antenna and almost always overwhelm the gateways, sometimes you’re in luck and one is able to decode the way too strong signal.
2 Likes
We fixed the problem.
It was mixed a fault of ours and of the framework adopted.
Apprently the internal SX1276 in the SAM R34 SoC wasn’t using the PA path we’ve designed for it, in spite of having it mandated to be used through registers programming. We solved with forcing the path with some frankenstein solution.
As a result, the signal in transmission was sent to a pin not connected to any antenna, probably the reason why it produced this abnormal phenomena of a single gateway.
Funny enough, even if the signal merely was sent to a pin of the RF Switch chip (which basically acted as an antenna, given it was not connected to anything), it was able to be received from a TTN gateway 500 meters away.
Hopefully issues have stopped with our project with regard to this matter, we thank you for your help, and apologize for the waste of time when we were at fault.
On the other hand I do have one other question on a possibility to produce more data for our research:
Is there a limit to the gateways that may be listed in rx_metadata? Is that limit 30?
In the event it is so, could a paid plan enable us to receive the full list of gateways? The more we are able to see in the list, the better it is for our research.
Don’t know without reading the source code (you could do that), but to hazard an informed guess, I doubt it. Pragmatically speaking (see the current thread about Australian RF physics & the law) no one would need 30 - or deploy that many gateways in range of a reasonably behaving device. The LNS has a job to do, looking up & collating a redundant amount of information isn’t one of them.
The TTN version of TTS is the same at the core as the TTI version, it comes with more functionality for managing your network. However the best way to find out is to ask one of the TTI staff.
There is a big but coming here. Any research you wish to do that involves a device hearing 30 or more gateways doesn’t sound hugely compatible with the community use of TTN. Whilst it is a ‘sandbox’ that is described as being for testing, it’s more for testing a use case, not for pushing boundaries way beyond the norms for academic purposes.
Please consider that you may be causing an impact on the other users around you and could potentially be impacting the normal running of the servers that we get free use of and must ensure we do not add to the already substantial costs that TTI cover.
With the resources of a university, spinning up a server to run a private instance of TTS shouldn’t be so hard.
What are you trying to achieve with your research?