[SOLVED] Ic880a stopped responding to RESET on pin 22

Hi!

I built a gateway using an RPi3 and an ic880a board. I used this resin.io build -

The gateway worked great for 3 weeks and then one morning I found that it had stopped and was looping in the reset script.

31.07.17 18:00:55 (+0000) INFO: Description configured to “RPi3-ic880a-1”
31.07.17 18:00:55 (+0000) INFO: [main] TTY port /dev/ttyAMA0 open for GPS synchronization
31.07.17 18:00:55 (+0000) INFO: [Transports] Initializing protocol for 1 servers
31.07.17 18:00:56 (+0000) INFO: [TTN] server “bridge.eu.thethings.network” connected
31.07.17 18:00:56 (+0000) INFO: [main] Starting the concentrator
31.07.17 18:00:56 (+0000) ERROR: [main] failed to start the concentrator

I rebuilt the SD card from scratch, thinking it might have been corrupted - but no joy - still the amber LED does not light.

I bought a new ic880a board, thinking that the original board must have had a hardware failure - but no joy - amber LED does not light.

I replaced the RPi3 - but no go with that either.
Several rebuilds with different Resin OS systems and new SD cards but still no go with the gateway starting.

I now have 2 RPi3 + ic880a gateways which fail to start.
Has anyone got any ideas?

Thanks in advance.

Have you checked the power supply? Is the red led on the RPi constantly lit or does it flash or fade?
What PCB are you using?
BTW, when using pin 22 I never see the amber led on the iC880a lit up. Only when using a PCB that requires a different reset pin.

Something you can try is to put comment signs in front of the G in lines 295 and 296.

I’m using 12v 2A over POE. The red LED on the RPi3 is constantly on and I have a voltage of 5.1V and using 450mA to power the boards.
I’m using this backplane -

https://shop.coredump.ch/product/ic880a-lorawan-gateway-backplane/

Pin 13 of the ic880a is connected to pin 22 of the RPi3 on the backplane - and has been working with no problems. The amber LED (2) always came on just before the concentrator started up.

With no software changes, I don’t understand why the gateway should suddenly fail. What’s more baffling is that the new hardware (RPi3 + ic880a) just connected with jumpers, as a minimal system and powered with a 5V 3A psu, exhibits exactly the same symptoms.

I think it will be lines 296 and 297 in my version of run.py

295 time.sleep(0.5)
296 GPIO.input(pin_number)
297 GPIO.cleanup(pin_number)

Is there anything I can set in the build to get some debug information out?

You are right about the line numbers. You could try enabling SPI debugging (requires modifying the lora_gateway/libloragw/library.cfg, set DEBUG_SPI to 1)

OK - I’ll set the DEBUG_SPI to 1

Where can I find the DEBUG output?

Commenting out the 2 lines had no effect.

OK - the SPI bus seems to be working.

31.07.17 21:24:53 (+0000) INFO: Description configured to “RPi3-ic880a-1”
31.07.17 21:24:53 (+0000) INFO: [main] TTY port /dev/ttyAMA0 open for GPS synchronization
31.07.17 21:24:53 (+0000) INFO: [Transports] Initializing protocol for 1 servers
31.07.17 21:24:57 (+0000) INFO: [TTN] server “bridge.eu.thethings.network” connected
31.07.17 21:24:57 (+0000) INFO: [main] Starting the concentrator
31.07.17 21:24:57 (+0000) Note: SPI port opened and configured ok
31.07.17 21:24:57 (+0000) Note: SPI read success
31.07.17 21:24:57 (+0000) Note: SPI read success
31.07.17 21:24:57 (+0000) ERROR: [main] failed to start the concentrator
31.07.17 21:25:09 (+0000) [TTN Gateway]: Resetting concentrator on pin 22
31.07.17 21:25:10 (+0000) *** Multi Protocol Packet Forwarder for Lora Gateway ***
31.07.17 21:25:10 (+0000) Version: 3.0.0
31.07.17 21:25:10 (+0000) *** Lora concentrator HAL library version info ***
31.07.17 21:25:10 (+0000) Version: 5.0.1; Options: native;
31.07.17 21:25:10 (+0000) ***

But the concentrator still fails to start.

Debug output is written to standard out so should be visible in the output.

Another debug option to check would be HAL.

OK - I’ll give HAL a go.

With DEBUG_HAL set to 1 - there is an error - FAIL TO CONNECT BOARD

31.07.17 21:53:10 (+0000) INFO: Description configured to “RPi3-ic880a-1”
31.07.17 21:53:10 (+0000) INFO: [main] TTY port /dev/ttyAMA0 open for GPS synchronization
31.07.17 21:53:10 (+0000) INFO: [Transports] Initializing protocol for 1 servers
31.07.17 21:53:10 (+0000) INFO: [TTN] server “bridge.eu.thethings.network” connected
31.07.17 21:53:10 (+0000) INFO: [main] Starting the concentrator
31.07.17 21:53:10 (+0000) Note: SPI port opened and configured ok
31.07.17 21:53:10 (+0000) Note: SPI read success
31.07.17 21:53:10 (+0000) Note: SPI read success
31.07.17 21:53:10 (+0000) ERROR: FAIL TO CONNECT BOARD
31.07.17 21:53:10 (+0000) ERROR: [main] failed to start the concentrator

Interesting!

Generated in line 726 of loragw_hal.c

It could be an issue with the configuration. Is the gateway still set to the right frequencyplan? Is the clksrc set to 1 in the global_conf.json? Is the global configuration on your system the EU868 one?

Yes - set to Europe 868MHz
Yes - clksrc set to 1

“clksrc”: 1,
“chan_multiSF_7”: {
“enable”: true,
“radio”: 0,
“if”: 400000,
“desc”: “Lora MAC, 125kHz, all SF, 867.9 MHz”

This is a part of the Resin.io log -

31.07.17 22:49:09 (+0000) [TTN Gateway]: Resetting concentrator on pin 22
31.07.17 22:49:10 (+0000) *** Multi Protocol Packet Forwarder for Lora Gateway ***
31.07.17 22:49:10 (+0000) Version: 3.0.0
31.07.17 22:49:10 (+0000) *** Lora concentrator HAL library version info ***
31.07.17 22:49:10 (+0000) Version: 5.0.1; Options: native;
31.07.17 22:49:10 (+0000) ***
31.07.17 22:49:10 (+0000) INFO: Little endian host
31.07.17 22:49:10 (+0000) INFO: found global configuration file global_conf.json, parsing it
31.07.17 22:49:10 (+0000) INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
31.07.17 22:49:10 (+0000) INFO: lorawan_public 1, clksrc 1
31.07.17 22:49:10 (+0000) lgw_board_setconf:437: Note: board configuration; lorawan_public:1, clksrc:1
31.07.17 22:49:10 (+0000) INFO: no configuration for LBT
31.07.17 22:49:10 (+0000) INFO: antenna_gain 0 dBi
31.07.17 22:49:10 (+0000) INFO: Configuring TX LUT with 16 indexes
31.07.17 22:49:10 (+0000) INFO: radio 0 enabled (type SX1257), center frequency 867500000, RSSI offset -166.000000, tx enabled 1
31.07.17 22:49:10 (+0000) lgw_rxrf_setconf:486: WARNING: NOT A VALID TX NOTCH FILTER FREQUENCY [126000…250000]Hz
31.07.17 22:49:10 (+0000) lgw_rxrf_setconf:498: Note: rf_chain 0 configuration; en:1 freq:867500000 rssi_offset:-166.000000 radio_type:2 tx_enable:1 tx_notch_freq:0
31.07.17 22:49:10 (+0000) INFO: radio 1 enabled (type SX1257), center frequency 868500000, RSSI offset -166.000000, tx enabled 0
31.07.17 22:49:10 (+0000) lgw_rxrf_setconf:498: Note: rf_chain 1 configuration; en:1 freq:868500000 rssi_offset:-166.000000 radio_type:2 tx_enable:0 tx_notch_freq:0
31.07.17 22:49:10 (+0000) INFO: Lora multi-SF channel 0> radio 1, IF -400000 Hz, 125 kHz bw, SF 7 to 12
31.07.17 22:49:10 (+0000) lgw_rxif_setconf:617: Note: LoRa ‘multi’ if_chain 0 configuration; en:1 freq:-400000 SF_mask:0x7e
31.07.17 22:49:10 (+0000) INFO: Lora multi-SF channel 1> radio 1, IF -200000 Hz, 125 kHz bw, SF 7 to 12
31.07.17 22:49:10 (+0000) lgw_rxif_setconf:617: Note: LoRa ‘multi’ if_chain 1 configuration; en:1 freq:-200000 SF_mask:0x7e
31.07.17 22:49:10 (+0000) INFO: Lora multi-SF channel 2> radio 1, IF 0 Hz, 125 kHz bw, SF 7 to 12
31.07.17 22:49:10 (+0000) lgw_rxif_setconf:617: Note: LoRa ‘multi’ if_chain 2 configuration; en:1 freq:0 SF_mask:0x7e
31.07.17 22:49:10 (+0000) INFO: Lora multi-SF channel 3> radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
31.07.17 22:49:10 (+0000) lgw_rxif_setconf:617: Note: LoRa ‘multi’ if_chain 3 configuration; en:1 freq:-400000 SF_mask:0x7e
31.07.17 22:49:10 (+0000) INFO: Lora multi-SF channel 4> radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
31.07.17 22:49:10 (+0000) lgw_rxif_setconf:617: Note: LoRa ‘multi’ if_chain 4 configuration; en:1 freq:-200000 SF_mask:0x7e
31.07.17 22:49:10 (+0000) INFO: Lora multi-SF channel 5> radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
31.07.17 22:49:10 (+0000) lgw_rxif_setconf:617: Note: LoRa ‘multi’ if_chain 5 configuration; en:1 freq:0 SF_mask:0x7e
31.07.17 22:49:10 (+0000) INFO: Lora multi-SF channel 6> radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12
31.07.17 22:49:10 (+0000) lgw_rxif_setconf:617: Note: LoRa ‘multi’ if_chain 6 configuration; en:1 freq:200000 SF_mask:0x7e
31.07.17 22:49:10 (+0000) INFO: Lora multi-SF channel 7> radio 0, IF 400000 Hz, 125 kHz bw, SF 7 to 12
31.07.17 22:49:10 (+0000) lgw_rxif_setconf:617: Note: LoRa ‘multi’ if_chain 7 configuration; en:1 freq:400000 SF_mask:0x7e
31.07.17 22:49:10 (+0000) INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7
31.07.17 22:49:10 (+0000) lgw_rxif_setconf:591: Note: LoRa ‘std’ if_chain 8 configuration; en:1 freq:-200000 bw:2 dr:2
31.07.17 22:49:10 (+0000) INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate
31.07.17 22:49:10 (+0000) lgw_rxif_setconf:647: Note: FSK if_chain 9 configuration; en:1 freq:300000 bw:3 dr:50000 (50000 real dr) sync:0xC194C1
31.07.17 22:49:10 (+0000) INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
31.07.17 22:49:10 (+0000) INFO: gateway MAC address is configured to B827EBFFFE8D952B
31.07.17 22:49:10 (+0000) INFO: Found 1 servers in array.
31.07.17 22:49:10 (+0000) INFO: Server 0 configured to “bridge.eu.thethings.network”

I found this warning in the log -

31.07.17 22:49:10 (+0000) lgw_rxrf_setconf:486: WARNING: NOT A VALID TX NOTCH FILTER FREQUENCY [126000…250000]Hz

Maybe this is causing the problem?

Have you contacted IMST? They have now a ticket system for technical support:
https://wireless-solutions.de/support

Hi marssystems,

This happened to me as well, and kersing is right about checking the power supply. Mine stopped working after around a week of stable operation, but somehow, it stopped working. Checking resin-io log screen, it is cycling through attempts in starting the concentrator… and failing. I first tried to do a software restart but when it didn’t work, I pulled out the GPS (which is sharing the power from a single 2.5A adaptor supply powering the RPi3B and the iC880a), let everything cool down and when I turned it on, everything started fine.

I first checked if something has changed but couldn’t find any which led me to believe it had something to do with the power supply. Just got my RPi to iC880 shield and will be finally making the connections permanent (I was just using jumper wires before this). Planning all along to provide a separate power supply for the iC880a.

Check the iC880A-SPI QuickStartGuide:

The power pins (21, 22) have to be connected to a power source that is able to provide more than 700 mA. Therefore it is recommended to choose a proper power supply that is able to supply the iC880A-SPI and the host system (e.g. Raspberry PI) at the same time.

I am using a 5.1V 10A psu so that isn’t a problem.

Check your power cables, ESPECIALLY if you’re using USB cables. Most of them are crap and will drop voltage like there’s no tomorrow under load because they are barely rated for 500mA. Just in case, use different cables for the two boards, or make your own sturdy cable and supply the RPi directly through the 5V pin on the header (be careful, it bypasses the polyfuse).

If said load is a current inrush (for example, when you are resetting the iC880A) the voltage drop might not even be visible on a multimeter, so if you have an oscilloscope at hand you should use that with a falling trigger at 4.5V or something.

My backplane - this one -

https://shop.coredump.ch/product/ic880a-lorawan-gateway-backplane

Has an on-board 5.1V 3A voltage regulator which I was powering from a 12V 20A psu over POE so I’m confident that the gateway has more than enough ‘juice’ for its needs.

If there’s a regulator on the board, cables can’t be the issue indeed.

I switched the gateway off for 30 mins - when I powered it on, it started up straight away - :laughing:
I will have to keep my eye on it - I don’t like not knowing what caused the failure in the first place.

Glad that worked for you :). I am doing the same… will be a headache if this happens in the field ;(

I have the same board. one thing I noticed is that the small potentiometer is hard to adjust… and it is suggested that we make it permanent by putting a drop of silicon on it. Did you check the voltage while your ic880a wasn’t starting up? I didn’t… but I will be doing that if and when the problem surfaces again. Building 5 gateways in total and we need this stable before we put it out in the field…

Yes - I have a voltmeter connected to the 5V output on the backplane and it shows 5.1V.

The gateway still fails to start after a re-boot. I have to do the power off - wait - power on procedure each time. I don’t understand why the ic880a doesn’t respond to the RESET signal as it should.