OTAA - works fine, but no more data coming from device

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…

Any clue or pointer?
Thanks

Anyone ? help me out please…
Thanks

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

2 Likes

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


Let me know if you see anything !
Thanks

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:

OTAA_Err2

Let me know if I should look for any other info…

Thanks for your help!

@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.

Thanks for your help!!

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…

Can anyone help me debug …

Thank you so much!

Hello All

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.

Thanks

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.


I am right?

Hi

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?

  1. 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??
  2. 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?

Thanks

I had a device that do join and sent me datas.
Next day, when i put Laird on, no more datas received.
(i was testing distance and other gateways)

Some hours more later searching and checking everything.
I put the Laird gateway (It was 1 about meter) more far and i receive data again.