@bluejedi, you read my mind, it’s done now, I test it since yesterday, setup if done by 2 scripts (1 to preconfigure PI and reboot, the other for the setup) asking what board you use and what features you want to install check if RPI 3 or RPI Zero to install correct nodeJS version.
Check out new on the repo the new readme.md
All should go straightforward, let me know in case of bug or if it need some improvement
1 Like
OK - just to say I now have the gateway running using a R.Pi with Rak831 and the Rak831 board using
https://www.thethingsnetwork.org/docs/gateways/rak831/
One difference is that I used 11 for GW_RESET_PIN
It is certainly less work to use method 1 , but with this method 2, I can certainly see the value of using Resin.io to remotely manage multiple TTN gateways (based on RAK831).
As I now have 2 memory cards - I can choose which software to use for the time being.
Its great to be able to use Resin for something and see the results (not used it before).
Will try version 3 soon (Charles version) - but I’m thinking of doing that another day now.
One thing though, Method 1 needs “legacy packet Forwader” ticked, but Method 2 (Kersing) does not i.e. Method 2 uses the more “accepted” TTN version (for want of the proper term).
For Method 3 (Charles version), it seems that “legacy packet forwarder” should be ticked - is this correct?
Yes, these differences and inconsistencies are very confusing (I also ran into this issue previously).
Here GW_RESET_PIN actually refers to the PIN number (just like te name indicates, which is correct) and not the GPIO number.
1 Like
New setup use new kersing MP packet forwarder, but I had issues with some devices what were unable to join with the mp packet forwarder. When I reverted to old packet forwarder issues were gone, this is strange because it’s not the 1st time I see this issue. May be due to device without GPS and time sync drift.
Anyway if you want to switch from mp to legacy forwarder (my version with extended log), just run the script from my repo
./build_legacy.sh
The Reset Pin is asked by the main setup script and it’s the BCM format (GPIO Name)
2 Likes
To prevent (more) possible confusion:
Which is the GPIO number, not the GPIO name (because that would be something like “GPIO17”). 
For
- CH2i RAK831 reset pin is GPIO25 (Pin 22) enter in setup script
25 - CH2i iC880a reset pin is GPIO17 (Pin 11) enter in setup script
17
but if you chose the correct board, setup does this for you
- RAK Raspberry Pi Adapter board for RAK831 uses GPIO17 (physical pin 11): GPIO number: 17
What does selecting?:
- All other models
Added
1 Like
This mean you’ll need to enter the reset pin manually in the setup (and may be manually adjust some config)
Hi Charles,
I’m will soon be trying your software with a R.Pi3 (B+) and RAK831 board - which option would this be? (or have you done this already 
)
Thanks for doing this BTW
There have been issues a number of times with delays in the packet processing for the TTN protocol in the back-end. I’ve seen delays of several minutes, at those times any response (OTAA and downlink) will be useless as the node will not be listening…
It’s a new option (not on the screenshot) RAK831 official shield (if you’re using the RAK831 PI Adapter plate) of course
That’s strange, when I had the issue, TTN was working fine except for a bunch of devices (all the same). Finally I switched to legacy and issue was solved. But afterward a customer fired up the same issue with exactly the same devices. It was on a Lorix One with another LoRaWAN private provider. I switched on the Lorix from mp_pkt_fwd to legacy packet forwarded and it did the trick. I’m quite sure the devices had something specific but to be honest all of this made me switch back to legacy. I know you’re using multitech with success but would be interesting to have users thought (some who have lot of different devices).
I can’t believe it’s just me and my customers
Keep in mind there might be several issues. So your problem might not be related to the issue I mentioned. I had issues joining because of the delays. Once response times were back to normal values the joins worked just fine.
Could you try the difficult devices with a TTN Gateway to see if they work with it?
I had the same sort of problems as Charles describes with my RAK831/RasPiZero GW. I followed Charles github page while installing everything about a month ago.
I had several devices with 8MHzPro-Mini/RFM95 which could absolutely not join with the RAK831 at SF 7. On SF8 some devices could sometimes join and with SF9 all devices could always join.
Those same node’s could join with SF7 on a single channel Wemos gateway. When joined the RAK GW had no problems reading the SF7 packets. So my thought was timing problems in the RAK gateway with sending SF7/SF8.
If connecting a GPS module will solve the problems I will use that but I did not figure out yet how to connect the Ublox module to the RAK831