@Dragon_Fly Sure thanks a lot. In this link it has been clearly given about the loraserver.toml file.
https://www.loraserver.io/guides/debian-ubuntu/.
Currently am getting this information in the (app server)Gateway tab. But still i am unable to view the last seen in the Applications/devices tab. I have a LoRaWAN GPS tracker turned on right now
Have you registered the devices to your application as OTAA? Your devices send join requests so you need to register them to your application as OTAA enabled devices.
I have enabled OTAA option but still i still get the response as join request. In the above image “f8af24ffff30ea78” is the GPS tracker i have currently turned on. But in devices tab the last seen of this device is still n/a.
Try journalctl -u loraserver -f -n 50
and
journalctl -u lora-app-server -f -n 50
Observe the results from both terminal views and try to figure out why the join requests are rejected.
In the Lora web interface I have been asked to select the LoRaWAN MAC version when creating device profiles . Is there a way to find the MAC version?
Also once device has been added, i have been getting log in the lora server sayin invalid data-rate. Can you tell me where to change this setting?
Please check the answer above. If you have the MCU code of the endnode than it may be clearly understood from LoRaMac.c inside MAC layer.
I think you should do the extra channel configuration for your endnode. Please check loraserver.toml, and also from your Appserver’s UI check Gateway-profiles section, if needed you may configure the extra channels for your gateway as well.
Thanks. As you suggested i sorted that out. But still the device isn’t activated. Can you please help me out with this setup? Please find the below image for your reference.
@Dragon_Fly Hi. I run the same setup today and was able to get some up link data in the Gateway LoRaWAN frames.
After this what should be expected from the end device? Also when will the JoinRequest comes from the end device…
Good to see you activated them, well the rest is about the capabilities of your device. For instance I have some metering motes that try to rejoin the network every 2 days. They perform some actions with some defined commands inside them (Clear alerts/open close valve etc). For your case you need to know all features of your device and work on it’s features I guess. My devices send OTAA join network requests when I show them a specific card or within each 2 days period.
The Join Request is very random and it doesn’t come from the devices at regular interval. For instance if i turn on the device it takes about 20 to 30 minutes to get the join request and sometimes within few minutes. Is it like that or is there some kind of configuration?
Also the time interval between two join requests is also very random.
As far as I know join request depends only on the mote itself. We operate OTAA that way on the field. Join request can be sent by the MCU code itself whever needed. If the MCU already received NSK - APP Key’s than it may choose not to re-register itself even though you reset the device. But I need to underline, my knowledge is quite limited about LoRa.
By the way I now realize that your device is probably being rejected, that’s why it keeps sending join request again and again. I think you should observe the logs carefully by journalctl :
journalctl -u loraserver -f -n 50
If it is rejected, would message still be “JoinAccept”? How do I know if it is an accept or reject?
I have same issue with accept-loop.
In log I don’t find indication of reject.
I think we need Brocaar’s help here. I don’t use loraserver.io for OTAA.
Another server that I use accepts the join requests (Keys are correctly preconfigured) and it’s done, I don’t get re-join messages after activation.
But here the process may be different, sorry. These may help?
https://www.loraserver.io/loraserver/features/activation/
https://www.loraserver.io/loraserver/features/rejoin/
Hi Anudeep_Karunakaran,
In the past, I had a similar problem with such a behaviour.
In my case, the gateway transmitted the Join Accept message, but the node dropped it. The reason was that the spreading factor of the receive windows haven’t match the spreading factor of the message.
Maybe you have the same problem.
BR DeHi
Today I got ConfirmedDataup from the device and when i checked the server log file i got the below error
level=error msg=“processing uplink frame error” data_base64=“gOZN1wCAPioIO7tspxU=” error=“get device-session error: device-session does not exist or invalid fcnt or mic”
I looked into this issue in forum and enabled the disable frame counters and LoRAWAN MAC version but still it persists.Also when will the device send ConfirmedDataup.
