Providing you have easy access to your gateway 
While experimenting that is always a good idea. You never know when you mess up and need to reimage the card… (I also had two cards die on me over the years using RPis)
1 Like
Thanks to all. Using several cards is surely a good approach. And yes. at the moment I run it in an open frame, just everything fixed to a metal bracket avoiding stress to the cables & connectors…
@Amedee Thanks again. I tried the Kerising packet forwarder. Installation went well so far, but the behaviour is unclear. When started from the command line, it forwards uplink messages, but does not forward downlink messages. If gets the RESP message, but does not send it to the concentrator.
When configured as a service, it refused to start. The log always tells:
Apr 01 22:00:45 raspberrypi ttn-gateway[733]: 22:00:45 INFO: [main] Starting the concentrator
Apr 01 22:00:45 raspberrypi ttn-gateway[733]: 22:00:45 ERROR: [main] failed to start the concentrator
Apr 01 22:00:45 raspberrypi systemd[1]: ttn-gateway.service: Main process exited, code=exited, status=1/FAILURE
Apr 01 22:00:45 raspberrypi systemd[1]: ttn-gateway.service: Unit entered failed state.
Apr 01 22:00:45 raspberrypi systemd[1]: ttn-gateway.service: Failed with result 'exit-code'.
This not only once, but over & over. mp_pkt_fwd is started as a service.
There are some of gotchas, in particular if you have a RPi3
- Ensure you reset the ic880a before you start the packet forwarder
- Set
core_freq=250in/boot/config.txtto avoid variable SPI speed - Set
dtoverlay=pi3-miniuart-btin/boot/config.txtto get Bluetooth out of the way
That should do it.
2 Likes
Thanks. That solved the start problem.
Still, downlink packets are not delivered. The log looks like that:
Apr 01 22:43:13 raspberrypi ttn-gateway[312]: ### [UPSTREAM] ###
Apr 01 22:43:13 raspberrypi ttn-gateway[312]: # RF packets received by concentrator: 1
Apr 01 22:43:13 raspberrypi ttn-gateway[312]: # CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
Apr 01 22:43:13 raspberrypi ttn-gateway[312]: # RF packets forwarded: 1 (16 bytes)
Apr 01 22:43:13 raspberrypi ttn-gateway[312]: # PUSH_DATA datagrams sent: 2 (840 bytes)
Apr 01 22:43:13 raspberrypi ttn-gateway[312]: # PUSH_DATA acknowledged: 100.00%
Apr 01 22:43:13 raspberrypi ttn-gateway[312]: ### [DOWNSTREAM] ###
Apr 01 22:43:13 raspberrypi ttn-gateway[312]: # PULL_DATA sent: 3 (100.00% acknowledged)
Apr 01 22:43:13 raspberrypi ttn-gateway[312]: # PULL_RESP(onse) datagrams received: 1 (196 bytes)
Apr 01 22:43:13 raspberrypi ttn-gateway[312]: # RF packets sent to concentrator: 0 (22 bytes)
Apr 01 22:43:13 raspberrypi ttn-gateway[312]: # TX errors: 0
@robert-hh
Why are you using the (old) Semtech protocol and not ttn-gateway-connector protocol?
Register the gateway without setting the ‘legacy’ checkmark and in your local_conf.json add:
"servers": [
{
"serv_type": "ttn",
"server_address": "bridge.eu.thethings.network",
"serv_gw_id": "<gateway ID from console>",
"serv_gw_key": "<key from console something like ttn-account-XXXXX>",
"serv_enabled": true
}
]With regards to the downlink packet that has not been sent to the concentrator, the log should show additional information on why it has not been sent.
@kersing. Yes, thanks for the hint about the protocol. I’ll do that, did not know where to configure. But still I’m wondering why the downlink messages are not received. After using the global_conf.json file from https://github.com/TheThingsNetwork/gateway-conf, it tells now that “RF packets sent to concentrator: 1 (22 bytes)”, but the nod does not get tell it got them. The parameters in tcpdump look ok.
Check the log file to see if there is any information in there.
I know journalctl, which is pretty talkative, but does not tell much about this detail. Is there a different logfile for this topic?
using the ttn-gateway-connector protocol the downlink works, which surprised me. Even before, a Rf signal was sent by the gateway exactly 1 s after the uplink request, but it was not received by the node.
Another question: Now, when a downlink message is ofrwarded, the log shows something like:
Apr 02 08:46:34 raspberrypi ttn-gateway[590]: # PULL_RESP(onse) datagrams received: 0 (0 bytes)
Apr 02 08:46:34 raspberrypi ttn-gateway[590]: # RF packets sent to concentrator: 1 (0 bytes)
`'`
What confuses me is this (0 bytes), while actually the message is received. Before, there was something like (22 bytes) in my test messages.Understandable. Because of the difference between the transport protocols it is harder to get the byte count right. I decided not to bother while implementing, there were more important issues to solve.
I might visit it some time in the future. If it bothers you, log an issue at github or even better, fix it and send a pull request.
Thanks for the response. At the moment I’m just OK, if it’s intentional. I will definitely look into the code some time. At first glance, it looks pretty large.
After almost 3 years I would like to repeat this question. Which packet forwarder is the best to use it on RPi3 & iC880 concentrator?
As @Amedee says “If you want to be a bit more ‘modern’ in term of architecture you can use the Semtech packet forwarder updated and maintained by @kersing here 199.”
Is @kersing forwarder still the best choice after all of this time?
After 1038 days of uptime my GW needs some serviceing. Due to it’s difficult-to-reach location I would like to setup whatever is needed.
Actual forwarder is:
14:04:58 *** Multi Protocol Packet Forwarder for Lora Gateway ***
Version: 3.0.10
14:04:58 *** Lora concentrator HAL library version info ***
Version: 5.0.1; Options: native;
…
14:04:58 INFO: [Transports] Initializing protocol for 1 servers
14:04:58 INFO: [TTN] server “router.eu.thethings.network” connected
14:04:58 INFO: [main] Starting the concentrator
14:04:59 ERROR: [main] failed to start the concentrator
Thank You!
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.
1 Like
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.
1 Like
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