Ok, one more backplane to the mix! 
My board doesnât have any of the funky features of @Charlesâ one. Itâs as simple as it gets:
Itâs shared on oshpark and the Fritzing file is on github.
It works with the installer script without changes.
And this is how it looks when plugged to the boards:
Nice,
You finally succeeded PCB with Fritzing ?
well, itâs more like I failed with Eagle and then tried Fritzing 
nice work, but does this also mean you didnât receive the official board yet?
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.
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.
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.
