RAK2245 PIHAT on Pi4 gateway won't connect

Thats a good one thank you!
To which json i need to add this?

I searched and found this when i selected the device and opened the payload formatter menu. As type is selected “use device repository”

function decodeUplink(input) {
    var bytes = input.bytes;

    switch (input.fPort) {
      case 100:
        return {
          data: {
            status: bytes[0] & 0x01,
            battery: (25 + (bytes[1] & 0x0f)) / 10,
            temperatureBoard: (bytes[2] & 0x7f) - 32,
            time: (bytes[4] << 8) | bytes[3],
            count: ((bytes[7] << 16) | (bytes[6] << 8)) | bytes[5]
          }
      };
    default:
      return {
        errors: ['unknown FPort'],
      };
    }
  }

If you lookin in the live view of application and select the message, scroll down the json, there are quit a few fields and lots of information in it.

Unfortunatly this is all i got when i select a message from the live data.

{
  "name": "as.up.data.decode.fail",
  "time": "2022-08-16T08:06:23.494504725Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "eui-4aea73b31ed0a60bd2bf02cxxxxxxce6",
        "application_ids": {
          "application_id": "testapp788"
        }
      }
    }
  ],
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01GAJV0ZG6C95TY5CXVPWCAJRZ"
}

EDIT: i think i see what you mean in the documentation. Can this be caused by the device repository formatter? There are many fields missing

Look in the Forward Uplink Data Message.

You will need to search for the correct decoder and fix that.

What node are you using a Browan?

Correct i am using a browan tbdw100

You will maybe need to contact them and ask them for the correct decoder.

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.

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! :slight_smile: 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

image

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.