Which console logs do you mean ? In the live data tab of the gateway is see nothing. There it says “waiting for events”.
Sorry for the screenshot i edited it, its now a textblock with all content i receive when i click on the line.
Not good and strange as the ACKs up & down are in the log on your first post. Let’s see how the device is being heard before we jump to conclusions.
As for the device, which you omitted for reasons unknown but definitely slowing down the volunteers trying to help you, what is in the console log / Live Data / activity list? Having the contents of the ‘Forward uplink data message’ will tell us/you which gateways are being heard by the device. There is no confidential Information that is not distributed on the internet in the JSON so redacting info is pointless - unless you happened to use the AppKey for that extraordinarily long device-id …
From browan i got directed to this repo for an js decoder.
I added the code to the payload formatter of the device.
The live data list of the device contains the “create device” message and after that three times “decode uplink data message failure” and “forward uplink data message” so decode, forward, decode, forward, decode, forward.
the decode json
{
"name": "as.up.data.decode.fail",
"time": "2022-08-16T08:03:36.608804495Z",
"identifiers": [
{
"device_ids": {
"device_id": "eui-4aea73b31ed0a60bd2bf02cxxxxxxce6",
"application_ids": {
"application_id": "testapp788"
}
}
}
],
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_APPLICATION_TRAFFIC_READ"
]
},
"unique_id": "01GAJTVWH03QCH0Z8W0RWSKKNJ"
}
The forward json, wich says for me pretty the same
{
"name": "as.up.data.forward",
"time": "2022-08-16T08:03:36.609373716Z",
"identifiers": [
{
"device_ids": {
"device_id": "eui-4aea73b31ed0a60bd2bf02cxxxxxxce6",
"application_ids": {
"application_id": "testapp788"
}
}
}
],
"context": {
"tenant-id": "CgN0dG4="
},
"visibility": {
"rights": [
"RIGHT_APPLICATION_TRAFFIC_READ"
]
},
"unique_id": "01GAJTVWH10AM6XFJS6616D9EH"
}
And you are right i missed the part where it took the key for the device-id…
Hello!
I facing a very similar problem:
My hardware is a Raspberry Pi 4 Model B Rev 1.5 & RAK2245 PIHAT.
During setup, I followed the quick start guide step by step, I have installed the rak_common_for_gateway and configured it in order to connect it with TTN.
I noticed that on TTN the gateway seems to be disconnected.
I checked my journalctl and discovered the following:
Apr 01 10:11:50 rak-gateway ttn-gateway[4887]: WARNING: [main] impossible to open /dev/ttyAMA0 for GPS sync (check permissions)
Apr 01 10:11:50 rak-gateway ttn-gateway[4887]: ERROR: [main] failed to start the concentrator
But, the interface /dev/ttyAMA0 is not available for raspberry pi 4B.
ls: cannot access '/dev/ttyAMA0': No such file or directory
How can I overpass this?
Please let me know if you need more information I can provide you with. Cheers!
This is usually because reset pin assignment is wrong. Check your configuration and the documentation and correct this for the win! 
GPS can be ignored as wont affect GW operation - just set location in TTN Console…
Thank you for the quick reply! Since I’m very new to this, what should I check about my configuration?
I have tried redoing the steps from the guide multiple times to no avail.
The platform selection process should set correctly - if you have chosen the correct one
step4 : Next you will see some messages as follow. Please select the corresponding hardware model.
Please select your gateway model:
- 1.RAK2245
- 2.RAK7243/RAK7244 no LTE
- 3.RAK7243/RAK7244 with LTE
- 4.RAK2247(USB)
- 5.RAK2247(SPI)
- 6.RAK2246
- 7.RAK7248 no LTE (RAK2287 SPI + raspberry pi)
- 8.RAK7248 with LTE (RAK2287 SPI + LTE + raspberry pi)
- 9.RAK2287 USB
- 10.RAK5146 USB
- 11.RAK5146 SPI
- 12.RAK5146 SPI with LTE
Please enter 1-12 to select the model:
step5 : Wait a moment and the installation is complete.
However step through
“sudo gateway-config” to configure your gateway.
And look for the reset pin assignment and make sure it matches the documentation info wrt the 2245 and associated HAT/interface board.
If in doubt you may need to check/edit set up script/json file
1 Like
Oh I see, while configuring the gateway I discovered that it is possible to fix the GPS issue too by setting "gps_tty_path": "/dev/serial0".
And look for the reset pin assignment
By this you mean to look the RAK2245 pinout (like in page 4), and see if it matches the raspberrypi 4 pinout?
If so, I can see that rpi’s GPIO13 is the corresponding pin for RAK2245’s RESET_GPS pin, but what file should I edit in order to fix it? I don’t see a straightforward option inside global_conf.json.
Apologies if the questions are too novice, but I just started getting into this field.
At this point GPS is a ‘dont care’ from TTN operation perspective, and the key task of starting the concentrator, so what you want is GPIO17 = Pi HAT 40 pin connector pin 11 for the concentrator reset (SX130x reset) as shown
I dont use this software for my systems specifically so can’t tell you from memory where to look (did know a while back but caches flushed!), last time I played with it was (I think) the Things Summer Academy, or the months following, a couple of years back! and dont have time right now to go digging… others may step in quickly and point you in the right direction…
1 Like
Closed your other thread! BTW did you try Forum search? (Top right every page)
1 Like
Thanks a lot @Jeff-UK ! I really appreciate it.
I created the other post in case somebody saw it, since in order to get this far in the thread someone must scroll a bit. I’ve been searching for quite a bit I must say but couldn’t find a post that matches my case.
Anyway, I will keep trying until I find this. In the meantime, if another one sees this, any help is welcome!
Also try the RPi SPI speed change trick - its too many years now but IIRC RAK put (logic level shifters?) interface devices in on some early cards (but after original 831/833 types) which slugged the SPI performance and many found slowing SPI down (Raspi-Config?) helped recover the situation, enabling correct comms and reset configs, until later cards came out with corrected designs.
So? And? Does that not provide context and if they open up a topic it’s because they are interested or have something to contribute and will scroll through the thread.
RAK (or indeed any other HAT) on Pi with SPI / reset &/or failed to start concentrator makes regular appearances - search broader than RAK2245 &/or Pi4 - its a generic issue so RAK and Pi will probably give you more material.
Progress Update - not solved yet.
I tried different GPIO options taking into considerations the pinouts by editing in rak_common_for_gateway/lora/start.sh the SX1301_RESET_BCM_PIN. Due to @Jeff-UK answer the default pin GPIO17 should be alright, but I have also tried setting it to 22 since for another user it worked. Still no progress.
Tried to slow SPI speed as recommended in this post + Jeff-UK’s recommendation - Using raspi-config I can only enable/disable the SPI interface. raspi-config edits the /boot/config.txt , but even if I edit it directly, the config.txt file on a Raspberry Pi does not include options for configuring the SPI speed.
By searching some more, I found out that SPI clock speed is usually configured at runtime within the application or the driver that is communicating with the SPI device.
On the other hand the post that I found didn’t specify where I can update this value so I found another post that mentioned a run.py file, which does not exist in the rak_common_for_gateway repo, and looking into it a bit more it was about a different RAK board, not 2245. So I gave up on that approach too.
As a last attempt I tried doing this with
sudo echo 2000000 > `/sys/class/spidev/spidev0.0/device/of_node/spi-max-frequency`
but it didn’t work: Permission denied - must be a kernel restriction.
However, printing the value that is already in the spi max frequency yields a sY@ , which is not a number value, making me think that there could still be a problem with the SPI .
As an alternative to the all those steps above, I followed this guide, trying to install the latest firmware from the RAK wireless website (instead of installing Raspian OS Lite + rak_common_for_gateway). I still I wasn’t able to even login to the board because no RAK_WIRELESS_XXXX access point would show up in the Wi-Fi.
Any idea how could I proceed? Feels like a dead end.
Try a different Pi board, preferably a 3 variant?
Trying a Pi 3 model (or Pi0W) was also going to be one of my next calls but folk have used the Pi 4 successfully so should not be an issue…what may be an issue is flaged by your last post as it reminded me that the '2245 emerged in the no mans land as TTN had just announced the V3 (The Things Stack) implementation and were transitioning over from V2. I recall that many manufacturers were slow to update their firmware images and instructions to reflect the transition with V2 sunsetting and finally being taken behind the shed and shot in Dec '20. (Felt like abandonware for a time!) Are you using current settings for the latest TTS? Correct TTN server settings? (Am assuming as in Greece then eu1.cloud… rather than the old router. address for the TTN server?) Also which DEV/GW EUI are you using for the GW? One derived from the Rpi MAC address (with FFFE padding?) or an alternate Conc card related EUI? (IIRC there was an issue for a time where some card EUI’s were not fully recognised and solution was go the RPi MAC derived EUI route…), finally is the 2245 new? how recently acquired? (through which channel if not RAK direct). Had it been used before by someone else?
1 Like
I see, very interesting insights!
I confirm that I am using eu1.cloud.thethings.network since I am based in Greece. I can see that both inside my gateway config and the TTN’s global_conf.json.
My EUI contains FFFE, but it’s in the middle of it i.e: XXXXXFFFEXXXXXX. If that means I am using the EUI derived from Raspberrypi MAC address, then it should already be ok.
The 2245 is completely new and was bought from RAK directly. I acquired it 1 month ago, March 2024.
It was purchased from the US if that plays a role.
Is there any information I can provide you with? Logs regarding my setup?
Should the TTN’s global_conf.json be exactly the same as the one in my 2245?
If not, to get a raspberrypi3 would be the next option?
And what do they say on the RAK forum / email support??
I’ve got various bits of RAK kit but overall, on here, we are generalists whereas RAK specialise in the RAK2245 …
1 Like
You are right on this! I sent them an email just yesterday and waiting for a response. I will get back to you with updates as soon as I have something 
IT FINALLY WORKED!
So I got some help troubleshooting from the rak wireless support. The problem was that the reset pin was wrong inside /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/start.sh.
(So far I was only editing the reset pin inside rak_common_for_gateway/lora/start.sh, which was not enough).
I removed it,
sudo rm opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/start.sh and then replaced it with the following:
#!/bin/bash
#Reset iC880a PIN
SX1301_RESET_BCM_PIN=17
#Export the GPIO pin
gpioset gpiochip0 $SX1301_RESET_BCM_PIN=0
gpioset gpiochip0 $SX1301_RESET_BCM_PIN=1
gpioset gpiochip0 $SX1301_RESET_BCM_PIN=0
#Run other commands
./set_eui.sh
sleep 0.2
./update_gwid.sh ./local_conf.json
sleep 0.5
./lora_pkt_fwd
Then make it executable:
sudo chmod +x opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/start.sh
Reboot, sudo reboot now and then log back in and check for any errors using journalctl -u ttn-gateway.service -f
To me, the service is finally working, and I can see the gateway on the TTN map!
1 Like