Initialization of loraserver gateway OS

Hello
I started configuring a gateway based on IC880A + RPI3b.
Wiring is done.
Installed LoRa Gateway OS.
Bridge is configured on another server.

After reboot: packet forwarder is started but stays in initializing mode…
Don’t where to investigate further… Any help ?

Monit 5.26.0 uptime: 22m

Process ‘lora-packet-forwarder’
status Initializing
monitoring status Initializing
monitoring mode active
on reboot start
data collected Fri, 13 Sep 2019 16:07:32

Process ‘lora-gateway-bridge’
status OK
monitoring status Monitored
monitoring mode active
on reboot start
pid 310
parent pid 1
uid 0
effective uid 0
gid 0
uptime 23m
threads 9
children 0
cpu 0.0%
cpu total 0.0%
memory 1.2% [10.8 MB]
memory total 1.2% [10.8 MB]
security attribute -
disk read 0 B/s [8.8 MB total]
data collected Fri, 13 Sep 2019 16:07:32

System ‘LORAGateway1’
status OK
monitoring status Monitored
monitoring mode active
on reboot start
load average [0.00] [0.00] [0.00]
cpu 0.0%us 0.0%sy 0.0%wa
memory usage 24.7 MB [2.7%]
swap usage 0 B [0.0%]
uptime 24m
boot time Fri, 13 Sep 2019 15:43:15
data collected Fri, 13 Sep 2019 16:07:32

I tried start the forwarder by CLI and got:

./lora_pkt_fwd /etc/lora-packet-forwarder/global_conf.json

*** Beacon Packet Forwarder for Lora Gateway ***
Version: 4.0.1
*** Lora concentrator HAL library version info ***
Version: 5.0.1;


INFO: Little endian host
ERROR: [main] failed to find any configuration file named global_conf.json, local_conf.json OR debug_conf.json

My config file exists in /etc/lora-packet-forwarder:

LORAGateway1:/opt/lora-packet-forwarder# cat /etc/lora-packet-forwarder/global_conf.json
{
“SX1301_conf”: {
“lorawan_public”: true,
“clksrc”: 1,
“antenna_gain”: 0,
“radio_0”: {
“enable”: true,
“type”: “SX1257”,
“freq”: 867500000,
“rssi_offset”: -166.0,
“tx_enable”: true,
“tx_freq_min”: 863000000,
“tx_freq_max”: 870000000
},
“radio_1”: {
“enable”: true,
“type”: “SX1257”,
“freq”: 868500000,
“rssi_offset”: -166.0,
“tx_enable”: false
},
“chan_multiSF_0”: {
“enable”: true,
“radio”: 1,
“if”: -400000
},
“chan_multiSF_1”: {
“enable”: true,
“radio”: 1,
“if”: -200000
},
“chan_multiSF_2”: {
“enable”: true,
“radio”: 1,
“if”: 0
},
“chan_multiSF_3”: {
“enable”: true,
“radio”: 0,
“if”: -400000
},
“chan_multiSF_4”: {
“enable”: true,
“radio”: 0,
“if”: -200000
},
“chan_multiSF_5”: {
“enable”: true,
“radio”: 0,
“if”: 0
},
“chan_multiSF_6”: {
“enable”: true,
“radio”: 0,
“if”: 200000
},
“chan_multiSF_7”: {
“enable”: true,
“radio”: 0,
“if”: 400000
},
“chan_Lora_std”: {
“enable”: true,
“radio”: 1,
“if”: -200000,
“bandwidth”: 250000,
“spread_factor”: 7
},
“chan_FSK”: {
“enable”: true,
“radio”: 1,
“if”: 300000,
“bandwidth”: 125000,
“datarate”: 50000
},
“tx_lut_0”: {
“pa_gain”: 0,
“mix_gain”: 8,
“rf_power”: -6,
“dig_gain”: 0
},
“tx_lut_1”: {
“pa_gain”: 0,
“mix_gain”: 10,
“rf_power”: -3,
“dig_gain”: 0
},
“tx_lut_2”: {
“pa_gain”: 0,
“mix_gain”: 12,
“rf_power”: 0,
“dig_gain”: 0
},
“tx_lut_3”: {
“pa_gain”: 1,
“mix_gain”: 8,
“rf_power”: 3,
“dig_gain”: 0
},
“tx_lut_4”: {
“pa_gain”: 1,
“mix_gain”: 10,
“rf_power”: 6,
“dig_gain”: 0
},
“tx_lut_5”: {
“pa_gain”: 1,
“mix_gain”: 12,
“rf_power”: 10,
“dig_gain”: 0
},
“tx_lut_6”: {
“pa_gain”: 1,
“mix_gain”: 13,
“rf_power”: 11,
“dig_gain”: 0
},
“tx_lut_7”: {
“pa_gain”: 2,
“mix_gain”: 9,
“rf_power”: 12,
“dig_gain”: 0
},
“tx_lut_8”: {
“pa_gain”: 1,
“mix_gain”: 15,
“rf_power”: 13,
“dig_gain”: 0
},
“tx_lut_9”: {
“pa_gain”: 2,
“mix_gain”: 10,
“rf_power”: 14,
“dig_gain”: 0
},
“tx_lut_10”: {
“pa_gain”: 2,
“mix_gain”: 11,
“rf_power”: 16,
“dig_gain”: 0
},
“tx_lut_11”: {
“pa_gain”: 3,
“mix_gain”: 9,
“rf_power”: 20,
“dig_gain”: 0
}
},

"gateway_conf": {
    "gateway_ID": "b827ebFFFE2175d4",
    "server_address": "fenoprofene",
    "serv_port_up": 1700,
    "serv_port_down": 1700,
    "keepalive_interval": 10,
    "stat_interval": 30,
    "push_timeout_ms": 100,
    "forward_crc_valid": true,
    "forward_crc_error": false,
    "forward_crc_disabled": false
}

}

If you start the packet forwarder from the CLI it may not know where to look for the configuration files. As a guess, change to the directory where the configuration files are, and invoke the forwarder from there.

For a DIY wiring setup you want to make sure you have the reset GPIO correctly connected and you might want to run the SPI stress test built alongside at least some version of the lora hal library used by the packet forwarder.

1 Like

Many thanks for your feedback.
Did the launch from the config file directory:

LORAGateway1:/etc/lora-packet-forwarder# /opt/lora-packet-forwarder/lora_pkt_fwd
*** Beacon Packet Forwarder for Lora Gateway ***
Version: 4.0.1
*** Lora concentrator HAL library version info ***
Version: 5.0.1;


INFO: Little endian host
INFO: found global configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
INFO: lorawan_public 1, clksrc 1
lgw_board_setconf:427: Note: board configuration; lorawan_public:1, clksrc:1
INFO: no configuration for LBT
INFO: antenna_gain 0 dBi
INFO: no configuration for tx gain lut 12
INFO: no configuration for tx gain lut 13
INFO: no configuration for tx gain lut 14
INFO: no configuration for tx gain lut 15
INFO: Configuring TX LUT with 12 indexes
INFO: radio 0 enabled (type SX1257), center frequency 867500000, RSSI offset -166.000000, tx enabled 1, tx_notch_freq 0
lgw_rxrf_setconf:476: WARNING: NOT A VALID TX NOTCH FILTER FREQUENCY [126000…250000]Hz
lgw_rxrf_setconf:488: Note: rf_chain 0 configuration; en:1 freq:867500000 rssi_offset:-166.000000 radio_type:2 tx_enable:1 tx_notch_freq:0
INFO: radio 1 enabled (type SX1257), center frequency 868500000, RSSI offset -166.000000, tx enabled 0, tx_notch_freq 0
lgw_rxrf_setconf:488: Note: rf_chain 1 configuration; en:1 freq:868500000 rssi_offset:-166.000000 radio_type:2 tx_enable:0 tx_notch_freq:0
INFO: Lora multi-SF channel 0> radio 1, IF -400000 Hz, 125 kHz bw, SF 7 to 12
lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 0 configuration; en:1 freq:-400000 SF_mask:0x7e
INFO: Lora multi-SF channel 1> radio 1, IF -200000 Hz, 125 kHz bw, SF 7 to 12
lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 1 configuration; en:1 freq:-200000 SF_mask:0x7e
INFO: Lora multi-SF channel 2> radio 1, IF 0 Hz, 125 kHz bw, SF 7 to 12
lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 2 configuration; en:1 freq:0 SF_mask:0x7e
INFO: Lora multi-SF channel 3> radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 3 configuration; en:1 freq:-400000 SF_mask:0x7e
INFO: Lora multi-SF channel 4> radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 4 configuration; en:1 freq:-200000 SF_mask:0x7e
INFO: Lora multi-SF channel 5> radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 5 configuration; en:1 freq:0 SF_mask:0x7e
INFO: Lora multi-SF channel 6> radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12
lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 6 configuration; en:1 freq:200000 SF_mask:0x7e
INFO: Lora multi-SF channel 7> radio 0, IF 400000 Hz, 125 kHz bw, SF 7 to 12
lgw_rxif_setconf:607: Note: LoRa ‘multi’ if_chain 7 configuration; en:1 freq:400000 SF_mask:0x7e
INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7
lgw_rxif_setconf:581: Note: LoRa ‘std’ if_chain 8 configuration; en:1 freq:-200000 bw:2 dr:2
INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate
lgw_rxif_setconf:637: Note: FSK if_chain 9 configuration; en:1 freq:300000 bw:3 dr:50000 (50000 real dr) sync:0xC194C1
INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to B827EBFFFE2175D4
INFO: server hostname or IP address is configured to “192.168.0.30”
INFO: upstream port is configured to “1700”
INFO: downstream port is configured to “1700”
INFO: downstream keep-alive interval is configured to 10 seconds
INFO: statistics display interval is configured to 30 seconds
INFO: upstream PUSH_DATA time-out is configured to 100 ms
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
ERROR: FAIL TO CONNECT BOARD
ERROR: [main] failed to start the concentrator

Looks like I need to check wiring…

try to create the start.sh file into the same directory of your global_conf.json

#! /bin/bash

Reset iC880a PIN

SX1301_RESET_BCM_PIN=17
echo “$SX1301_RESET_BCM_PIN” > /sys/class/gpio/export
echo “out” > /sys/class/gpio/gpio$SX1301_RESET_BCM_PIN/direction
echo “0” > /sys/class/gpio/gpio$SX1301_RESET_BCM_PIN/value
sleep 0.1
echo “1” > /sys/class/gpio/gpio$SX1301_RESET_BCM_PIN/value
sleep 0.1
echo “0” > /sys/class/gpio/gpio$SX1301_RESET_BCM_PIN/value
sleep 0.1
echo “$SX1301_RESET_BCM_PIN” > /sys/class/gpio/unexport

./lora_pkt_fwd

and then start it with: ./start.sh

Many many many thx !!

With your start script , I got better result:

> lgw_start:823: Note: calibration started (time: 2300 ms)
> lgw_start:844: Note: calibration finished (status = 191)
> Info: Initialising AGC firmware...
> Info: putting back original RADIO_SELECT value
> INFO: [main] concentrator started, packet can now be received
> 
> INFO: Disabling GPS mode for concentrator's counter...
> INFO: host/sx1301 time offset=(1568393437s:537486µs) - drift=230057166µs
> INFO: Enabling GPS mode for concentrator's counter.
> 
> INFO: [down] PULL_ACK received in 0 ms
> INFO: [down] PULL_ACK received in 1 ms
> INFO: [down] PULL_ACK received in 1 ms
> 
> ##### 2019-09-13 16:51:10 GMT #####
> ### [UPSTREAM] ###
> # RF packets received by concentrator: 0
> # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
> # RF packets forwarded: 0 (0 bytes)
> # PUSH_DATA datagrams sent: 0 (0 bytes)
> # PUSH_DATA acknowledged: 0.00%
> ### [DOWNSTREAM] ###
> # PULL_DATA sent: 3 (100.00% acknowledged)
> # PULL_RESP(onse) datagrams received: 0 (0 bytes)
> # RF packets sent to concentrator: 0 (0 bytes)
> # TX errors: 0
> # BEACON queued: 0
> # BEACON sent so far: 0
> # BEACON rejected: 0
> ### [JIT] ###
> # SX1301 time (PPS): 19191823
> src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty
> ### [GPS] ###
> # GPS sync is disabled
> ##### END #####
> 
> JSON up: {"stat":{"time":"2019-09-13 16:51:10 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0}}
> INFO: [up] PUSH_ACK received in 1 ms
> INFO: [down] PULL_ACK received in 0 ms
> INFO: [down] PULL_ACK received in 0 ms

Would you explain why forcing a RESET will do it better ?

Thx again !

The sx1301 chip has complex internal state and needs to start form a known situation, vs wherever a previous crashed instance of the packet forwarder may have left it.

It’s not a given that it has solid power-on self-reset either; flexible things like MCUs typically do, some other special purpose ICs, not necessarily - and the technology to make a POR reset detector isn’t necessarily something otherwise needed in a pure crunch-the-numbers digital process (the RF/Analog part is taken care of by the helper ICs, the SX1301 is pure hardwired digital processing)