I’m biased of course 
but I think it still is an excellent choice. When TTN provides the V3 version of the backend for the community network you might want to consider Basic Station but for V2 I don’t think that is the best option.
If you want to make life easier with regards to upgrading the software in due course I would suggest using Balena on the RPi. That allows you to remotely update the software in the future.
IMHO if it ain’t broke don’t fix it. I run various Semtech legacy, poly, mp & basic stn gw’s and Jac’s behaves & is as stable as any and usually better than basic stn with glue to v2. For me the clincher is fact I can use decent names for gw vs relying on a clunky EUI based name with a pseudo random set of numbers … ok can now quickly recognise ones that are TTIGs, RPis or Lairds or whatever by looking at first few bytes but not as good as knowing it is TestGW_001, TestGW_007, TestGW_039 or whatever or perhaps Acme-Factory#3, or Acme-North-Vinyard, River_Bridge5, etc.
Great - I knew what to choose before three years already 
So i will keep jac’s packet forwarder. In this case is it any way to diagnose what is wrong with current configuration?
Starting with:
sudo /opt/ttn-gateway/dev/lora_gateway/reset_lgw.sh start 25
echo sleep 10s before mp_pkt_fwd
sleep 10s
cd /opt/ttn-gateway
./mp_pkt_fwd
But ends everytime with the same message:
17:27:45 INFO: Description configured to “GW NG 1 @ GB33”
17:27:45 INFO: [Transports] Initializing protocol for 1 servers
17:27:45 INFO: [TTN] server “router.eu.thethings.network” connected
17:27:45 INFO: [main] Starting the concentrator
17:27:45 ERROR: [main] failed to start the concentrator
Deamon.log says:
Jan 15 17:58:15 gw_ng_1 mp_pkt_fwd[20110]: 17:58:15 INFO: [Transports] Initializing protocol for 1 servers
Jan 15 17:58:15 gw_ng_1 mp_pkt_fwd[20110]: 17:58:15 INFO: [TTN] server “router.eu.thethings.network” connected
Jan 15 17:58:15 gw_ng_1 mp_pkt_fwd[20110]: 17:58:15 INFO: [main] Starting the concentrator
Jan 15 17:58:15 gw_ng_1 mp_pkt_fwd[20110]: 17:58:15 ERROR: [main] failed to start the concentrator
Jan 15 17:58:15 gw_ng_1 systemd[1]: mppktfwd.service: main process exited, code=exited, status=1/FAILURE
Jan 15 17:58:15 gw_ng_1 systemd[1]: Unit mppktfwd.service entered failed state.
What can I check to find out if is it possible to fix current configuration without without “putting a hand on box”?
Thank You for any advice!
This typically indicates either that the concentrator card hasn’t been reset, or that there’s an SPI communication problem between the host system and the concentrator. It’s not typically very dependent on the actual packet forwarder version used, only on pointing it at the correct SPI device, correct wiring, and for the RAK boards with inexplicably slow and unecessary level translators, using a slow SPI clock (probably 1 MHz). It could also be an issue with insufficient power - putting an sx1301 or sx1308 concentrator into operating mode draws a lot of power, somewhat less so for an sx1302.
The most important question probably would be, do you have any packet forwarder which yet successfully operates this concentrator in this system - if it used to work but stopped doing so with the same software that used to work, that suggests a hardware failure. Given the power draw it might be thermally related.
As this really has nothing to do with the choice of packet forwarder, debugging your problem should really be its own thread.
(If you only have remote but not physical access to the box, build some of the SPI test routines and push them to the box to test the communication independent of actually trying to be a packet forwarder)
I have checked some basic points but without loopback on 19/21 pins and run ./spidev_test -v, I’m afraid I can’t do anything else. Thank You for useful advices.
Obviously, this is of no use without SPI loopback:
pi@gw_ng_1:~/spidev-test $ ./spidev_test -v
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 KHz)
TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | …@…▒…▒.
RX | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | …
About the error message, not being able to start the concentrator:
Using the same set-up as Roberto69, I see the same error on boot. Since the start attempt is repeated after a few moments, starting the concentrator succeeds finally, typically at the second or third attempt. So I do no care about that a lot. Especially since this RPI/iC880/Packet forwarder setup runs VERY STABLE, and a reboot is a rare event, like once a year. The last one I recall was a power fail caused by me by switching on a 1 KVA transformer in the same mains circuits without current limiter.
Best regards, Robert
I meant to use the test programs in the LoRa hal and packet forwarder repositories, which talk to the concentrator chip itself at a low level.
i agree. It is well known syndrome. But in my case, it not helps. At least if I would have control over PoE. Rule of thumbs: better to use worse location, which you can access it without 5 persons with 5 keys
“I meant to use the test programs in the LoRa hal and packet forwarder repositories, which talk to the concentrator chip itself at a low level.”
Of course, but I am afraid I am a little bit short on this level.