I am new in Lora and Lorawan application. I have some nodes and a Gateway communicating over TTN network. I’m using OTAA and all my nodes are connecting to my Gateway easily. But when a neighbour switch on his TTN gateway happens that some of my nodes joins with that Gateway instead of mine. In this way they use a Spread Factor higher due to the higher distance, growing up consumption.
There is a way to force the communication to a precise Gateway using Lorawan protocol? Maybe changing to ABP?
There is a way to lock Spread Factor on a node to low level or is all in the hands of Lorawan protocol?
In wich way the Lorawan node select a Gateway instead of another?
Devices don’t connect to gateways, they connect to networks. The gateway takes radio signals and passes them on, there is no mechanism for a device to say “I only want to talk to X”.
Your devices shouldn’t be rejoining - OTAA is meant to be a one time thing and then the device either stores the join details or never gets turned off.
ABP will resolve this somewhat because you can fix the SF which will sort out the power consumption problem but you’ll have to figure out which devices need to be set to which SF as clearly there is something happening in your neighbourhood with regards to reception.
It’s not all clear for me. If the end-node connection is to a network server, so it can change gateway at any time without a rejoin session? Or the packets are always sent in broadcast and all gateways reached by the signal will repeat it to the network server defined by the key inside the packet?
The communication problem could be related to the short distance between node and gateway(lower than 1meter)? In that case the two antennas have problem into communication, so, the end-node could decide to grow SF and reach the neighbour gateway?
Ouch! Yes, very probably - you’ll be SHOUTING so loudly that I doubt a signal could get through. Opinions vary but 5 to 10 to 20m is the sort of minimum, or a brick wall.
Send OTAA Join command to GW ( if I don’t, it’s unwilling to send, says its not joined )
Send Payload.
Repeat step 1.
The above works.
Question :
Should I not send the OTAA request when power is applied? If I don’t, then it won’t send. Says its not joined to a network.
I’m running my own gateway, the gateway forward packet to private server.
I see when I switch off my GW, then the device sends a Join request and some other GW accepts…so my message is lost, cause that (random) GW can’t forward to my private server. Should I not send a JOIN message at every startup? Or how does one prevent this behavior?
You device should not do this, re-join, the packet should just flow via the other gateway to the NS.
Are your gateway and ‘that gateway’ both on TTN? If yes the packet will be forwarded via your integration (webhook or MQTT) on your application to the same endpoint, irrespective of the gateway in between.
Yes it will be, lora is not wi-fi, so the separation needs to be some distance or obstacles that absorber RF. Your RSSI can be fairly low and the SF will still be 7, as long as the SNR is good. I say 5-10m with a brick wall is normally sufficient.
You can do this if you are sure it will work at a certain SF, but MAC are suppose to set you device to function at its optimum SF and TX power.
<Are your gateway and ‘that gateway’ both on TTN? If yes the packet will be forwarded via your integration (webhook or MQTT) on your application to the same endpoint, irrespective of the gateway in between.>
My gateway and the ‘other’ gateway are not both on TTN. So the things is that the other gateway accepts my device ( because of the join request ) and then the payload never goes to TTN…but rather into a blackhole!
How does one prevent this when there are non TTN gateways around?
That wont happen - unless you have registered your device on the network associated with ‘that other gateway’ - it will simply drop any packets it hears (or rather that GW’s associated LNS will.) Have you registered your device in TTN?
Is there not another step between 3 & 4 - wait for and procees join accept! Then send payload!
Actually no it is not - OTAA is preferred - better managed by LNS and more secure…and…and… ABP good in some circumstances and where you are running tests and find OTAA isnt working - as a check to see if you can send data to the LNS and through to your device/application console.
You should not do repeat OTAA - ideally a node will do that once in its life! Ok maybe after battery swaps etc. You do not tell us what your node is? Sounds like when you put it to sleep it is loosing its network credentials - forcing a rejoin. You need to store before deep sleep or use a lower setting for standaby/sleep than any that loose your state - which MCU? Some are notrious on the Forum for not playing nicely with sleep - Search is your friend…
your device should save state. That means the keys and address received at join and the counters and other LoRaWAN settings (transmission power etc). If you don’t and rejoin every uplink you burn through your 64k nonces and at that point the device can’t join anymore. Also you are transmitting and receiving twice where once is sufficient so using power twice.
Gateways are subject to airtime restrictions in large parts of the world. When you have multiple nodes that require join responses in a short period this will fail because the gateway can’t transmit the response. This happens regularly at workshops with 10 people so will happen in real life as well.
other gateways do not ‘accept’ anything. Gateways forward all packets (joins and uplinks) to the network server which processes the packets and creates return packets if required. So another gateway can receive the transmission but if it does not forward the data to your private server no reply can be created because other servers will not have the required AppKey to validate the join.
Please use the documentation to get a better understanding of LoRaWAN, what you are asking is related to the basics.