Ic880a + RPi 2 - a lot of CRC_FAIL


(Michal) #1

Hello,

I have tested the following configuration:

iC880a + RPi 2 with The Things Network software from https://github.com/ttn-zh/ic880a-gateway
I am using 5V 2500 mA power supply for RPi 2 (I plug it into micro USB port).

For the node I use HopeRF RFM95W with Teensy 3.2, and a code from https://github.com/tftelkamp/arduino-lmic-v1.5 I tested it using both SF7 and SF12.

When those two are connected I am getting quite a lot of CRC_FAIL indications (usually between 25 and 50%, sometimes reaching 66%). I feel this is not normal for a simple test with those devices on the same desk. I have also tested the same node with a single-channel test gateway from tftelkamp github repository (based on HopeRF RFM95W as well) and I have not seen this problem (I would get some CRC errors but only for long ranges, not when node and gateway are close to each other).

Has anyone seen any issues like that? I looked at the forum and it seems some other people had similar problems but I could not find any consistent answers. Somebody pointed to power supply being not powerful enough. What power supply should be used in such configuration? What are the methods I could use to debug this system further? Any help is welcome!

Best regards,
Michal


Raspberry Pi 3 + IC880a
#2

This could just be another device operating at 868MHz.
An IC880A receiving at 8 channels on every SF from 7 to 12 simultaneously will trigger more often than a RFM95 which listens at only 1 channel and 1 SF at the same time.
I see something similar. The crc_fail rate is about constant. messages with correct crc are variable.
my gateway on semtech
I suspect the crc_errors origin from my thermostatic device. I just wait until the summer. Then i will remove the batteries,

Art.


#3

Well, it wasn't the thermostat. It's off now. The crc-errors are still there.


#4

Try putting the RFM95W node further away from the gateway. It might be giving off too strong a signal for the gateway on the same desk. I moved my Teensy with RFM95W node to another room and had (almost) no errors after that.

I have read a few reports by others about this, this seems to be a problem with the RFM95W in some configurations.


#5

You must be living on Hawaiï or so, it's still too cold to switch of the thermostat over here in Nijmegen :wink:

First of all, from a LoRa point, node and gateway do not "connect". A node just sends packets and any gateway in range will receive these packets and start decoding. All valid packets received by the gateway will be forwarder to the router and eventually (when using confirmed messages), the network will decide which gateway gets the action to send the ACK message to the node.

This means that your gateway will receive the messages on channels it listens on and checks all these messages. So you can never be sure that the messages you receive are from your own node. The gateway has no knowledge about the encryption key so it is not able to see from which node the message was received.
Unless you have special (network debugging) code in the gateway that is able to decode the messages using the application session key of your node.

  • Are you sure the messages resulting in CRC fails are from your own node? I normally attach an LED to my development boards in order to see when it starts transmitting.

  • Do you have any means of checking the radio spectrum? I have a simple SDR device that is able to scan the 868 MHz band so I can see if there is any other signal besides my own.
    If you don't, hunt Google (try searching for "RTL SDR 868". Something like this is almost a must when doing your own development, it shows you not only if you are transmitting but also on which channel(s), if channel hopping is used, what kind of SF you are using (a bit of guessing is involved there) and if there are other signals interfering with your signals.

I have seen very strange wide-band flashes across the 867-869 region in my office. Not one of my devices and it pops up now and then showing very short high-power burst once every few seconds for about a minute


#6

After a search for CRC_FAIL:100% I fell on this similar topic.
I have a ic880a + BB Green board as concentrator. On very frequent occasions I notice in my logs the following

Jan 10 10:33:43 beaglebone lorrier[3297]: ### [UPSTREAM] ###
Jan 10 10:33:43 beaglebone lorrier[3297]: # RF packets received by concentrator: 3
Jan 10 10:33:43 beaglebone lorrier[3297]: # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
Jan 10 10:33:43 beaglebone lorrier[3297]: # RF packets forwarded: 0 (0 bytes)
Jan 10 10:33:43 beaglebone lorrier[3297]: # PUSH_DATA datagrams sent: 3 (669 bytes)
Jan 10 10:33:43 beaglebone lorrier[3297]: # PUSH_DATA acknowledged: 100.00%
Jan 10 10:33:43 beaglebone lorrier[3297]: ### [DOWNSTREAM] ###
Jan 10 10:33:43 beaglebone lorrier[3297]: # PULL_DATA sent: 9 (66.67% acknowledged)
Jan 10 10:33:43 beaglebone lorrier[3297]: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Jan 10 10:33:43 beaglebone lorrier[3297]: # RF packets sent to concentrator: 0 (0 bytes)
Jan 10 10:33:43 beaglebone lorrier[3297]: # TX errors: 0

What does the CRC_FAIL indicate in this case when data is sent in upstream from a mote to the network server ? In previous experiments with my own node the gw does forward the data to my backend.
Does this mean my gateway receives lorawan frames that he can not deliver to my backend, so 'foreign' lorawan data ?
I am not very sure about this, so that is why I post my question up here - the data of my own devices are upstreamed in a correct way. Can anyone of the experts -Rob65 - confirm please just to be comfortable in knowing I do not lose any frames ?


(Arjan) #7

...and: