Arduino Mega R3 with Dragino LoRa Shiel 1.4 no JoinAccept with OTAA

My HW: Arduino (RobotDyn) Mega R3 2560
LoRa Hat: Dragino LoRa Shield V1.4
Arduino IDE 1.8.19
My SW: Arduino IDE → Example → MCCI LoRaWAN Lmic library → ttn-otaa
APPEUI[8]= 0000000000000000

TTN Settings
FrequencyPlan: Europe 863-870 MHz (SF12 for RX2) or Europe 863-870 MHz (SF9 for RX2) I’ve tried both
LoRaWAN Version MAC V1.0.3
Activation Mode: OTAA

At the TTN-Applications Console I see “No Activity yet”
Live data window is empty

Arduino Monitor:
Packet queued
253915: EV_TXSTART
647164: EV_JOIN_TXCOMPLETE: no JoinAccept
4410587: EV_TXSTART
4803839: EV_JOIN_TXCOMPLETE: no JoinAccept

If I start it with ABP, everything goes fine

Which switch have I forgotten or set incorrectly?
I am grateful for every tip
Tom from Gwatt(Thun) Switzerland

It would be good to verify the pinmap is correct

FrequencyPlan: Europe 863-870 MHz (SF12 for RX2) or Europe 863-870 MHz (SF9 for RX2) I’ve tried both

This only matters after a join accept is received, or when using ABP. The join process itself always uses LoRaWAN regional default settings, never customizations - selecting the SF9 option only controls how things would work once in a session.

At the TTN-Applications Console I see “No Activity yet”

Next verify that your node registration details are correctly matching between the sketch and the node’s registration in TTN as an OTAA (versus ABP) device.

If I start it with ABP, everything goes fine

Maybe on the uplink side, but that doesn’t mean that downlink is working unless you have specific evidence of that. Today even ABP nodes need to have working downlink to behave properly on the network, but broken downlink probably means complete join failure.

What sort of uplink RSSI and SNR are you seeing when you use ABP? How far away is the gateway?

Which version of LMIC? Hopefully 4.1

The LoRa Alliance guidelines “TR007 Developing LoRaWAN ® Devices” to which a Mr J. Stokking of The Things Industries was party to says we should always use an official EUI so it’s still a mystery as to why the ‘All Zeros’ button exists.

Additionally, some modules & LMIC can’t cope with all zeros anyway and no one here has been motivated to find out why, we take the pragmatic approach, so you can either:

Add a new device, get the console to generate a DevEUI, copy it somewhere safe and then exit (I’d not create a device with the same Dev & Join/App EUI, too confusing). You can then use that official EUI as your applications Join/App EUI.

Or you can generate one using the official not-official guidelines for generating non-official EUI’s here: Random EUI or Key generator

Or you could buy a chip like the Microchip 24AA025E64T that has an official EUI on it that you will then own.

Thanks for the Replay

It would be good to verify the pinmap is correct

// Pin mapping
const lmic_pinmap lmic_pins = {
    .nss = 10,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 9,
    .dio = {2, 6, 7},

What sort of uplink RSSI and SNR are you seeing when you use ABP?


How far away is the gateway?

3.21 Km

LMIN Version: 4.1.0
I used the Device Address of ABP to create a AppEUI =260B0A2A00000000 to not use 0

Hello Tom,
what type of gateway do you use?

There are three ways to create an EUI that is likely to work & be acceptable, this is definitely NOT one of them.

This is more a suggestion that you look at the Dragino website to check the documented pins - it’s unlikely any of us here would know them well enough to verify them for you. Sadly I do, and they are OK.

We ask that people post text for responses as screen shots can end up a bit too tiny for ageing eyeballs. However fuzzy numbers I can see are pushing the limits somewhat.

If you don’t have a gateway, we can’t see if the shield is transmitting OK but we can assume that it is as ABP is getting through. The pinmap is a common point of failure for receiving, but is as per my cheat sheet.

As you say there is nothing in the device console, where we’d at least be looking for a Join Request, then it is likely there is something wrong with your EUIs. If they were correct but the AppKey was wrong we’d see a MIC mismatch. If they were all OK then we’d see a Join Accept on the console even if the shield didn’t pick it up OK.

So it’s likely that the EUI’s are mis-entered in to the LMIC sketch, so that would be the next step, having created a Join/App EUI as recommended above.

Hi, everyone
all the best in the new year. Stay healthy

I don’t own a Gateway. I use one in the area

too tiny for ageing eyeballs

Sorry for That. I descript it:
Upper Line: “Arrow down” 16:06:15 Schedule data downlink for transmissi… MAC Payload 51 xx xx xx xx xx xx 9D… Rx1 Delay 1
Lower Line “Arrow up” 16.06.15 Forward uplink data message Payload: {Loop:0, Temp: 3.04, Volt: 258} 00 01 02 03 04 05 06 07 … FPort:1 Data rate: SF7BW125 SNR: -3.5 RSSI: -115

I under stand: I use the generated DevEUI as the Join/AppEUI?
The DevEUI has 8 Byte the AppEUI has 16 Byte; is this not a Problem?

Yes, but for a device you don’t the use

Yes, it means you are confused about App/JoinEUI and the AppKey.

I’m one step further. I hadn’t considered ‘little-endian format’ for DEVEUI
Now I get “Accept join-request” and “Forward join-accept message” on the TTN console.
But still “EV_JOIN_TXCOMPLETE: no JoinAccept” on the Arduino print out

Good - what is the reported RSSI / SNR for the Join Request.

The most likely problem is your antenna & its placement. The smaller antenna’s on devices may not hear the response.

I come to the same conclusion
I also tried it with Arduino MKR WAN 1300. Same behavior
No SNR and RSSI is displayed. That’s why I programmed ABP again
Now SNR 8.25 and RSSI -107,SNR -2.2 and RSSI -115, SNR 7.25 and RSSI -108 It varies in this area

Look on the web console to see what the gateway is recording.

My problem is solved.
I bought a gateway (Dragino LPS8). Now I see my devices with the sent data.
Thanks for your help!

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