I email IMST about their official board and case and it seems they are only selling them with new IC880a orders, not a good way to treat recent customers. I wanted to show their kit at my local makerspace but they seemed disinterested.
If IMST missed the chance, thats the best for others 
as
@Charles iC880A and Linklabs in-between-shield plus funky features
or
@gonzalocasas onzalocasas [IMST IC880A + RPi] Gateway "hangs" every few weeks
well that depends - I know of quite a few people who want a close to turnkey solution, they don’t mind assembling but don’t want to solder.
With the delays of the TTN gateway and the increasing interest of telcos I hope that TTN doesn’t “miss the boat”
I could sell those pre-assembled if anyone is interested. I can provide them at cost, not interested in making money with this; what I am not sure of is how the shipping part works, I guess I can ship it in a regular padded envelope, otherwise the cost of shipping to some countries will exceed that of the board itself.
DM me if you’re interested.
I also have a problem where my gateway (RPi/IC880a SPI) falls over when left running. Last night it only ran for an hour. I start poly_pkt_fwd manually and see how long it goes for before getting:
ERROR: [main] unintended SX1301 reset detected, terminating packet forwarder.
I will have a go at doing the steps listed in this post and see if it improves. Shorter wires or make a PCB, power supply filtering, shielding, turn off WIFI (which would be a real pain!).
I also have CRC errors so may have some relationship.
Notice that the unintended reset message is recoverable. The service restarts automatically in that case, so, that’s probably not the root cause if your gateway is non operational after that. I’d go for WiFi issues or power supply issues (in that order).
I’m afraid the nice watchdog code is hiding the real problem, the relative long non screened wires between Pi and IC880A act as antenna’s, for example GSM telephone or switching relays, connecting mains loads further away all these can couple into the wires and disturb signal levels and shape, resulting in wrong SPI communications. Maybe I was lucky but my gateway never did fail or reset, it’s already running for months with Wifi communication to the internet and no special code.
Further keep the IC880A antenna input as far as possible away from the noisy Pi, it will help you with receiver sensitivity…
Mine was resetting due to the power supply. I had inadvertently used the wrong white wall plug adapter. Changed it back and resets gone. CRC errors still present so still some work to do. I am going to put a good power supply filter on and probably a stiffer reset pull up and a small cap. The jumper wires gotta go. Perhaps make an adapter PCB with everything on it and good shielding.
Keep in mind packets with CRC errors are to be expected and present on commercial gateways as well. After all with radio communication interference is to be expected…
Hi Gonzalo,
I build a Lorank based gateway with a beaglebone, same problems, and I want to install the watchdog. Do you know if the Lorank installer is already updated with it?
The watchdog is outdated, we’re not using that anymore, the current fix is in the packet forwarder itself (the TTN fork: https://github.com/TheThingsNetwork/packet_forwarder/commit/d0a3319599d84cb455047f915b9c2aac7cd54e25). I think Lorank8 does not use the TTN fork but @devlaam knows best.
For a quick test, you could try adding the same lines of code directly in the clone of the packet forwarder you have and trigger compilation, Lorank8 uses almost the same script to build that we use (in fact, we forked from theirs originally), so their process is also basically 1) clone 2) compile 3) install.
cheers
So according to the wiring diagram on ttn-zh wiki, the reset pin from iC880A is connected to RPi pin 22 aka GPIO25. I wonder if anything is actually controlling that pin? I cannot find any mention of that in the relevant repos; nothing on ttn-zh or . If nothing is actually driving that GPIO pin, it’s an input and thus the reset pin is pulled down to GND via a 100k resistor on the iC880A board. While it is enough to hold the pin near the logical 0, strong interference may induce transients and cause an unintended reset. Could anyone experiencing this problem try and connect the reset pin to ground via a 4k7…10k resistor instead and see if it helps or not. Ideally though someone should patch the code/instructions to make that pin an output and drive it properly.
1 Like
The reset is performed during the execution of the start.sh script. The control is then transfered to the packet forwarder which is expecting to fint the IC880A in a clean reseted state.
There is a catch: the script unexports the pin (line 13). When you unexport, the pin is set back as input. You can guess the rest.
We can try and remove unexport from the script – not really needed, and see if it fixes the problem.
1 Like
A reset pin is usually pulled high with a large (~10kOhm) resistor. When you set the output pin of the raspberry pi, with which you pulled the pin low, back to input, the reset pin will always be pulled high, preventing a reset.
I think the way it is currently done is correct.
Hi,
My gateway with Raspberry Pi and RisingHF LoRa Concentrator Module (similar to IMST IC880A) also experiences hangs, only if after internet is down for some time and up again. From the logs, radio packets are received without problems (I can still see how many radio packets are received by concentrator), no resets issue, however upstream and downstream is not shown anymore after internet is down for like 1 hour and more and up again.
I reproduce the same problem by turning off my home router for 1 hour then I turn it on again. I expect the gateway is able to send the packets to TTN server if the internet reconnects, but at this point it is not sending, upstream and downstream is not shown in logs as usual. If I restart ttn-gateway service, the thing is working again as usual.
Does anyone has the issue same as me?
Sounds like a NAT issue on the router, many NAT implementations expire UDP mappings after 1 hour.
You could try @jpmeijers Gateway Connector implementation which uses TCP instead of UDP and so should be more stable: https://github.com/jpmeijers/ttn-resin-gateway-rpi
Wow it is new to me, thanks for introducing this to me! I am eager to try it out. Seems like configuration and monitoring will be easier with the online dashboard.
For UDP mappings issue, is there any possible fix either on router or software in Raspberry Pi? Just eager to know, as it might help those who have the same issue as me. Thanks.
The guys from the core TTN team have prepared a totally new packet forwarder based written in go-lang. We’re testing it, and soon will replace the installer with it. The new packet forwarder does not use UDP to connect, so it shouldn’t have this issues. 
1 Like