Hi
I am using :
1.Latest version of loraserver 2. latest version of lora-app-server 3. Laird RG186 (EU 868) running Semtech forwarder 4. Device running LoraWAN MAC ver1.0.1
After configuration setup of Org, Service, Gateway, Application and Device, when I power up my device, the join request and accept works fine (the activation tab shows the data) followed by one uplink and one downlink. And then there is no activity. The device is supposed to be sending data every 30 sec. This device works fine with my Laird GW (preset for TTN) and TTN with OTAA - I see data every 30 sec. But that is not the case with LoRaServer. Can anyone help me please?
Further I also observed on gateway that when I connect to TTN, the traffic shows me records for every 30 sec. But when I use LoRaServer, there are only join request, accept followed by uplink and downlink, and not activity there after. it seems my device goes to sleep?? which is weird.
I have also set up InfluxDB and its integration, and that works fine, I see only 1 record posted in mydata table, and no more records…
I’m in the US so this may not apply to you but when I had issues like the ones you’re describing it was because loraserver was set up for different channels than the gateway I was using. The join process is spread across all channels but when it gets a downlink from the first data uplink that tells the device which channels to stick to, then data is sent on a frequency the gateway is not receiving.
Again I know the specifics of channels/subnets is different in the EU but that’s what has happened with me in the past
Is there any possibility that you can check the selected data rate in your node, after receiving the downlink? It is possible that the Downlink message includes a mac command to change the Data Rate to be used in subsequent transmissions and its disabled in your node. By default; at least in version 2.4, ADR is set globally for the server. If you are not aware of it, it is used to determine if the current DR is to “loud”, so the server manages it and tells the device to “lower its voice”. This is a wild guess, but could help your troubleshooting. Take a look at the Live LoRaWAN frames tab/logs.
Hi @Safrone
Thanks for your reply and information! I have updated the loraserver.toml with enabled channels and extra channels (5 of them). And I found that the channels and BW info on my Laird 186 (for EU868) matches exactly the channels and BW defined on this page of TTN - click here. And the loraserver.toml also configured the same way. Also Laird document says that gateway supports LoraWAN MAc 1.0.0. I also tried that value but I still see the same behavior - only join/accept/uplink/downlink - and then no more dataframes. For command “journalctl -u loraserver -f -n 100”, shows the following image when restarting the node
Hi @berkut3000
Thanks for your reply and clues!
All four data exchanges happen using coderate:“4/5” - that is what he frames under LiveLorawanFrames show. After the JoinRequest and JoinAccept follows the UnconfirmedDataUp and UnconfirmedDataDown.
I have attached the image for DataDown frame with this:
Let me know if I should look for any other info…
@berkut3000
further I found that code running on my node has LoraMac.h implements - LoRaWAN Specification V1.0.1 chapter 5, table 4
And also found that I have not updated the typedef - uDrRange which defines the min and max values for DR - which has min : 4 and max : 4 - - refer to code line 197 of this link on github - click here
But the same code works just fine with TTN, and it has never missed any frame at all. May be my node is stationary and close to my gateway and it does not need to change the DR. Not sure if I really need to redefine min and max and flash that code into my node.
let me know if you think of any more clues.
Unless defined otherwise, LoRaServer enforces ADR by default, so it may be different with TTN. I say this because in my nodes, I always set DR0 (US915, RN903) before transmitting a confirmed message.
Hi @berkut3000
just to make sure, I set up the gw to connect to TTN and then restarted the node, I have attached the screen shots for traffic on the gw and traffic on the TTN, the node is configured to send data every 30sec, following are the snapshots:
we see something that is expected for TTN : TTN uses non-standard SF9BW125 for RX2 on channel 868.525Mhz and other DataUp and DataDown lines.
Going back to configuring Semtech forwarder on Laird and connecting to Lora-gateway-bridge:
I regenerated the lora-gateway-bridge.toml and trying restarting the node, I still see the same behavior of JoinRequest/JoinAccept/UnconfirmedDataUp/unconfirmedDataDown cycle and then nothing happens, the node seems to be lost in the loop…
I have now downgraded to LoraServer V2.8.2, Lora-App-Server V2.6.1 and Lora-Gateway-Bridge V2.7.1 and now using MQTT forwarder on Laird RG186 gateway
Well I still see the same behavior, JoinRequest/JoinAccept/UnconfirmedDataUp/UnconfirmedDataDown
And no further activity, no further data coming from node…
I have attached snapshot of when I run this command - mosquitto_sub -v -t “gateway/#” after restarting the node. And then I just see repeating gateway/xxxx/stats and gateway/xxx/config commands
Can someone help me debug / resolve this … .
Thank you all for your help!
Well I have tried to contact Laird support, but not sure if that is the issue here, tried both MQTT forwarder and Semtech forwarder with LoraServer V2.8 but still the same behavior.
And further I have just ordered LoRaGo Port from Sandbox and will try installing the Lora gateway OS base and see how it goes.
Hello
To see if we receive device data.
Isnt it in “Application -> a device -> device data”?
And that data is in Base64, and we must to parse it to hex and/or decrypt it if necessary.
It is not the data issue. My node is configured for OTAA, after the node restarted, I see this sequence of events: JoinRequest/JoinAccept/DataUp/DataDown - the device is activated, but then the node stops sending the data - which is actually configured to send data every 30 sec. My node behaves just as expected with TTN.
I actually did some more findings: I have attached the snapshot below.
Can anyone help me debug this?
I think after the activation, “ADR Request” is sent to the device to set DR >> req_dr=6 which my node is not able to set??
what is “pending mac-command block set” ??
After the above data exchange, the node goes quiet and then there are only gateway stats packets
Does that mean my node is not able to set DR=6?
Can I try setting “disable_adr = true” which will only use constant DR value?
Hi @User123
My node is sitting some 6m away from the gateway, and I tried putting it further away but that does not help, I still see the same behavior.
Anyone can comment on : what is “pending mac-command block set” ? also about the ADR request? I will try to run my node in debug mode, and find out what is happening.
I received LoRaGo Port from Sandbox. Installing and running LoRa gateway OS base was really straight forward. It connected fine with my LoraServer running on my Ubuntu cloud server.
But unfortunately I see still the same behavior - just JoinRequest/JoinAccept/Uplink/Downlink - and the node goes to sleep. I had thought that there something wrong my Laird gateway. But using the LoRaGo Port gateway I get same results. This is really so frustrating
Hi Silas,
I have exactly the same problem. Activation, first uplink and first downlink message are received. After that nothing more… I work with the Dragino starter kit. Maybe we can fix it together
Welcome to this community!!
Would you please let us know what is your set up? What LoRa node / LoraServer version etc are you using? Is that node functioning as expected with TTN? Can you please post some snapshots from LoraServer when you run command ->
journalctl -u loraserver -f -n 50
So I tried reflashing code in my LoRa node with ADR=false and also left the node and Laird gateway turned off for almost 24 hours. And then I restarted the gateway and node, to my big surprise the node is working as expected!!! It is continuously sending data to gateway and the data going to LoRaserver.
as expected… see the image attached
Although the LoRaserver.toml has disable_adr = false, since the device has been configured as adr=false, for all the uplink I see as adr=false (see the image).
There is another surprising thing - I don’t see any unconfirmed downlink as was in previous which was requesting to set the adr. I am not sure why that is not there, can anyone help?
