Dragino Tracker-D no Join Accept


I recently acquired the TrackerD LoRaWAN Tracker. Unfortunately, I’m having difficulty determining the firmware version. The device is powered and placed in the roof space.

I’m encountering issues with joining TTN using the OTAA process.

Following Dragino’s instructions for setting up the end device, the TTN live data console displays a continuous loop of 'Forward join-accept message - Accept join-request - Successfully processed join-request’ messages with about 20 minute intervals.

I attempted to delete the device and resubmit it for both Europe 863-870 MHz (SF9 for RX2) and SF12 for RX12, carefully verifying that the keys are correct but end up with the same loops.

Here’s a log from from the TrackerD:

[13:56:38:753] 339373642: EV_TXSTART␍␊

[13:56:38:753] 339373715: TXMODE, freq=868500000, len=23, SF=12, BW=125, CR=4/5, IH=0␍␊

[13:56:45:236] start single rx: now-rxtime: 3␍␊

[13:56:45:236] 339778782: RXMODE_SINGLE, freq=868500000, SF=12, BW=125, CR=4/5, IH=0␍␊

[13:56:45:466] rxtimeout: entry: 339793131 rxtime: 339778772 entry-rxtime: 14359 now-entry: 5 rxtime-txend: 312375␍␊

[13:56:46:236] start single rx: now-rxtime: 3␍␊

[13:56:46:236] 339841282: RXMODE_SINGLE, freq=869525000, SF=12, BW=125, CR=4/5, IH=0␍␊

[13:56:46:468] rxtimeout: entry: 339855632 rxtime: 339841272 entry-rxtime: 14360 now-entry: 5 rxtime-txend: 374875␍␊

[13:56:46:468] 339855654: EV_JOIN_TXCOMPLETE: no JoinAccept␍␊

Additionally, here’s a snippet from the TTN console of a ‘ successful join-request’ message:

“settings”: {“data_rate”: {“lora”: {“bandwidth”: 125000, “spreading_factor”: 12, “coding_rate”: “4/5”}},

“frequency”: “868100000”, “timestamp”: 3167072388, “time”: “2023-12-11T14:49:36.560217Z” },

“rx_metadata”: [{“gateway_ids”: {“gateway_id”: “xx”, “eui”: “xx” },

“time”: “2023-12-11T14:49:36.560217Z”, “timestamp”: 3167072388, “rssi”: -119, “channel_rssi”: -119,

“snr”: -15.8, “uplink_token”: “CiMKIQoVcGF1bC10YW5uZXItYnVnZ3ktYWlyEggAAAJLCwMPZxCE4ZbmCxoMCIDD3KsGELn6r6ECIKCH5qGW+u0C”,

“received_at”: “2023-12-11T14:49:36.606862649Z” } ],

“received_at”: “2023-12-11T14:49:36.607777638Z”,

“correlation_ids”: [“gs:uplink:01HHCNNQJZ613KCECTS5C99C0W” ],

“consumed_airtime”: “1.482752s” },

“correlation_ids”: [“gs:uplink:01HHCNNQJZ613KCECTS5C99C0W” ],

“origin”: “ip-10-100-7-123.eu-west-1.compute.internal”,

“context”: { “tenant-id”: “CgN0dG4=” },

“visibility”: { “rights”: [“RIGHT_APPLICATION_TRAFFIC_READ” ] }

I would greatly appreciate any insights or assistance. Thank you.

What is the distance to the gateway? RSSI and SNR seem to be very low.

1 Like

hi, the nearest is around 550M away according to the TTN map. I am in a built up area.

Please ensure you format any logs or JSON or text or code with the </> going forward.

As above, your RSSI is close to reasonable limits & your SNR is disastrous.

550m in an urban area for a gateway (which generally have decent antennas on them) isn’t unsurprising - there may well be all sorts of things in the way. Conversely the device has a tiny antenna and is clearly not hearing the Join Accept - if you search the forum for that phrase your post would have been redundant - it comes up weekly.

Using a tracker on TTN is pretty pointless - the Fair Use Policy will prohibit you uplinking enough for live tracking - “Where is my asset” should be OK.

Redacting the gateway id prohibits us helping you. The only secret to redact is the AppKey of a device - everything else is public data.

Overall, anyone starting out with LoRaWAN makes best progress by having their own gateway - a TTIG is around €/£/$ 90 and saves hours of debugging.

Thank you for the swift response Nick.

My intention was to trial this service first, “where is my asset” perhaps updated hourly would be fine. I appreciate the advice concerning just redacting the Appkey. Below is the code again for your information.

  "settings": {
    "data_rate": {
      "lora": {
        "bandwidth": 125000,
        "spreading_factor": 12,
        "coding_rate": "4/5"
    "frequency": "868100000",
    "timestamp": 3167072388,
    "time": "2023-12-11T14:49:36.560217Z"
  "rx_metadata": [
      "gateway_ids": {
        "gateway_id": "paul-tanner-buggy-air",
        "eui": "0000024B0B030F67"
      "time": "2023-12-11T14:49:36.560217Z",
      "timestamp": 3167072388,
      "rssi": -119,
      "channel_rssi": -119,
      "snr": -15.8,
      "uplink_token": "CiMKIQoVcGF1bC10YW5uZXItYnVnZ3ktYWlyEggAAAJLCwMPZxCE4ZbmCxoMCIDD3KsGELn6r6ECIKCH5qGW+u0C",
      "received_at": "2023-12-11T14:49:36.606862649Z"
  "received_at": "2023-12-11T14:49:36.607777638Z",
  "correlation_ids": [
  "consumed_airtime": "1.482752s"
"correlation_ids": [
"origin": "ip-10-100-7-123.eu-west-1.compute.internal",
"context": {
  "tenant-id": "CgN0dG4="
"visibility": {
  "rights": [

The gateway id doesn’t have a public location or height so commentary on coverage/terrain isn’t possible. It is reasonable to assume that a TTN gateway will be on the recommended settings. Fundamentally your antenna needs a direct unimpeded line of sight to the gateway antenna. If it’s not your gateway there is some guesswork on that.

But all the above applies, your signal ain’t great for a device known to have an average antenna - forum search on Tracker-D will reveal more details.

We don’t tend to think in terms of trialing the service - we don’t pay for it and it’s well proven for its applications, TTN is about community connectivity via gateways at home & work and then using off-the-shelf & DIY devices to do stuff. The Learn pages outline the typical uses for LoRaWAN that work. If you tell us what you have in mind people can comment further.

1 Like

Hi @srg774 unless it has moved I think I know the GW and the host (and ultimate owner/org). I assume you are based in the South Bucks area or somewhere with a northern Slough area post code or at least just about in range of the Chalfonts (St. Peter or St.Giles)? As Nick has observed its not readily identifiable under TTS(CE) aka TTN V3 - as I believe it is still running under an old V2 instance. It is/was lent to and hosted by one of the South Bucks/Bourne End and Cookham Community members - Paul Tanner (surprise surprise) - and was physically mounted at a school in the area. The original use case/development Paul was working on was a mobile air quality monitor that was attached to prams (hence buggy) and similar being pushed by mums and dads taking their offspring to school so they could map and then hopefully avoid or potentially mitigate for (traffic induced) pollution in the local areas and the routes to local schools.

Whilst the project has long since been mothballed last time I met with Paul I understood the GW was still in place (and clearly still operating!). It was supplied to him and owned by the Digital Catapult team. Though I dont think it or many others are actively monitored or managed. Paul did suggest they (DC) hand off management to me so I could bring over to V3 and run as a more useful contribution to the local community. In a later meet with DC I offered to undertake the task of migrating all the (still deployed) UK wide DC GW’s over to V3 and to update the map/location data so they would again become visible, and a better utility, to the TTN community, but they seem to have moved on (5G/6G focus) and never took me up on the offer, despite a prompt or two.

Wrt your poor signal strength, this is not suprising as the area around the Chafonts (Chiltern Hills) is, well, hilly and you dont need to go far or decend into one of the local valleys to find you loose signal or have weak strength.

If you are mobile a short trip over to Gerrards Cross might put you in range of one my own GW’s (head to the area between the Rail Station and the Lawn Tennis club - I know coverage is good around there - and atleast try and see if you can join more readily. Another option is there is a TTIG (not one of mine) deployed over near Seer Green though I havent had much time to look at mapping that one…if closer to you may be easier than the Laird I have in G-X.

Am overdue contacting Paul again so will see what current GW status is. (It’s a Kerlink GW) As a DC GW the admin fell to DC team, under the now defunct (from around the time of the V2-V3 transition) ThingsConnected initiative, but I think he may have had collaboration right allowing him to see traffic, so he may be able to help with sight of what GW sees from your device on management console view.

…reminds me I should contact DC again as I think there are still many - maybe dozens of GW’s scattered around the country but still not visible in TTN V3 or on community maps, though many were effectively ‘given’/handed off to the local/sponsoring users/companies.

Finally, please revert to using SF9 (as recommened for TTN) for RX2 - there are limits on using SF12, its not very spectrum or community friendly, and L-A requires/advises operators to limit joins with SF11/12 where practical.

someone did something


one of those one that were 1/2 done

Indeed, that was the scenario for many. IIRC DC had an LNS instance of their own (same for JANET I believe) and likely peered in through PacketBroker - hence GW ID visible vs just a PB GW reference in received metadata. Last updates were sometime Q4’21 (mid COVID!) about a year after V2 sunset around the time the DC initiative wound down. There are quite a few orphans - parental instincts kicking in again…I need to get them a home :rofl: Key is they are (mostly) still passing traffic so have some utility to the Community :slight_smile: Several in London & S.East, Northumberland/N.East, N. Ireland etc. (latter routed through a local BBand provider and think original deal may have ended so may not be functional wrt backhaul…)

Looking at location data either was faked/offset for security or may have been moved from original school site…will try to find out status as above.

Hi Jeff, this is great feedback. I was wondering what ‘buggy air’ was and now it is fully explained. I actually live in Uxbridge about halfway up hill to the Common but have a view over Fulmer so the hill seems to be blocking the local gateway. I actually reverted the settings and walked towards the local gateway, reactivated and came back home to find an ‘update end device’ message with a snippet here "name": "end_device.update", "time": "2023-12-12T08:56:39.609848414Z", "identifiers": [
the forward uplink message looked complete here is another snippet: "rx_metadata": [ { "gateway_ids": { "gateway_id": "uxb-common-01", "eui": "58A0CBFFFE801CF2" },
As was previously mentioned, It makes sense enable a gateway at my home location so I can meaningfully progress with the further developments. I probably need to send some AT commands to the device to so the uplinks within fair use.

1 Like

Thats the usual recommendation for anyone looking to do dev work :+1: (and it helps build/fill in the network :wink: )

BTW I did some mapping over Uxbridge way on the 30th Nov. Approached from MWay/Oxford Road and did a couple of runs up and down High St/Belmont Road and got just 1 hit! So assume coverage in your area is poor! Only pick up was (I think) from a TTIG near Park Road at top of the hill (appears to be the one that captured your snippet :slight_smile: ) - had 7 trackers with me (4 types) on the day and only one of the original Semtech LoRaMOTEs pinged. The Dragino LGT-92 I had with me (predecessor to the Tracker-D, similar antenna (poor)) saw nothing. (Likely also as duty cycle/update rates too low (FUP etc.!) to cover all ground where driven - no TX when near the TTIG?)


Obviously we are a bit off topic now! And sounds like you finally had a network join :wink:

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.