1 gateway: raspberry pi 3 with IMST iC880A(connected)
2 devices
Arduino Mega 2560 with Dragino LoRa/GPS shield (Quectel L80)
Arduino Mega 2560 with Dragino LoRa shield (DHT11)
both are joined the network (OTAA)
with the command sudo systemctl status ttn-gateway
● ttn-gateway.service - The Things Network Gateway
Loaded: loaded (/lib/systemd/system/ttn-gateway.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2019-03-25 09:54:17 CET; 2h 52min ago
Main PID: 9778 (start.sh)
CGroup: /system.slice/ttn-gateway.service
├─9778 /bin/bash /opt/ttn-gateway/bin/start.sh
└─9801 ./poly_pkt_fwd
…….
I change in the file /opt/ttn-gateway/bin/global_conf.json the parameters
/* forward only valid packets */
“forward_crc_valid”: true,
“forward_crc_error”: false, with true
“forward_crc_disabled”: false, with true
restart the service
sudo systemctl restart tt-gateway.service
and with the command
sudo systemctl status ttn-gateway
….
That’s quite close to me, for Long Range LoRa radio. So, what if you increase that, a lot? Like 10 meters or more?
And are you sure the CRC errors are related to transmissions from your devices? (Rather than some other devices that happen to be in the neighbourhood.)
Did things ever work for you? When you leave the gateway Traffic page in TTN Console open for quite some time (or when you look in your logs over an extended period), are you seeing packets from other nodes?
sorry I am not familiar with the post format. I have to learn.
I have found one another place for the device, ~ 15m far from gateway.
I have now only one device in use.
for me it’s seem all things are working.
It is only information from the gateway-status. I don’t have something else to show the traffic.
As they joined, the devices were working fine at some point. For a gateway, which simply forwards whatever it receives (CRC errors aside), an OTAA Join Request is just an uplink, just like a “regular” data uplink. So:
If you used the current gateway for the OTAA joins, then both the gateway and the nodes were working at that time, and then something has changed with either the gateway or both nodes.
If they joined using another gateway, then your current gateway is likely the problem. Did it ever work? Is there any wiring you can check?
I manage 2 devices with 2 applications. (two application-EUI). The gateway work with two applications. Each application with only one device.
Now for testing I have only one device (mega 2560 with lora shield – DHT11) and also only one gateway (rpi 3b with IMST-iC880a) in use.
With the arduino-ide console, I can see the device joint (OTAA) successfully the gateway and I can also see the transmission of values (temperature and humidity).
Not exactly. Gateways don’t know anything about applications (nor about devices).
If your own gateway’s log is always only showing CRC errors, and nothing shows on your gateway’s Traffic page in TTN Console, then the device’s Join Request must have been received by other gateway(s) in your neighbourhood. And its Join Accept must have been sent from (one of) the other gateway(s) as well. (Devices do not connect to a specific gateway; they just transmit and hopefully one or more gateways forward their data to TTN.)
Also, if the Join Request uplink was received by other gateway(s), then the device’s data uplinks must be received by those gateways as well, and hence the application/device’s Data page in TTN Console must show the data as well?
So, the device is fine (not causing the CRC error).
Again: did your gateway ever work? Any wiring you can check?
The AppEUI is similar to a port number. I can manage several connected devices.
The DevEUI is similar to a MAC address.
The end device constructs a message containing the DevNonce, AppEUI and DevEUI. Over this message, the Message Integrity Code (MIC) is generated by the AppKey. The message is sent to the network server.
I have a look at the mobilefish.com and the result for me is:
After the join request from the end device, the network server authenticates the end device and send the “join successfully” message. The message contains the DevAddr, AppNonce, NetID and some other values. The communication between the end device and the network server is established. For me in my case this step work fine. I see the message on the Arduino-ide console. The passed parameters appEui and appKey are ok.
Now the second part with the data transmission. The LoRa packet comprises of three elements: Preamble, header (optional) and payload. If the header is not presence, we have the Implicit header mode otherwise we have the Explicit header mode. By the implicit header mode, the payload, coding rate and CRC presence are fixed. In this mode the header is removed from the packet (transmission time aspect). In this case the payload length, error coding rate and presence of the payload CRC must be (manually?) configured on both sides of the radio link.
I don’t know exactly what happened with the OTAA join mode. The packet forwarder decodes the incoming packet from the network server. Perhaps it is a confusion between the implicit and the explicit header mode decoding. The payload-CRC is always present in both packets. Only present in explicit header mode, the header provides information if the CRC-payload is present or not. The message CRC_FAIL: 100.00% says the packet forwarder can not decode properly the incoming packet. It was for me the reason to adapt the forward only valid parameter section in the global_conf.json file. I disable the forward CRC control and restart the ttn-gateway.service, Now the RF packets forwarder counter says, the gateway is sending something. It is a big mistake to do that. In the implicit header mode, the packet forwarder never asks if the CRC-payload is present or not. the payload length, error coding rate and presence of the payload CRC must be configured on both sides of the radio link. The packet forwarder makes it automatically?
The value of the RF packet forwarder counter is not trusty. The gateway is never sending something to the network server.
I use the poly_pkt_fwd from the zh-gateway package with only one network server enable. I have also used the basis_pkt_fwd without success. I am not sure but it is something wrong with the packet_forwarder.
The packet forwarder does not decode anything at all, it can not as it does not have access to the encryption keys used.
The packet forwarder only checks a CRC and forwards (the name suggests it) packets. From the network to the air and from the air to the network.
No it says the received data did not pass a simple CRC check so the packet received from the air is not worth forwarding to the network as it is damaged.
The value is perfectly alright. Only packets with a valid CRC should be forwarded. Your problem is that you do not receive valid data on your gateway as the failure with two packet forwarders shows. There is nothing wrong with the packet forwarders.
There are a number of possible reasons:
Your node is not sending valid data
The incoming signal at the gateway is too strong resulting in over modulation which malforms the received data.
You gateway hardware is defective.
… countless more options…
If you do not start answering the basic questions Arjan asked we will not be able to help you and we won’t spend any more time helping you.