Checking the logs to see if you see any traces about activation?
loraserver / lora-app-server and lora-gateway-brigde doesnt show any signs of activation
In that case, start from the origin (the packet-forwarder & LoRa Gateway Bridge): https://docs.loraserver.io/lora-gateway-bridge/install/debug/, when you see data there, one step up to LoRa Server and see what happens there in the logs.
thanks for your help, will debug this issue. It’s could be related to node’s battery.
I have one confusion in OTAA Node activation.
Consider there is OTAA node and receiving data using Brocaar LoRa sever the system which runs the Borcaar LoRa server is got rebooted. In that case,OTAA node activation need to be performed again or not.
That depends how you’ve configured your Redis database. When all data is persisted to disk (which I believe is the default), then you can reboot and no OTAA activations get lost.
On the other hand, this is easy to try out yourself
Thank you for your response.
Currently ,I am using default Redis database settings. I understand that reboot(System which runs LoRa Server) won’t affect the OTAA communication.
I am totally new to LoRa server. I’ve only recently installed the lora server onto a VM using Ubuntu.
I’m able to add my gateway in but when i tried to join my node to the server, I’m getting join failed on my node but i’m able to see the join request on my server.
Below are the screenshots taken using the mosquitto_sub command.
Please help me.
Please check your
loraserver logoutput. As you can see in your screenshot, there is only an uplink (
.../rx) in your logoutput, no downlink (
.../tx). So probably the issue is that you have provisioned your device incorrectly (e.g. wrong key).
I am not sure if this is the log output. Below is the screenshot
This are my settings
It okay, i fixed it. It is due to the frequency setting in the Lora server
Please see https://www.loraserver.io/loraserver/install/debian/ for instructions how to find the log output (Debian / Ubuntu based installations).
I am trying to activate one of my devices on loraserver.
When turning my device on I can see joinRequest being sent through the registered gateway and joinAccept being sent back. Even though the joinAccept is being sent my device does not get activated but it sends joinRequest again just to receive joinAccept again and keeps looping this way.
When I was doing OTAA over TTN under same conditions everything worked great.
What could be the reason for this?
Please make sure that the correct LoRaWAN version is selected in the device-profile, as 1.0.x and 1.1.x are not compatible. Most likely your device does not support LoRaWAN 1.1.x (as this is not yet supported by TTN).
Hey, thanks for the fast reply!
I have actually tried setting each and every possible version of LoRaWAN (just in case) in device-profile with the same result.
could you confirm? Do you use lorawan mac version 1.0.2 and regarding provisionning of appkey, the field network key must be fill with your “OTAA appkey” and the appkey field must be left blank.
I am using STM32CubeExpansion_LRWAN_V1.1.0 if you are familiar with it. After some digging I am pretty sure that the mac version in this program is 1.0.2 as you stated but I am not 100%.
And regarding the keys I have left the app key blank and network key is the actual app key.
I don’t think so, in this link https://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/i-cube-lrwan.html you can see that from I-CUBE-LWAN_V1.1.0 the lorawan mac version used is V1.0.3.
You can also find a previous link which deals about this topic ==> https://forum.loraserver.io/t/lorawan-mac-version-1-0-3/1914
In my case I’m using I-CUBE-LWAN_V1.0.x (it works with loraserver) and I notified the same behavior with I-CUBE-LWAN_V1.1.0 that is to say join-request/accept loop.
Setting the device-profile to LoRaWAN 1.0.2 or 1.0.3 should not matter for LoRa Server as the only change in behavior of LoRa Server is between 1.0.x vs 1.1.x.
Yes I understand your point of view, normally with lorawan mac V1.0.3 implementation only class B devices could encounter an issue, but something is different from the release of I-CUBE-LRWAN_V1.1, certainly we have to get closer of STMicroelectronics to go deeper.
Julien, is the example code version you are using still available to download? I can’t find it anywhere.
Also, may I PM you about something.