MKR WAN 1300 First configuration

I am following the “First registration of your MKR WAN 1300 or MKR WAN 1310 on TTN” guide. And the FirstConfiguration Example from the MKRWAN.

I get the device EUI, register it on TTN, and try the first config. If I connect via ABP it seems to work fine, but I am not able to see data on my TTN application. On the other hand, if I connect OTAA it is unable to connect, and the message asking if I am indoor comes out.

I have tried with different gateways and different location, and still, the same outcome.

Guide: MKR WAN 1310 Meets The Things Network! - Arduino Project Hub

It’s not connecting - it’s transmitting in to the void, hoping something will hear it.

That is a sort-of-connect - a join request is transmitted in to the void, hoping something will hear it.

The outdoors bit sounds like a message left over from GPS code.

Do you have access to your own gateway - as the simplest thing is to see if the gateway is hearing either mode - on the gateway log itself and also on the gateway console on TTN.

What exactly are the gateways? Are they yours or other gateways in the TTN community? (If they are yours, as Descartes mentioned you can learn a lot by looking at their raw data)

Where are you located, and which regional settings is your node operating with? What about the gateway’s settings?

@cslorabox @descartes Thanks for your replies.

Unfortunately, I do not have my own gateway yet. So, I am connecting to TTN community gateways.
I am located in Copenhagen, and I tried connecting gateways from universities (ITU and DTU).

You don’t connect to a gateway, you transmit and if you are in range, a gateway will hear it.

So there could be any number of reasons why you aren’t getting any uplinks working - almost always people need access to a gateway for debugging their first few devices.

I know how it works, and If I am using that term is because of the threads I have been reading on this forum and the turotials I have been following, “Are you connecting via OTAA (1) or ABP (2)?” i.e.

I do not understand which difference will make debugging with my own gateway first, as I should be able to transmit. If I want to get advantage of another existing gateway I am going to be in the same situation.

You will be able to see the gateway logs and the web console so you will actually know if your device is actually transmitting and if the keys are correct. This is not our first rodeo with helping someone getting going.

Yes, we use the phrase connect, but not to gateways, but to the network. There is no concept of choosing gateways.

Okay, thank you.

That the use I made in my first message, and was the first thing you pointed out, instead of adding it as a comment. :grin:

I’m facing a similar issue…

My RPi gateway with a RAK2245 is connected and visible in my TTN Community console …

My MKR1310 never gets online, double checked the appEUI (all zeros), DevEUI & appKEY … as defined in the Application & embedded device config on the TTN Community console …

The syslog on the gateway seems to suggest a crc failure, and it is configured not to forward bad or missing crc’s …

Got any good references to check out?

Thx

The situation with all zeros has moved a lot over the last few months but generally people have found that an all zero App/JoinEUI tends not to work, particularly with LMIC but this is an older copy of LoRaMAC-node running on the Murata module which may not cope well either.

Try configuring with a non-zero EUI, you can get a random one from here: Random EUI or Key generator

I use LoRaWAN version MAC v1.0.2 with, as I’m in Europe, Regional Parameters of PHY V1.0.2 REV A and the test unit monitoring soil moisture in the terracotta pot outside the office door is chugging away nicely.

1 Like

It would be good if you could show specific examples of those messages, and run some tests with when you power the node to make sure that they are time correlated. One possibility could be the node being too close to the gateway.

Thanks for the input, will make changes accordingly and try again. Am EU based and using the EU868

Read somewhere that bad-crc may be just a non-LoRa device operating in the ISM spectrum … my doorbell comes to mind …

Hey @Peter_Depuydt I wonder if you eventually found a solution to your connection problems and actually remember it :wink: Thank you!

same…wondering the same. I tried following these instructions but still no success on my end.

If your referring to the instructions quoted in the first post, then you could take the problem up with Arduino, they produce the MKR WANs and run the project hub that has the instructions. Maybe they dont know people are having issues with them ?

On another one of these MRK WAN threads I explicitly tested the Arduino instructions and found them to be acceptable.

There are so many points raised in this and other “can’t connect” threads that you could address - or at least look at this one and comment on such things as gateway ownership & location.

1 Like

Hi
I have a concern regarding this same problem.
I have a Getaway Milesight UG 67 LORA
and as node I am using an arduino mkr wan 1300.
I follow all the steps in TTN and in fact the gateway is already registered and working, but I carry out the configuration that is recommended in the arduino forum for the node and it does not connect
any advice ?

What tells you that? The serial log or the console? And precisely what do they say?

And with a little forum search of “does not connect”, you’ll find us asking how far apart the gateway & device are.

But @Johan_Scheepers will come along shortly to go in to detail to help you out.

Yes shortly with 400km in-between traveling around somewhere in South Africa.

Google to the help :wink: or is that ChatGpt

Most common reasons for newbies nodes not joining, the RSSI is to high causing channel bleed and overloading the RX front-end. Move the node 10m to 15km from the gateway and preferably if the distance is short have a brick wall inbetween. RSSI need to be below -60 or so preferably.

After all LoRaWAN stands for low power long range radio acess, with a bit of IP somehere in-between.

1 Like

He meant meters!