I do know the answer. It can’t so it won’t. It will send the response to gateway1 which will not forward it and as a result the node will never get the data. TTN does not implement the notion of receive only gateways with a sending partner. (Yet, they may well accept patches for V3 implementing this, but discuss first before spending a lot of time on creating patches)
BTW, if gateway2 can’t receive data from a node, chances its transmissions get to that node are near zero. So for this use case I wouldn’t bother to even look into modifying the stack.
I agree. So idea number 2) seems not to be the solution.
Lets go to idea number 1): power-reduction (EU868).
One problem we have (in EU) is the limitation of ERP. Assuming an antenna-gain of 12dBd the gateway is not allowed to output more then 2dBm (I ignore the loss of cable and plugs). Then we reach the ERP-limit of 14dBm for g/g1 sub band (8 LoRaWAN-channels). But there is one channel we are allowed to use an ERP of 27dBm - 869.525 MHz in g3-sub band (RX2-downlink window).
What about reducing the TX-power of the gateway to 2dBm in g/g1 (8 LoRaWAN-channels) and using 15dBm for g3 (RX2-downlink)?
That would give us more then 10dB more sensitivity for the receiver of the gateway without exeeding the legal ERP-limits. Additionally we have 13dB more ERP in RX2-window. A nearly perfect balance.
I dont see the restriction of ERP as a problem really as its there for a good reason. There is limited bandwidth available in the RF spectrum for this type of application, so to allow for widespread use or sharing of this limited bandwidth its important to keep power levels down, specifically to restrict the coverage to relativly small geographical cells.
Increase the power level from say 14dBm to an effective 27dBm, the range increases by a factor of 4 and that in turn increases the size of the coverage cell by 16 and the possibility of interference (i.e.another gateway in the same area) also by a factor of 16. Now the RX2 is only a single channel and given the extra range you might expect it to be a popular choice, increasing the chance of interference further.
To use RX2 in this way you would also have to change the LoRaWAN standard (This was mentioned earlier in the thread) and the firmaware used by nodes and Gateways.
If your gateway has an output-power of +27dBm the max. antenna gain allowed is 0dBd or 2.15dBi in sub-band g3. It does not matter whether the antenna is directional or omnidirectional.
So what would I gain if I use gateway output of 4dBm with a 23dBm Yagi in stead of gateway output of 27dBm with 0dBm omnidirectional antenna? Because that was option 1 you suggested, to reduce the power output to be able to use the Yagi antenna.
In my book you loose coverage in all directions except where the Yagi is pointing and do not gain any signal strength in that direction, so effectively you are worse off because you reduce coverage in stead of increasing it. Or am I overlooking something?
But the yagi is also collecting more general noise as well.
As for the practical effects of multipath type interference on LoRa , well that would require testing for I think I myself would not assume there is an advantage here, without real World testing results. Do you have any ?
The noise level, seen by the receiver, seems relativly constant in my experience as in the recever is seeing general background noise with probably widespread particular geographical sources. So in a city for instance where you point a directional antenna may make no difference to the level of noise seen.
Easy test to carry out, if you had access to the great outdoors, my guess is that there will be little to no difference.
In any case you would be implementing a Gateway with very restricted coverage.
Thank you guys for all your helpful comments! I will stay with a standard gateway but it’s important that questions like mine can be discussed here in a ‘liberal’ fashion :)…I am not intending to break any regulations, that’s why I was reaching out for your help!
Why is that important? And why more important than us spending time answering questions from other users? Because that is the choice you are making by requesting our response.
However when posts are made that have ‘suggestions’ that are illegal or contrary to the LoRaWAN standard, then the issues will and should be highlighted.
I am surprised that some of the ‘suggestions’ have been allowed to remain, its easy for a casual reader to get the wrong idea as to what is not permitted in a casual read of threads such as this.
Generally, of course. Unless you actually want to receive packets from far away such as in the case of LoRa enabled life jackets or other critical devices used at sea.
Like this one of mine, proudly pointing out over the Irish Sea.
Understanding the use case before dismissing someone’s question and falling back on TFU docs really doesn’t help.
No-one has a network just to have a network, they have one because they want to do something with it.
Abrasive comments don’t help the community, they only serve to divide it and we work much better when we seek to understand the other viewpoints.
TTN is a community of tens of thousands and has grown because what of what it enables and supports.
How the community decides to use its own gateways whilst obviously complying with local regulations and TTN guidelines is down to them is it not? It’s all LoRaWAN btw.
Why send a HAB up to break the world record if not to celebrate the technology’s potential.
The LoRa life jacket concept is still in development but thank you for the keen interest. Getting a SFx message out from a device of a user in peril or a submerged container / obstruction to shipping is possibly more compelling than LoRa enabled mousetrap traffic.
My point is to apply some context and to try and avoid being abrupt and preachy. It seems like you’re also saying don’t put your gateways up high incase it becomes reachable.
SRDs is not what Nicolas had in mind when he authored LoRa or am I.missing something?
I am fully aware to which community this forum connects but thanks for the reminder.
Saving lives at sea using LoRa technology is certainly a very worthy use case. However please keep in mind TTN community network is not the right platform for life critical services. If you search the forum you will find messages by TTN core team members providing that statement.
TTN community network has no SLA and over the last year suffered several outages lasting hours to days. Not a technology to use when lives depend on reliability.
That is right. And other people using the network (rightfully) assume a gateway that receives transmissions of their nodes will be able to send data to them as well. Creating an asymmetric setup voids that and may lead to a lot of hair pulling as to why things don’t work as expected. So while it may serve your use case, it might hurt someone else’s.
