RN2483 - NwkID with mac set devaddr

[Sauxo]

Hi,

My question is which part in the “mac set devaddr” command is the NwkID / NetID, some sources says the LSB while others says MSB, and I can’t figure out if the command is little endian or big endian either. I haven’t been able to figure it out by any example I found on this and other websites either as I expect things belonging to the TTN network to either start or end with a byte 0x26 or 0x27, and I haven’t found any that have that.

But the real question for us is how should we assign the DevAddr to our LoRaWAN devices, our plan was that settings the NwkID to 0x00, and filling the remaining 25 bits with some serial- or random number, so that it isn’t locked to any specific network, and for that I need to know the order of the devaddr-command since our design makes use of the Microchip LoRaWAN stack, which should be the same as the RN2483

So let’s say we got a DevAddr (which I assume has either a byte set to 26h or 27h ) assigned to an sensor, how should we configure a RN2483 device to join the TTN network via ABP, should we write

a) mac set devaddr 26XXYYZZ
or
b) mac set devaddr ZZYYXX26

Thanks,
Sauxo

[BoRRoZ]

here you’ll find some code examples that make use of ttn arduino device lib and the rn2483

TheThingsNetwork/arduino-device-lib

[Sauxo]

Thanks for the post @BoRRoZ , but I can’t find none of the examples really answering my questions either. Could you point me more exactly into the github project if you think I missed it?

Or if someone can provide their “mac get devaddr” for a device that is connected to TTN, that probably help a lot too

Thanks again

[arjanvanb (Arjan)]

See the following post for more details:

@arjanvanb

The most significant 7 bits are used as network identifier (NwkID) to separate addresses of territorially overlapping networks of different network operators and to remedy roaming issues. The least significant 25 bits, the network address (NwkAddr) of the end-device, can be arbitrarily assigned by the network manager.

Also, are you even referring to The Things Network? If not, then see:

@htdvisser

A NetID is indeed not required for a private network, but a private network is required to use a different sync word than a public network

But if you’re really just asking if the following is correct:

mac set devaddr 26XXYYZZ

Yes, that’s the one. But the DevAddr must be generated by TTN Console, not by yourself.

[Sauxo]

Thanks @arjanvanb, I’ve read that and many other topics on the subject, so you are basically saying that if I join TTN with a device and I write “mac get devaddr” it would be something like 26XXYYZZ?

We are manufacturing LoRaWAN devices, which we want to work with TTN, or any network for that matter out-of-the-box. TTN only supports devices with NwkID 00/01/26/27, that is why we need to know how this is done in the RN2483 since we use the same stack. And there is no information about where the NwkID is in the DevAddr for that stack. If is it Big or Little endian. Since a lot of sources conflict when saying the NwkID is LSB/MSB.

[Sauxo]

@arjanvanb

mac set devaddr 26XXYYZZ

Okey thanks! Yes we know the DevAddr most come from the TTN Console

[arjanvanb (Arjan)]

@Sauxo

We are manufacturing LoRaWAN devices, which we want to work with TTN, or any network for that matter out-of-the-box.

If you’re saying you’re going to program a DevAddr into the device before selling it: how do you plan to transfer ownership of that DevAddr to whoever bought your device?

Using OTAA rather than ABP is probably better; see Registration of node with pre-configured LoRaWAN keys.

[Sauxo]

Yes, the devices only inputs method are through LoRaWAN and a magnetic sensor since they are fully enclosed for special applications. So our approach is that they come with predefined values for DevAddr, NwkSKey, AppSKey, DevEUI, AppEUI and AppKey, you can then switch between ABP / OTAA mode by holding a magnet by the sensor. Only allowing OTAA wouldn’t pass the Lora-Alliance certification process in my understanding.

After the device has joined the network you can change all settings as you please via a downlink protocol

The ownership of the devices is on which holds the encryptions keys of it.

[arjanvanb (Arjan)]

@Sauxo

our plan was that settings the NwkID to 0x00, and filling the remaining 25 bits with some serial- or random number

If that’s still your plan: I don’t think that’s supported. These are local test addresses for experimental nodes. I don’t expect a provider such as TTN to be obliged to even handle those at all. TTN Console surely does not support registration of those addresses, but one could currently use ttnctl; see my first link in my first answer.

@Sauxo

The ownership of the devices is on which holds the encryptions keys of it.

But then your customers cannot use TTN Console? (Which might be okay for you.)

[Sauxo]

ABP is only there to be compatible with the lora-alliance certification, we want devices that are certified and can be used on all networks. I understand those addresses are for experimental uses, which no networks is obligated to handle. But I don’t see how we can support ABP and get our products certified without locking them to a specific network. We got to have some kind of pre-configured DevAddr for that to work. The best for us is if we could skip ABP and still get them certified, but I don’t see how that could ever work.