I think thats the way to go. I cannot find anything by searching the web and also no issue here on the forum. I will update you if i get any reply.
Thank you
Why can’t you just look at the console logs for the gateway and the device as requested above - why add more, more is not good, simple is better - it’s “Live Data”
Not as a screen shot, because we never post screen shots when we can copy the text and then we format it with </>
Just turn off the payload formatter, it is clearly wrong or not for your device.
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.
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.
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…
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.