No JoinAccept

I just started tinkering wth Lorawan, so sorry if i’m asking the obvious.

I’m trying to connect a TrackerD Dragino GS tracker to TTNV3 (https://www.dragino.com/products/tracker/item/234-trackerd.html)

The TTNV3 console shows join requests being received and forwarded, and they seem to contain sensible data, but the TrackerD keeps showing through its RS232 interface: no JoinAccept.

The TrackerD should be preprogrammed to join the TTNV3 network, but no joy. I’ve tripple checked the EUI’s and recreated devices multiple times to be sure, but no joy.

I’m located near Rotterdam, surely Lorawan coverage shuld cover most parts of The Neterlands?

One of the Forward join-accpet messages in the TTNV3 console: (xxxxxxxx instead of real Dev eui)

{
“name”: “as.up.join.forward”,
“time”: “2023-08-13T08:41:54.772233633Z”,
“identifiers”: [
{
“device_ids”: {
“device_id”: “eui-a8404186dxxxxxxx”,
“application_ids”: {
“application_id”: “trackerdpeewee”
},
“dev_eui”: “A8404186DXXXXXXX”,
“join_eui”: “A840410000000102”,
“dev_addr”: “260B3283”
}
}
],
“data”: {
@type”: “type.googleapis.com/ttn.lorawan.v3.ApplicationUp”,
“end_device_ids”: {
“device_id”: “eui-a8404186dxxxxxxx”,
“application_ids”: {
“application_id”: “trackerdpeewee”
},
“dev_eui”: “A8404186DXXXXXXX”,
“join_eui”: “A840410000000102”,
“dev_addr”: “260B3283”
},
“correlation_ids”: [
“as:up:01H7Q0Y6TJ9HD4V0RFSEZRGY4N”,
“gs:conn:01H7EH0V415XCVVG9X57X7F0SD”,
“gs:up:host:01H7EH0V44TPWAPYFJAN6KAZGF”,
“gs:uplink:01H7Q0Y523KHCW97A86QKBMX0S”,
“ns:uplink:01H7Q0Y523BNARET5YCYBGTT9V”,
“rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01H7Q0Y523F6TVWB7C5S6881DT”,
“rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01H7Q0Y6THTBTV4FJR8354YVM9”
],
“received_at”: “2023-08-13T08:41:54.769515215Z”,
“join_accept”: {
“session_key_id”: “AYnuDxRJx92YoB98uBqyRQ==”,
“received_at”: “2023-08-13T08:41:52.963932776Z”
}
},
“correlation_ids”: [
“as:up:01H7Q0Y6TJ9HD4V0RFSEZRGY4N”,
“gs:conn:01H7EH0V415XCVVG9X57X7F0SD”,
“gs:up:host:01H7EH0V44TPWAPYFJAN6KAZGF”,
“gs:uplink:01H7Q0Y523KHCW97A86QKBMX0S”,
“ns:uplink:01H7Q0Y523BNARET5YCYBGTT9V”,
“rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01H7Q0Y523F6TVWB7C5S6881DT”,
“rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01H7Q0Y6THTBTV4FJR8354YVM9”
],
“origin”: “ip-10-100-13-164.eu-west-1.compute.internal”,
“context”: {
“tenant-id”: “CgN0dG4=”
},
“visibility”: {
“rights”: [
“RIGHT_APPLICATION_TRAFFIC_READ”
]
},
“unique_id”: “01H7Q0Y6TM6K4P4TPNF7W9C0CF”
}

One of many Serial output:

81387759: EV_TXSTART
81400301: TXMODE, freq=868300000, len=23, SF=10, BW=125, CR=4/5, IH=0
start single rx: now-rxtime: 4
81735861: RXMODE_SINGLE, freq=868300000, SF=10, BW=125, CR=4/5, IH=0
rxtimeout: entry: 81739462 rxtime: 81735854 entry-rxtime: 3608 now-entry: 5 rxtime-txend: 312375
start single rx: now-rxtime: 4
81798361: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0
rxtimeout: entry: 81812714 rxtime: 81798354 entry-rxtime: 14360 now-entry: 5 rxtime-txend: 374875
81812733: EV_JOIN_TXCOMPLETE: no JoinAccept

I’m not sure where to look. I’ve read that every TTN provided AppEUI shoud start with 0x70B3D57ED ](https://www.thethingsnetwork.org/docs/lorawan/address-space.html#applications), clearly thats not the case here.

I would recommend to look for a gateway first. Or do you have your own gateway? What is the distance to this gateway?
If there is no gateway around, you will never succeed in joining TTN.

Things aren’t looking so bad:

  • You’re using OTAA (not ABP), which makes things a bit easier
  • It appears your join request was received by TTN, it was accepted and your device was assigned a device address (260B3283): join/app EUI, device EUI and key are OK
  • TTN has a reserved range of EUIs, but is able to process other EUIs too. So A840410000000102 (for example) should be no problem

I think you should be able to see in the app or device live view of the console which gateway received your join request (and sent the reply). You can then look up this gateway on the map at TTN Coverage . You should also be able to see signal strength and signal-noise ratio.

It it possible that you’re just at the edge of coverage, where a TTN gateway is able to hear receive device, but your device is not actually (or sporadically) able to receive the gateway’s response.

Thanks for the fast reply.

I am located at the red cross in the attached picture, around 10 kilometers away from the densely populated area of Rotterdam in the left of the picture. Range shouldn’t be a problem, i guess?

I’ll try to determine which gateway received the join request.

picture link: heatmap hosted at ImgBB — ImgBB

Edit: i tried an Invoxia GPS earlier but was planning on returing it because it would give location updates very infrequently. But i just put that outside at a high point and seems to start giving location updates now. I thought TTNv3 coverage would be around 100% in the Netherlands, and hopelfully adequate around large cities in Europe. Because, why would bother selling a Lorawan GPS tracker if coverage is sparse? Are my expectations too high?

The community network consists of gateways put up by volunteers and is free to use. Is it realistic to expect volunteers to provide a 100% coverage in NL without any financial compensation?

You can help improve coverage by deploying gateways on TTN. Very much appreciated if you do.

Look at ttnmapper.org to check the estimated coverage in the area you want to use a device.

And for trackers, keep in mind you can only use infrequent updates to stay within the fair use policy (30 seconds of air time a day)

If you need nation wide coverage and more airtime you need to look at commercial entities offering LoRaWAN. At least one Dutch telecom operator operates a nation wide network.

BTW, please upload pictures to the forum, not links to external websites where the person visiting needs to check if it is safe.

Thanks for the fast reply, much appreciated!

I’m aware of the volunteer principle, and appreciate the concept very much. My son used to run a Helium access point, until his AP got corrupted and he gave up.

I’ll go over my options and work out for myself if i want to pursue this any further.