I am using a AU915 IMMOTION People Counter, LoRaWAN MAC 1.02 REV A and Australia 915-928 Mhz FSB 2. Since moving to Australia v3 Cluster the End Device will loop between ‘accept join-request’ then the ‘Forward join-accept message’ over and over again until the batteries are exhausted.
The End Device will then continue trying to rejoin without any success.
The same AU915 IMMOTION People Counter, LoRaWAN MAC 1.02 REV B worked without fault on the Australia v2 Cluster.
The same AU915 IMMOTION People Counter, works without fault on the SENET LoRaWAN and Loriot LoRaWAN.
The AS923 IMMOTION People Counter, LoRaWAN MAC 1.02 REV A and Asia 920-923MHz (used by TTN Australia) works without fault on the Australia v3 Cluster.
It is becoming clear that the End Device is not at fault but for some reason incompatible with Australia v3 Cluster.
Can anyone offer a suggestion on how I can get the AU915 IMMOTION People Counter, LoRaWAN MAC 1.02 REV A End Device working on the Australia v3 Cluster using the Australia 915-928 Mhz FSB 2 Frequency. The End Device developers and users have tried many times and settings with no success.
Capture the raw join accept packet being transmitted back to the node by the gateway, along with its air settings. If no join accept is being generated, there’s probably a problem with your node registration details.
Find a way (like serial debug output) to access the air settings the end device is using during receive attempts, and compare these to those used to transmit the join accept.
It is becoming clear that the End Device is not at fault
It’s quite premature to conclude that, because you are overlooking the possibility of an only partially LoRaWAN compliant configuration that works with some legal network behaviors but not with other also legal network behaviors.
That said, there’s not much variation in join accept behavior.
Also keep in mind that having a node too close to a gateway is known to result in unreliable communication due to front end overload issues.
Hi cslorabox - Thankyou so much for your advice. I’m out of the office for the next couple of days but I’ll be sure to try your tips later in the week. I was not aware that having a node too close to a Gateway is known to result in unreliable communication. Great Tip!
In V2 console, the US915, EU868 and CN470 work well. But in V3 console, US915 and EU868 work well, only CN470 encounter this issue. Does anyone provide the suggestion?
I found that some of my OTAA devices on AU915 that had been working with MAC 1.02 REV A in TTN V2 would not join in V3. The solution was to set them up as MAC 1.02 REV B in the V3 console.
Good morning,
Is there any one who could solve the mentioned problem. It made me disappointed. I see always forward join accept message. Would you please help me?
1- more or less from december 2021 we have this problem
2- I reset the devEUI and all other parameters in lorawan node
3- I tried ABP
Many thanks,
Thanks, but As @wolfp said I upgraded the firmware to the latest possible version (1.1.1 as it is a LSE01 sensor we bought it in 2020 and its main-board doesn't support version 1.1.4 as I tried it too). But problem didn't solved.
Its also possible to hold ctrl+move mouse scroll to maximize web page. I tried to do as you said, Please let me know the screenshot is visible.
The second screen shot is clearly some text that if you can’t copy & paste off the CuteCom screen, you could copy & paste out of the cutecom.log.
The primary reason for getting text formatted with </> is that we need to see the serial log for the device for the loop - neither screen shot shows any form of loop.
Looks like the module is rebooting after it received the join accept message. Have you read chapter 5.3 of the manual and implemented the mentioned fix?
