I have two gateways (mile sight UG67 gateway) . Gateway A will communicate with all the nodes but there i will not have any network connectivity.e.g wifi , ethernet etc … Gateway B will be placed near our datacenter . now i want to know if its possible to establish communication between these two gateways so Gateway A send data to Gateway B and then from Gateway B i can use that data . its sort of repeater function which we do with wifi routers.
Nope. Can’t be done. LoRaWAN gateways require internet connectivity. Either ethernet or cellular.
There have been multiple discussions regarding LoRaWAN repeaters on the forum, use search. However the answer is still ‘can’t be done’.
1 Like
thanks for replying man.
then what to do about such use cases ? if you know any helpful article or discussion on this form please guide
As has been mentioned the Gateway needs Internet connectivity to forward messages into TTN.
The question therefore is more one of how you provide that Internet connectivity.
sir i am not worried about forwading messages to ttn . my concern is how to establish between two gateways …so one receive data from nodes and then send it to other gateway over lora protocol instead of cellular, wifi or ethernet connectivity… from second gateway i will have internet connectivity .
sir i am not worried about forwading messages to ttn . my concern is how to establish between two gateways …so one receive data from nodes and then send it to other gateway over lora protocol instead of cellular, wifi or ethernet connectivity… from second gateway i will have internet connectivity .
You can’t.
The first person to answer you wrote the software many of us use to run our gateways.
The second has built & deployed a satellite.
So even if you don’t believe them, believe me, there is no mechanism to relay packets from gateway to gateway that will work in any manner that will work - it was never designed for it.
So look at GSM/LTE options or another location for the gateway that has no backhaul.
Also, please consider using the Edit tool which is next to the Delete tool rather than duplicating posts.
Also so that Gateways dont end up chatting to each other wasting valuable resourses, air time and backhaul capacity, during normal operations (when downlinking from one gw to a node that could look like an uplink to another gw) they actually have an inbuilt mechanism to specifically stop them talking to each other! Or atleast to allow them to recognise another GW and then totally ignore the signal (down chirp vs up chirp IIRC) and if you do not know what that refers to then as Nick says you really do not know enough to be doubting all the previous posters. Plans for node to node repeaters have been discussed for years and still havent materialised…gateways would be an order of magnitude harder again.
TL:DR
Without even considering the techincal aspects just assume that you are not the first person in the World to want to do this and it does come up on the forum fairly often.
Therefore why do you think that no-one on the forum can offer a solution ?
If there was a solution you might expect someone on the TTN forum to know about it, or alternativly you could find it via a Google search.
To address the specific comment about using UHF LoRa as some form of relay then a Gateway somehow using that to talk to another Gateway would very quickly exceed legal duty cycle limits.
Its possible that 2.4Ghz LoRa might just be fast enough to act as a radio bridge for a handful of km. Whilst the 2.4Ghz bands dont normally have duty cycle limits, its a heavily used band, so using it for a reliable radio bridge would be a challenge, even if it were possible to re-invent the established TTN\LoRaWAN gateway code.
- Provide internet connectivity at the first gateway
- Use satellite LoRaWAN and forget about those two gateways
- Use a different technology, LoRaWAN won’t work the way you want it to.
1 Like
In that case point to point WiFi with proper directional antennas to provide internet might work as well and be a far better solution.
1 Like
Well, maybe.
But WiFi is normally very short range and to extend it you would need high gain antennas and\or high power levels. Lots of issues with legal ERP limits then. Hence why I mentioned 2.4Ghz LoRa, its maybe on the edge of providing enough speed\distance and being legal.
no no i am not doubting their expertise .i am sorry if my reply reflected that.i am sure they quite capable thats why they are helping others. I thought may be i was unable to explain the requirement so thats why i explain it again.
and sorry for duplicating post … next time i will not make this mistake… first post so bear with me .
The same questions come up time & time again, we know the patterns …
Then the question is off-topic for the TTN forum.
What radio schemes could be used to backhaul a gateway depend heavily on the details of the particular location (are there commercial services such as LTE available, is there line of sight for a directional antenna link, etc), the regulatory regime in which it will have to operate, and the nature of the network being supported.
For TTN, which is what is on topic here, this hasn’t really been seen as a practical project, with the unique exception of experimental gateways on orbiting satellites - you can look into the details of what’s been done, but I don’t think they provide support for ordinary TTN nodes also supported by the network of conventional terrestrial gateways, as there are some unique architecture challenges to having gateways of distinct reporting lag and “cost to use” in a network that presently doesn’t really have a mode for gateway characteristics.
The more the backhaul radio scheme looks like the LoRa modulation radio signals carrying LoRaWAN-protocol traffic arriving at the gateway itself, the trickier deconfliction and timing are going to be - using a distinct radio for the backhaul and things like using a different frequency sub-band which can be blocked by a filter, using a wider bandwidth and faster SF, and physically displacing the backhaul antenna some distance away (and even ideally on the other side of the mountain peak) would help a lot.
If someone had a geographic area they wanted to cover on behalf of TTN and could only do so by such means, then the full details of the situation might lead to an interesting conversation.
But engineering solutions to a unique private network problem isn’t really on topic here.