Hello,
I have noticed that my LoRa node attempts to join, an Accept is sent from the server, but subsequently no data (uplinks) come from the device, so the session between the device and server might not be valid or intact. Only after triggering the join for the 4th time, the device started sending data. Has anyone ever seen such behavior or can explain why this is happening?
Your device is somehow unable to receive the JOIN ACCEPT.
By the way, why do your JOIN ACCEPT get sent down on RX2?
I also see two JOIN REQUEST. With this pattern, I got this feeling that you disabled packet de-duplication? Why?
Hi,
thanks for your help.
Its not my own device, so i dont know, why the device is sending two Join Request at the same time on different channels.
And yes i am confused too with the Join Accept downlink on RX2. But this cant be configure from the server side. To other devices, from different manufacturer, the chirpstack answers normal to a join request on RX1, via the same uplink channel.
But do you have the packet de-duplication check enabled? To me, it looks like an echo. It may happen if the node is very close to the gateway and if the packet de-duplication feature is disabled.
If RX2 is being used, I guess that your gateway is busy and RX1 is coincidentally often in use. It’s not a good sign, but it’s another problem. I you want to dig into this, I suppose the logs may have some hint. If you’re using the classic UDP packet forwarder, the decision to use RX1/RX2 lies in Chirpstack Gateway Bridge. If you’re using something else, it may lie inside the packet forwarder itself.
You could also look at the LoRaWAN Frames logger of your gateway, to see whether it’s always busy sending downlinks.
no the packet de-duplication check is not disabled.
In this case, we are using a milesight gateway. Normally we are using tektelic, where the UDP packetforwarder from Semtech is used on the gateway. So there is no gateway bridge.
So where should i read out some logs?
Maybe the milesight gateway is the problem.
There must be a gateway bridge. You’re using the LoRa gateway in the same way I do, whereby the gateway bridge component is in your cloud.
Actually, would you want to take a look at your gateway’s LoRaWAN Frames logger first? It’s in Chirpstack’s UI, so perhaps that is easier.
Regarding the duplicates: another theory I have, is that you have multiple gateways. Or there’s only one, but it sends two messages because of an echo effect.
However, the latency is quite high, higher than the de-duplication delay. If it’s possible to ping your LNS from the gateway, what’s the latency like?
Here’s the setting and the default value. If any gateway takes more than 200ms to relay the uplink to the cloud, it’ll be counted as a separate message. I suggest making a change, only if you’ve confirmed the problem.
# Time to wait for uplink de-duplication.
#
# This is the time that ChirpStack will wait for other gateways to receive
# the same uplink frame. Please note that this value affects the
# roundtrip time. The total roundtrip time (which includes network latency)
# must be less than the (first) receive-window.
deduplication_delay="200ms"
i saw a commit, that fixes “ghost packets”
Fix concurrent handling in case of ghost OTAA packets. · brocaar/chirpstack-network-server@1b50594
We are using an older version of the network server (3.15).
Could this also describe this behavior?
I cant connect to the gateway right now, i have to do this later to check the latency.
Maybe. But wow, you are using a really old version.
yeah thats true.
So you would recommend to try this with an other Gateway, check the gateway bridge logs, check the latency and try to update the chirpstack, right?
How close is the device to the gateway? If it’s too close (meters) it’s normal to have double messages.
Which region are you is? Could it be that the device is configured single channel? I’d you in 915 AU or similar this maybe the reason for this behaviour.
If you spent a minute looking at the original question, you’d see that the frequencies align with EU868. But that immediately also reveals the problem: the device appears to be sending JoinRequests at forbidden frequencies, such as 867.1MHz. I’m not sure why at the same time Chirpstack shows a second entry at 868.1MHz (which is allowed), but your device apparently doesn’t adhere to the LoRaWAN specification.
About 3-5meters right now for testing.
How close is too close? Are there any references or approximate distances?
That’s a good point about the Join on 867.1 MHz. Is the Join on this frequency prohibited, or does it simply not conform to the default settings in the specification for a Join? If that’s the case, it could either be that a ghost packet is being generated on this frequency (unintentionally), or the manufacturer is not adhering to the specification in their firmware.
The LoRaWAN specification only allows joining on the three default frequencies. It’s not forbidden by law.
But the situation is odd given the ‘ghost’ joins - at what frequency should the network server respond? It is only allowed to send a JoinAccept for the 868.x frequencies which also appear, but always after the 867.x frequencies which are likely the ones actually used by the device, given that they appear here. And as a result your device will be listening at another frequency than the JoinAccept is transmitted at.
I guess the fix for these ghost packets will be helpful, but a bit of distance will very very likely help. The golden rule is 10 meters & a brick wall between gateway and device, or if that’s difficult an RSSI of -70 or more negative. LoRa is all about Long Range, not screaming in one another’s ear - that would be hard to understand for you as well.
1 Like
Meters and SF11 is way too close. Unless a wall is in between. Maybe this is the problem. What’s the db of both frequencies? Kind of difficult / impossible for a node to transmit two time in the same second and with SF11.
Try with a wall or / and SF7. Although it puzzles me why 1-2-3 efforts are fruitless. Also @bns has a point.
1 Like
A few months ago I have spent a couple days debugging why a device appeared to be transmitting roughly 0.5MHz higher than it was supposed to - it turned out that I had IQ inversion disabled which needed to be enabled. Apparently because the devices were too close to each other, they screamed hard enough for the other to still be able to pick up the signal but apparently appeared shifted to what it was expecting.
Key takeaway is to indeed lower the power / SF as much as possible and get some separation between the devices.
1 Like
Thank you guys so much for your help.
I will take your comments and tips into account and consider them in my tests.