IMST iC880A receiving all RF packets with CRC error

Hi all,

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

[UPSTREAM]

……. # RF packets received by concentrator: 1
……. # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
……. # RF packets forwarded: 0 (0 bytes)
……. # PUSH_DATA datagrams sent: 2 (639 bytes)
……. # PUSH_DATA acknowledged: 100.00%
…….

something wrong?

  • CRC_FAIL: 100.00%,
  • RF packets forwarded: 0

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

[UPSTREAM]

……. # RF packets received by concentrator: 1
……. # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
……. # RF packets forwarded: 1 (152 bytes)
……. # PUSH_DATA datagrams sent: 2 (639 bytes)
……. # PUSH_DATA acknowledged: 100.00%
…….

help, help

show some console screenshots / metadata pls
from the otaa join
from the application where the device is added
from the device itself

Those are useless, so will/should be ignored. Maybe your devices are far too close to your gateway, causing the reception circuits to be overloaded?

Also, please don’t forward packets with bad CRC to TTN, so revert the configuration changes you made.

devices are not far too close to Gateway? (~ 2m)

sorry, after set back CRC-Control parameters and restart the service I have RF packets forwarded: 0 (0 bytes)

##### 2019-03-25 13:33:29 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 1
# CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (219 bytes)
# PUSH_DATA acknowledged: 100.00%

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?

(Also, please see How do I format my forum post?)

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.

no change.
### [UPSTREAM]###
# RF packets received bei concentrator: 1
# CRC_OK: 0.00%, CRC_FAIL: 100,00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (219 bytes)
# PUSH_DATA acknowledged: 100.00%

How did you manage this? Using another gateway?

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?

Ok you are right, but now I have only one gateway and only one device with one application.

Sorry, I have to make a break now. I hope I can continue tomorrow norming this dialog with you. Thank for spending time for me. Have a good day.

Hi

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.

BTW. Do you really understand any of the text you are quoting? If not (and your messages suggests you don’t), try https://www.thethingsnetwork.org/docs/lorawan/ .

2 Likes

I explain that I have only one Gateway, one node with one sensor. But it is not enough. I thank you. I stop my request. I am a beginner. bye

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.