MKR1310 on chirpstack v3

I have an RAK7244 running chirpstack v3. It collects LoRaWAN data from various sensors (weather station) and sends MQTT data to a server.
I would like to join my Arduino MKR1310 to the gateway but, not being a programmer, I don’t know where to get the various key and eui information to set it up.
If someone is familiar with this Arduino unit on chirpstack, I would appreciate some guidance. I haven’t configured to MKR to do anything specific yet and only want to get it connected. Thanks in advance.
Bob

Im not sure about that specific Arduino but if you don’t have a devEUI or appKey you can always just make them up. As long as your devEUI and appKEY match between the device and Chirpstack it should be able to join.

DevEUI is a 16 character hex string. Each LoRaWAN manufacturer has an assigned range of devEUIs such that each one is unique, so if a device joins a public network there won’t be two with the same devEUI, but since you are on a private network you do not have to worry about this constraint and can use any value as long as doesn’t conflict with another device you have.

Appkey is a 32 character hex string and is randomly generated for each device. These should be completely random and there is no constraint on overlap. So you should just make one up and set it in both chirpstack and the device.

To test I typically use:

DevEUI: 0102030405060708
AppKey: 01020304050607080910111213141516

Thanks, Liam, I’m getting something like this:
Welcome to MKRWAN1300/1310 first configuration sketch Register to your favourite LoRa network and we are ready to go! Your module version is: 1.3.0.0 Your device EUI is: 39:30:31:30:52:31:79:08 Are you connecting via OTAA (1) or ABP (2)? Enter your APP EUI
The instructions are for joining TTN but nothing for chirpstack that I can find. It gives me the devEUI but nothing more. It seems setting up TTN will supply the other required keys and eui. As mentioned, I’m not skilled in this. Do I just make up the other requirements for chirpstack?
Cheers,
Bob

The appEUI they are referring to here is also known as the appKey (the names of the keys have changed throughout the different LoRaWAN versions). This and the devEUI are the only required keys to connect to Chirpstack. When adding a device in Chirpstack there is also the option for a joinEUI, but that is only for if you have an external join server, in default Chirpstack you can put any value in joinEUI and it will make no difference.

So you will want to take that devEUI: 3930313052317908 and then just make up an appKey, you could use a random number generator for this.

Those two keys are the only keys necessary for joining in Chirpstack, all of the other session keys will be generated from these keys.

Thanks, Liam, I’m going to delete what I have setup in chirpstack and start again. Your explanation is helpful to my understanding.
TTN setup data seems to be the most available information for most devices but I picked chirpstack as it was local, and I didn’t see why anyone would be interested in following the temperature in my crawl space or living-room. Can TTN be run locally?

What do you mean by TTN setup data? While most guides for devices are for TTN setup: the keys, device specifications, device onboarding, etc are all regulated by the LoRaWAN specifications so the ideas are the same between the two platforms.

I believe there is a paid membership for a “private” lorawan network. Whether this means its run locally or simply seperated from the rest of the public network I’m not sure.

Liam,
By setup, I was referring to the directions on how to setup and join TTN. In most cases, there are step by step instructions for each device.

Anyway, while I have your helpful ear, I have some more questions.

There are several things to setup in chirpstack. For example most of my devices supplied information such as LoRaWAN MAC version and LoRaWAN Regional Parameters revision which are required in the device profile. Is there a general setting which will work if I don’t have the specs?

I have my device eui from Arduino and you indicate that the app eui is the same as app key which I have made up. However, it is also asking for both an app eui and some other app key which I need to supply but don’t have. Do I also make up one of these?

Your module version is: 1.3.0.0
Your device EUI is: 39:30:31:30:52:31:79:08
Are you connecting via OTAA (1) or ABP (2)?
Enter your APP EUI
Enter your APP KEY
Sorry to be so dense here but this is very new to me. Please don’t hesitate to tell me to get lost if you don’t have time.
Cheers Bob

Don’t worry about it Bob, happy to help.

Unfortunately not, having the wrong MAC or regional parameters revision can cause errors with the device communication, so you need to make sure these are correct for each device type you have. If you haven’t already though you should import the device repository from this guide: Device-profile templates - ChirpStack open-source LoRaWAN® Network Server documentation

It’s outdated as it is a fork from TTNs device repository before they made it illegal to import (I think 2ish years ago) so it’s not always reliable and is missing devices but is still a valuable resource for many devices and allows you to import their device profiles.

The appEUI does not need to be the same as the appKey, I typically have the appEUI at all 0s, but the value does not matter and doesn’t even need to match in Chirpstack. Whereas the appKey is what is used to generate the LoRaWAN session keys and must be the same on the device and Chirpstack.

I assume you mean the device is asking for more keys, not Chirpstack? I don’t know what other keys it would require, maybe if you gave some more context or the names I could tell you.

To join with Chirpstack (or TTN) over OTAA the only keys required should be the devEUI and the appKEY. My hunch is the device wants to join over ABP instead, which requires you to specify each of the session keys (instead of OTAA where these are generated based off the appKey, and changed with each new join). Do you know if this is the case?

Thanks, Liam, let me try to digest some of these references. I see some generic settings for Arduino devices which I’ll try and get back to you.
Just curious where you are located? My main site is N4MRV-1 --- Ashland, Virginia Current Weather Conditions and I’m working to switch over to an RPI5 where the MKR1310 will be installed along with other sensors.
Cheers,
Bob

Neat weather station page :+1:

I’m from Yellowknife, NWT, Canada! Prototyping LoRaWAN capabilities for SSiCanada.

One more comment on the ABP vs OTAA. If your device is using ABP it should ask you for a NwkSkey, AppSkey and the devAddr (possibly fCnt as well). If its using OTAA it should ask you for the devEUI, Appkey and JoinEUI (also referred to as an appEUI but again this value does not matter for Chirpstack).

In OTAA the LoRaWAN server uses your devEUI to generate a devAddr (An address unique on your network referencing the device) and uses the appKey to generate the AppSkey and NwkSkey (which are the actual keys used for encrypting and decrypting packets).

Essentially ABP just skips the “join” process, and you have to enter the values for the generated keys yourself. So depending on the keys it asks you for you should be able to tell how your device is connecting, but regardless, for ABP and OTAA as long as the values of the keys are the same on Chirpstack and the device it should join.

I took a look at the MKR1301 Guide to connect to TTN that I assume you were working from. I think I understand your confusion, I was referencing the joinEUI and you were getting stuck on the appEUI, these are the same thing. The names of keys have just changed a bunch throughout LoRaWAN versions.

So after looking at the guide what you will want to do the following:

In Chirpstack:
Create a device with devEUI: 3930313052317908
Once created set the Appkey to: 01020304050607080910111213141516

In the Arduino:
set the appEUI to: 0000000000000000
set the appKey to: 01020304050607080910111213141516

It should connect after that.

EDIT:

Looking back I realize I told you the appEUI was the appKey, my bad :man_facepalming:

Liam,
I sent you a message by replying to the email notice because I wasn’t able to attach a file. If you didn’t get it then let me know and I’ll try something else.
Still can’t get a join request after following your last instructions.
Cheers,
Bob

I checked out the code, it all looks okay to me. Can’t rule out that the issue isn’t device side but I think it’s more likely at this point there is a misconfiguration in Chirpstack.

One thing you could try on the code side is just to hardcode the OTAA keys, that way there is no risk of mistyping:

  if (mode == 1) {
    appEui = "0000000000000000";

    appKey = "01020304050607080910111213141516";

    connected = modem.joinOTAA(appEui, appKey);

As for Chirpstack you should check the logs when the device attempts to join (and if your RAK has logging you should check that too). If the messages are making it to the gateway we could rule out a bunch of issues. I also just read that you are running Chirpstack V3, might be worth looking into upgrading as V4 has many benefits and is significantly easier to set up.

Liam,
No better luck with keys inserted in code. RAK gateway shows no attempted join messages. My feeling is that the MKR1310 isn’t sending anything out. The FirstConfiguration.ino seems to load ok. No errors appear when I put in the keys but then it stops a few minutes to say move closer to the window. Since the gateway is only 10 feet away, this can’t be a problem. I have US915 in the code but maybe it’s sending something that isn’t understood by the gateway. Not sure how to test this.

Since I have everything working on chirpstack v3, and my limited knowledge of programming, I have been afraid to try v4. If you think the migration is fairly simple then maybe I could try at some point.
Cheers,
Bob

Looks like it’s not uncommon for the MK1310 to have issues with Chirpstack:

Doesn’t look like your exact issue as this guy atleast gets join/accepts but something to be aware of.

As for V4 if you have a spare server to try it (so then you don’t need to delete your current one incase the migration fails), then there would be no harm in giving it a shot. The migration itself really is not hard (although I have not done it before): v3 to v4 migration - ChirpStack open-source LoRaWAN® Network Server documentation, and then you need to make sure you do the v4.7 redis → postgres migration as well (a single command): [release] ChirpStack v4.7

Hi, I also am trying to use a 1310 and Chirpstack. I had to modify the driver a bit in order to get the 1310 to connect. Here is the change I made to MKRWAN_v2.h:
bool join()
{
for ( int attempt=0; attempt<20; attempt++ )
{
sendAT(GF(“+JOIN”));
if (waitResponse(3000L, “JOINED”) == 1)
{
return true;
}
}
return false;
}

The join function is near line 700. Sorry about the formatting - I do not know how to properly insert a block of code.

However, now I am stuck because I do not know how to write a codec for the 1310.

BTW: I used a spectrum analyzer to ensure that the 1310 was actually transmitting a 915MHz signal.

Thanks, k3pto, I tried your patch but got an error in the compile. I’m not skilled in this so maybe my formatting isn’t correct and I don’t know how to debug.
I’m about ready to toss it out the window…
Cheers,
Bob (n4mrv)

Hi Bob,
You can send me your file and I will try to fix it.
My email is k3pto@arrl.net

1 Like