No Payloads received ON TTN Gateway and Application

On TTN I am receiving

GATEWAY in TTN

JoinEUI
D9338691871F2 :smiley::smiley::smiley: (smily face so I dont share the joinEUI but it is correct)

DevEUI
353131395637:smiley::smiley::smiley: (smily face so I dont share the DevEUI but it is correct)

Data rate
SF10BW125
SNR
8.5
RSSI
-111

APPLICATION on TTN

I’m receiving Device ID

Forward join-accept message

DevAddr 260DCB ::smiley::smiley: (smily face so I dont share the Dev Addr but it is correct)

Successfully processed join request

Accept join request DevAddr

260DCB ::smiley::smiley: (smily face so I don’t share the Dev Addr but it is correct)

I can’t see any payloads?

The device is set up as OTA v1.0.3 and is on
Australia 915-928 MHz, FSB 2 (used by TTN)

Any ideas would be greatly appreciated.

If join accepts are coming through, then it appears that at least your gateway is working, and you set up the dev eui, app eui and app key in the node (and TTN console) correctly.

What kind of device do you have?
Does it receive and process the join response?
Are you sure it is sending a payload?

Hi Thanks for the response,

I have a water meter and lora A923.
In regards to join response all i can see is the following?

APPLICATION on TTN

I’m receiving Device ID

Forward join-accept message

DevAddr 260DCB ::smiley::smiley: (smily face so I dont share the Dev Addr but it is correct)

Successfully processed join request

Accept join request DevAddr

260DCB ::smiley::smiley: (smily face so I don’t share the Dev Addr but it is correct)

Hi Guys this is the Join Accept

{
“name”: “js.join.accept”,
“time”: “2023-07-10T15:27:06.974439876Z”,
“identifiers”: [
{
“device_ids”: {
“device_id”: “eui-35313139563xxxx”,
“application_ids”: {
“application_id”: “netvendorwmd”
},
“dev_eui”: “353131395637xxxx”,
“join_eui”: “D9338691871xxxx”,
“dev_addr”: “260DExxx”
}
}
],
“correlation_ids”: [
“rpc:/ttn.lorawan.v3.NsJs/HandleJoin:01H506KQ6TGJXZHZDYKTCYYDWA”
],
“origin”: “ip-10-102-12-29.ap-southeast-2.compute.internal”,
“context”: {
“tenant-id”: “CgN0dG4=”
},
“visibility”: {
“rights”: [
“RIGHT_APPLICATION_TRAFFIC_READ”
]
},
“unique_id”: “01H506KQ6YCQ6WMEFYXQKH423P”

And this is the forward accept message:

{
“name”: “as.up.join.forward”,
“time”: “2023-07-10T15:27:08.783591551Z”,
“identifiers”: [
{
“device_ids”: {
“device_id”: “eui-353131395637xxxx”,
“application_ids”: {
“application_id”: “netvendorwmd”
},
“dev_eui”: “353131395637xxxx”,
“join_eui”: “D9338691871Fxxxx”,
“dev_addr”: “260DExxx”
}
}
],
“data”: {
@type”: “type.googleapis.com/ttn.lorawan.v3.ApplicationUp”,
“end_device_ids”: {
“device_id”: “eui-353131395637xxxx”,
“application_ids”: {
“application_id”: “netvendorwmd”
},
“dev_eui”: “353131395637xxxx”,
“join_eui”: “D9338691871Fxxxx”,
“dev_addr”: “260Dxxxx”
},
“correlation_ids”: [
“as:up:01H506KRZAAFVP6935PHMC8XYX”,
“gs:conn:01H5050SEBJ3F4FGGV6X9C665E”,
“gs:up:host:01H5050SPMKFD3108EF51MJVS1”,
“gs:uplink:01H506KQ6N22SMR9MH0KXY9A72”,
“ns:uplink:01H506KQ6Q4G7DRWNEQANMFJEE”,
“rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01H506KQ6P5TCBBH81RMMZ1NBY”,
“rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01H506KRZ92JDAJQ8ZXKF69GR9”
],
“received_at”: “2023-07-10T15:27:08.778040993Z”,
“join_accept”: {
“session_key_id”: “AYlAadzccegNiMRo83MRXg==”,
“received_at”: “2023-07-10T15:27:06.967121687Z”
}
},
“correlation_ids”: [
“as:up:01H506KRZAAFVP6935PHMC8XYX”,
“gs:conn:01H5050SEBJ3F4FGGV6X9C665E”,
“gs:up:host:01H5050SPMKFD3108EF51MJVS1”,
“gs:uplink:01H506KQ6N22SMR9MH0KXY9A72”,
“ns:uplink:01H506KQ6Q4G7DRWNEQANMFJEE”,
“rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01H506KQ6P5TCBBH81RMMZ1NBY”,
“rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01H506KRZ92JDAJQ8ZXKF69GR9”
],
“origin”: “ip-10-102-6-80.ap-southeast-2.compute.internal”,
“context”: {
“tenant-id”: “CgN0dG4=”
},
“visibility”: {
“rights”: [
“RIGHT_APPLICATION_TRAFFIC_READ”
]
},
“unique_id”: “01H506KRZF49BX5S8MBZPX77TX”
}

Please stop redacting with smiley faces - it makes reading technical information harder.

The DevAddr is not unique & isn’t a thing in almost any issue - it’s only used to match incoming uplinks and the Join & Dev EUI are of public record. It’s only the AppKey you should not disclose.

Please use the formatting tool </> on the toolbar for logs & information.

You haven’t answered the two of the questions asked of you in your last responses.

As you have noted, duplicate posts are not a good idea - how do we know where to respond or get new information. Please stick to this thread.

Hi Descartes,

Noted.

I have answered where I could.

1.The end device is a water meter
2. In regards to receiving and process of the join in not sure I’m assuming so please see below responses
3.The manufacturer assures me that it is sending a payload.

Accept Join Request

{
  "name": "js.join.accept",
  "time": "2023-07-10T22:37:44.927515833Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "eui-3531313956378202",
        "application_ids": {
          "application_id": "netvendorwmd"
        },
        "dev_eui": "3531313956378202",
        "join_eui": "D9338691871F2B02",
        "dev_addr": "260DBECA"
      }
    }
  ],
  "correlation_ids": [
    "rpc:/ttn.lorawan.v3.NsJs/HandleJoin:01H50Z87JW2EX6W8SS4EFV688X"
  ],
  "origin": "ip-10-102-12-29.ap-southeast-2.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01H50Z87JZ5BEY41ECC6A8S3GG"
}

Successfully processed join request

{
  "name": "js.join.accept",
  "time": "2023-07-10T22:37:44.927515833Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "eui-3531313956378202",
        "application_ids": {
          "application_id": "netvendorwmd"
        },
        "dev_eui": "3531313956378202",
        "join_eui": "D9338691871F2B02",
        "dev_addr": "260DBECA"
      }
    }
  ],
  "correlation_ids": [
    "rpc:/ttn.lorawan.v3.NsJs/HandleJoin:01H50Z87JW2EX6W8SS4EFV688X"
  ],
  "origin": "ip-10-102-12-29.ap-southeast-2.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01H50Z87JZ5BEY41ECC6A8S3GG"
}

If this was a car forum, would you say “I have a car” when asking for assistance for a technical issue?

Hi Descartes,

Mate this is the firs time I have ever posted on a forum!
Not here for an argument! .I’m looking for solutions not problems.

The device is a water meter that is on frequency AS923 brand name cs

I have been given the device Id 3531313956378202 and an app key from the manufacturer CS.
And have been told to set it up OTAA as Lora specification V1.0.3 Rev A

That’s all the information I have.

1 Like

If you’re only seeing Join messages the device probably does not receive a join accept. We’ve seen reports of gateways not transmitting for some obscure reason, that might be your issue as well. If you own the gateway you could try resetting it.

Hi Kersing,

The gate way is a Browan please see:

Setup-the-BROWAN-Femto(OPDK-Basic-Station-ver.)-to-Access-TTN-Stack-v3-Server_v2.pdf

The strange thing is that on the TTN application side, The DevAddr (8 digit number) keeps changing after 2 or 3 attempts. The device however isn’t is this normal? I thought the DevAddr (8digit number) should stay constant?

On the Gateway side off TTN the Credentials are constant.
Please see attached photo.

When setting the device up on OTTA:
What should the Join EIU be:
What should the DevEIU be:

On the end device it has a label with

Application EIU: D9:33:86:91:87:1F:2B:02 ( I used this as as Join EIU)
Device ID: 3531313956378202 ( I used this as as Dev EIU)
Application key: (32 digits xx:xx:xx:xx:xx:xx:xx:xx:xx:xx) (I used this for applicaton key)

Could it be the way it has registered? Could it be the frequency and channel set up on the gate way.

And how do you propose people make suggestions about “a water meter” from a manufacturer called “cs” with multiple random posts over the forum - slow down and accept guidance.

Totally normal and as I said above, hardly relevant.

The solution to this problem is specifity - you’ve been overly specific about the red herring of the DevAddr but you can’t tell us the exact make & model number of the water meter? A link to the manufacturers site would go a very long way. That will give us all sorts of hints, like if we’ve seen issues in the past with it and, as above, the likely antenna placement that may well not be hearing the join accept.

How far away is the device from the gateway - can you move them closer to test the issue? What antenna has it got?

Please do not upload files that can be linked to - there is limited file space & there are security issues for anything other than text or images that come from users computers.

That is consistent with the device not receiving the JoinAccept and retrying to join.

Yes? And Browan gateways can not have issues? What are you trying to tell me?
I suggested to reset the gateway (or restart or whatever you want to call it) so it is in a known ‘good’ state.

HI Kersing, I have restarted the gateway, by disconnecting power waiting and reconnecting it and have the same issue.

I understand hardware can have issues, all I was pointing out was the Model of the gate way and the documents I have of it to share it with you. I was hoping you would say yes we have encountered lots of issues with the gate way.

Hi, The gateway and the water meter are currently about 10 meters apart.
I have tried it at 1m apart as well as 100 meters apart. The antenna is an 6dBi Antenna. I have tried having it connected as well as disconnecting it from the gateway and the issue is still present.

Please dont! If already done and your GW has attempted to TX - e.g. sending the Join accept etc. there is every chance you may have damaged the GW RF output - they must always be used with a load (ant) - or may have induced longer term reliability issues. If you are lucky you may have gotten away with it!

Try increased seperation - more than 10m to compensate for fact you have used a higher gain ant, which may also have induced nulls in coverage BTW. A basic 2-3.15dbi ant is usually sufficient… try and get an absorber in between - wall, window etc and let us know what RSSI values you are seeing in the console, similarly try (a bit) closer as Nick suggested, though if too close you risk overloading front ends cause distortion,saturation and potential channel bleed meaning device wont hear join accept on correct channel and will keep trying.

Above all as previously requested details are everything and so would be helpful if you could tell us more on what devices, firmware versions, links to docs etc. as the Forum volunteers cant be expected to either have crystal balls or to go off and do your research for you - you need to provide info (please!) :slight_smile:

Hi Jeff thanks for this information much appreciated. Here is the latest response from TTN

Data rate: SF10BW125
SNR: 11.2
RSSI: -59

I have now put the device behind multiple walls 2 concrete walls to be specific and is around 30 meters away.

{
  "name": "gs.up.receive",
  "time": "2023-07-11T10:15:58.527610299Z",
  "identifiers": [
    {
      "gateway_ids": {
        "gateway_id": "00005813d398ac0d",
        "eui": "00005813D398AC0D"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.GatewayUplinkMessage",
    "message": {
      "raw_payload": "AAIrH4eRhjPZAoI3VjkxMTWCVN3GPpU=",
      "payload": {
        "m_hdr": {},
        "mic": "3cY+lQ==",
        "join_request_payload": {
          "join_eui": "D9338691871F2B02",
          "dev_eui": "3531313956378202",
          "dev_nonce": "5482"
        }
      },
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 10,
            "coding_rate": "4/5"
          }
        },
        "frequency": "923200000",
        "timestamp": 2218056028
      },
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "00005813d398ac0d",
            "eui": "00005813D398AC0D"
          },
          "timestamp": 2218056028,
          "rssi": -59,
          "channel_rssi": -59,
          "snr": 11.2,
          "uplink_token": "Ch4KHAoQMDAwMDU4MTNkMzk4YWMwZBIIAABYE9OYrA0Q3LLToQgaDAje17SlBhD1mrb7ASDgnsTzxpAQ",
          "channel_index": 1,
          "received_at": "2023-07-11T10:15:58.513686807Z"
        }
      ],
      "received_at": "2023-07-11T10:15:58.527273333Z",
      "correlation_ids": [
        "gs:conn:01H50B3S93WNN50KHTNWRD0HRQ",
        "gs:uplink:01H5276Q9ZZVNN6T83HRJNN1HF"
      ],
      "crc_status": true
    },
    "band_id": "AU_915_928"
  },
  "correlation_ids": [
    "gs:conn:01H50B3S93WNN50KHTNWRD0HRQ",
    "gs:uplink:01H5276Q9ZZVNN6T83HRJNN1HF"
  ],
  "origin": "ip-10-102-5-95.ap-southeast-2.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_GATEWAY_TRAFFIC_READ"
    ]
  },
  "unique_id": "01H5276Q9Z997YA3FET6GPRJH0"
}

Could it be the Chanel and frequency set up on the gateway that I have set up wrongly.

We haven’t encountered lots of issues with that model, however there have been some issues if I recall correctly. Forum search is you friend.

Any chance of testing with a different gateway?

With regards to the gateway setup, make sure your values match the TTN frequencyplan. You can download a json version on the gateway page that should list the values to be used. Your current values look off to me.

Knowing the make & model of the water meter may will be illuminating.

Just say’n

At this stage I don’t have another gateway to test with :frowning:

The TTN network plan is 915 - 928 MHz, FSB 2 (used by TTN ) I Have used this plan for gateway and application settings in TTN.

However the water meter is labelled Lora AS923.

The Bowan Gateway JSON is below: I hope this is what you have requested as it was the only page I found that had JSON on it which was under Lora module LOG.

JSON up: {"rxpk":[{"tmst":4221786804,"chan":6,"rfch":1,"freq":923.200000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":12.5,"lsnr_min":10.5,"lsnr_max":15.2,"rssi":-65,"size":23,"data":"AAIrH4eRhjPZAoI3VjkxMTVccnlDoKk="},{"tmst":4221786804,
"chan":5,"rfch":1,"freq":923.200000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":13.5,"lsnr_min":11.2,"lsnr_max":16.5,"rssi":-67,"size":23,"data":"AAIrH4eRhjPZAoI3VjkxMTVccnlDoKk="},{"tmst":4221786804,"chan":4,"rfch":1,"freq":923.200000,"
stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":13.0,"lsnr_min":10.8,"lsnr_max":15.2,"rssi":-65,"size":23,"data":"AAIrH4eRhjPZAoI3VjkxMTVccnlDoKk="},{"tmst":4221786804,"chan":2,"rfch":0,"freq":923.200000,"stat":1,"modu":"LORA","datr":"SF10BW1
25","codr":"4/5","lsnr":12.8,"lsnr_min":11.2,"lsnr_max":15.2,"rssi":-65,"size":23,"data":"AAIrH4eRhjPZAoI3VjkxMTVccnlDoKk="},{"tmst":4221786804,"chan":1,"rfch":0,"freq":923.200000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":13.8,"lsnr_mi
n":11.8,"lsnr_max":16.8,"rssi":-67,"size":23,"data":"AAIrH4eRhjPZAoI3VjkxMTVccnlDoKk="}]}

Do you have another device, preferably a known good brand, to check the gateway &/or general setup?