I’ve got a setup where I’m using 2 gateways to cover 20 end devices within a building
I’ve had one gateway up and running with more than half the end devices connected to it and all has been working fine.
I’ve added the second gateway to add the rest of my end devices but have seen issues with downlinks.
The gateways are located at opposite sides of the building but they do overlap in the middle with some end devices being in range of both.
It’s the end devices in this overlapping zone that I’m seeing the downlinks being dropped.
It’s worth noting that the overlap zone of end devices also have trouble joining with multiple join attempts usually occurring, with the worst case being an end device trying to join for around 20 mins.
I’m using two Tektelic Kona Iot micro gateways in EU 868MHz and both using frequency plan “Europe 863-870 MHz (SF9 for Rx2 - recommended)” on TTN for the gateways and the end devices.
I’ve moved the gateways around to limit this overlap zone but there will always be a few devices caught in the middle.
If it was in the US915 region I would have tried putting the gateways on different sub bands but I don’t think that can be done on EU.
Thanks for the quick reply.
I’m limited by the infrastructure of the building so putting one in the middle isn’t an option as i don’t have the power and data available. I do feel that a couple would be slightly out of range even if this were possible.
an example of one of my overlapping devices
RSSI -101db to gateway 1
RSSI -110db to gateway 2
SNR value 37
a second overlapping device
RSSI -81db to gateway 1
RSSI -115db to gateway 2
SNR value 34
downlinks are getting scheduled in TTN consistently no drops on that end
live data feed for the end device shows this and on the live data feed for the gateway.
How common are the downlinks (should be used sparingly), if using SF9 for uplinks and (recommended) SF9 for downlinks then you may see bursts of heavy traffic all on the same SF throwing away one of the points of resiliance of LoRa modulation wrt various SF’s being considered pseudo-orthogonal to each other reducing co intereference and allowing better signal resiliance and recovery even where in same channel. If respective signals >~20-22db different may be starting to see near/far related issues, even in such a small volume space (use of random/optimised SF under say ADR control to be preferred where possible). Also can you track the GW selection for DL’s such that you can see the expected GW being chosen to handle this for any given node? If anything the nodes on the ‘middle/overlap’ area should be better off as they effectively have a redundant path, so issues like e.g. GW duty cycle issues should be partially mitigated improving device support.
Downlinks are used when end devices are powered on to configure them. Once powered on devices will not receive downlinks again until a reboot. Configurations can’t be saved to my end devices so this downlink send on device join is my work around. Devices are being installed so as a result I’m seeing more downlink traffic than will actually be the case once finished. It’s not a case that I’m testing by booting on 10 devices on at the same time I’m seeing the issue as I install 1 at a time. For testing I’m manually sending them from TTN console with similar behaviour in the dropped downlinks.
I have implemented SF12 for my Rx2 window and have set ADR on with different margins 25, 15 and 5. I can see the uplink traffic has generally chosen an SF that isn’t 12 but this hasn’t made a noticeable difference. Downlinks look to be getting scheduled and transmitted consistently from the nearest gateway that I’d expect to be used.
So the confirmation uplink has only been enabled to help with identifying dropped downlinks. It’ll be disabled again once I’ve found a solution which should hopefully bring me back within FUP?
gateways would be close to 75m/100m apart.
Between each of the gateways would be at 4 walls of concrete likely metal within
Seems a bit meta - “I’m losing downlinks so I’ll make more downlinks happen all the time”. And in the context of the FUP, “Hello Officer, I just wanted to test if I could break the speed limit every time I drive”.
A single device that you are manually sending downlinks from would probably suffice and allow you to process the data - rather than the semi-random blizzard as @Johan_Scheepers refers to above.
If it’s 100m between them, you only need ~33m to run a PoE cable to the middle two rooms to situate a gateway per room.
When we ask what are these devices, we mean make & model - as then higher minds (mostly @Jeff-UK) can comment on the antenna on it.
I have installed up to 10 gateways in building complexes that overlap several times, but have never had any problems with them. And if the first gateway is unplugged, do the other sensors work with the other gateway? This way you could see if that is really the problem.
Yeah when i revert to one gateway I am seeing a big improvement. I’ve created a similar setup with two gateways for testing in our office and to your point I don’t see any issues so its weird.
I have swapped out both my gateways on site too incase of a fault but issue has remained. Have you ever had any interference issues in you’re building complexes that I might not be considering @TobiasAlora? wifi APs, wireless mics… etc?
Yeah worth a shot looks like I’ve got a latency of 90ms on my working test setup. I’ll compare this when I’m next on site to see if I’ve a large discrepancy.
Officer, I just wanted to test if I could break the speed limit every time I drive”.