LoRaWan Gateway issue (not connected status). Where are RF packets forwarded?

[mbruj]

Hello All,

I have built my LoRaWan gateway as per instruction From zero to LoRaWAN in a weekend

The gateway works perfectly fine. The issue that I have discovered over the time is that I cannot see my gateway connected in The Things Network (TTN) console. The status says "not connected"

Additionally, I bought two makerfabs LoRa sensors and I programmed them using this instruction: https://www.makerfabs.com/wiki/index.php?title=Lora_Soil_Moisture_Sensor

I used LoraTransmitterADCAHT10.ino code to program them. (I am not sure whether this step is correct)

Now, when I look at the screen from my raspberry Pi that is used for my gateway I am receiving following information:

... # RF packets received by concentrator: 4 ... # CRC_OK: 42.86%, CRC_FAIL: 57.14%, NO_CRC: 0.00% ... # RF packets forwarded: 3 (36 bytes) ... # PUSH_DATA datagrams sent: 4 (906 bytes) ... # PUSH_DATA acknowledged: 0.00%

I can clearly see that something is sent to the gateway, approved and forwarded. The problem that I have is that I have no idea where this data is?

Is there anyone who would be able to tell me where I can find it?

Also, can you explain me what "PUSH_DATA acknowledged" is an why in my case it is 0%. Maybe that's the problem?

When I go to my gateway traffic tab I can see just empty table.

Thank you

[CongducPham]

Hi, looks like you are using another LoRa framework, not the one on this github. However, for TTN you may check whether the gateway id matches on your TTN console, whether you defined TTN as your network server in global_conf.json,...

regards,

[mbruj]

Hi, looks like you are using another LoRa framework, not the one on this github. However, for TTN you may check whether the gateway id matches on your TTN console, whether you defined TTN as your network server in global_conf.json,...

regards,

Thank you for your response.

The gateway ID matches the .json file that was approved when I was verifying the gateway. It is also the same as EUI number I can see when I turn on my gateway.

I am not really sure what do you mean by "whether you defined TTN as your network server in global_conf.json". Would you be able to tell me more about it?

Thanks

[CongducPham]

either in global_conf.json or in local_conf.json you need to have

"server_address": "router.eu.thethings.network", "serv_port_up": 1700, "serv_port_down": 1700,

but if you followed instructions from "From zero to LoRaWAN in a weekend" then it is surely already set, but you may check. Otherwise, right now, I don't see why you don't see your gw on TTN.

regards,

[mbruj]

either in global_conf.json or in local_conf.json you need to have

"server_address": "router.eu.thethings.network", "serv_port_up": 1700, "serv_port_down": 1700,

but if you followed instructions from "From zero to LoRaWAN in a weekend" then it is surely already set, but you may check. Otherwise, right now, I don't see why you don't see your gw on TTN.

regards,

Yeah, this is exactly what I have:

... { "server_address": "router.eu.thethings.network", "serv_port_up": 1700, "serv_port_down": 1700, "serv_enabled": true } ...

I though that it will appear as connected and traffic will show up after couple of days. It's been two weeks now and nothing has changed since then.

Thanks for your help anyway. I will keep searching, but hopefully someone else will be able to help.

Cheers

[CongducPham]

For the gateway, I don't know why it is reported as not connected. For the data from your devices, did you created an app on TTN, and registered your devices?

[mbruj]

For the gateway, I don't know why it is reported as not connected. For the data from your devices, did you created an app on TTN, and registered your devices?

When it comes to "not connected" status in the TTN console I already read somewhere that it is known issue and it will not be fixed in V2. There is more people having this issue https://github.com/ttn-zh/ic880a-gateway/issues/74

I also got confirmation from @gonzalocasas that this status is not very reliable at the moment. Therefore, do not put too much attention to that.

Yes, I did create an application as well. I followed the YouTube tutorial how to register application on TTN console (minute 7:18 - 10:43).

I have to admit that this shows me an error when I click "Serial Monitor" in Arduino IDE.

Now, when I think about it, it looks like this is where I am doing it wrong. I am programming the sensor incorrectly. What do you think? Looks like with previous program is sending data but, do not tell the gateway where to send to.

In my understanding all LoRa sensors should be working with this gateway?

[mbruj]

Just FYI I am uploading the full outcome from the gateway.

I highlighted things I do not understand.

... ##### 2021-03-05 09:48:53 GMT ##### ... ### [UPSTREAM] ### ... # RF packets received by concentrator: 7 ... # CRC_OK: 14.29%, CRC_FAIL: 85.71%, NO_CRC: 0.00% ... # RF packets forwarded: 1 (52 bytes) ... # PUSH_DATA datagrams sent: 2 (506 bytes) ... # PUSH_DATA acknowledged: 0.00% <------------ Does it sound right? ... ### [DOWNSTREAM] ### ... # PULL_DATA sent: 3 (0.00% acknowledged) <------------ ... # PULL_RESP(onse) datagrams received: 0 (0 bytes) <------------ ... # RF packets sent to concentrator: 0 (0 bytes) <------------ ... # TX errors: 0 ... ### [GPS] ### ... # Invalid gps time reference (age: 1614937733 sec) ... # Manual GPS coordinates: latitude 10.00000, longitude 20.00000, altitude -1 m <------------ My coordinates are different ... ##### END #####

Here is the screenshot of data I am receiving from sensor.

To me it looks like the gateway is receiving the data, but it is not sending to TTN console.

[CongducPham]

From the serial monitor, i don't know if the transmission is correct or not because of the 'no reply' message. I'm not sure where it comes from because I would be surprised if it expect an ack from the gateway. Maybe it is only local 'rfm95_server' in which case maybe there is no transmission at all.

For the gateway, maybe it catches packets from other devices that are not yours. The proportion of CRC_FAIL is quite high so the probability that it is other packets from far devices is quite high.

You need to make sure that your device is transmitting correctly.