RN2483 can't join to Conduit

[wojtek t]

We did check the config on the Multitech server side, but we will make
sure that RN2483 is also set correctly (and we can also try with private
just to see how it will behave).
I would expect that Rn2483 is set properly as we can operate without any
problems with Kerlink and also no problem at all with actual
operators/network providers.

[Jon Pearce]

check if it’s reliable in long run or I would get no-free-ch or denied messages

The “no-free-ch” is a normal response, so please don’t take it as a sign of an issue or lack of interop between systems. It is purely a duty-cycle safe guard as described in the LoRaWAN spec.

I.e. if you get “no-free-ch” as a response, you are exceeding the duty cycle restrictions of the spectrum.

Defaults are 3 channels each with 0.33% duty-cycle allocated.
You can disable this (as during during certification testing) or over-ride the limit with a higher value, but it should be done consciously and in accordance with regional limits.

The “denied” response during OTAA join is similar, but note that join has its own duty-cycle limit of 0.1%, again, from the LoRaWAN spec. So you get 3 chances (3 default channels) then have to wait.
Also note that the response “denied” is given due to no response from the server, again from the LoRaWAN spec. So from the response at the command line, its not possible to say if the server really denied the join, or just didn’t response, didn’t hear the request, or just had a poor channel in the downlink.

[wojtek t]

I will leave it to Yuqian to explain in details his testing methodology, but we take duty-cycle into consideration and he waits between subsequent requests.
Just to clarify, the server indicated successful join but the node reports denied, meaning that as you said the join confirmation message is not being delivered back to the node.

[Jon Pearce]

In addition to the above about join having a 0.1% duty cycle, it means that joining at SF12 is not that wise, as it congests the network and uses up your scarce 0.1% duty cycle quickly.

Better is to start at fastest SF7 (=DR5) then increase the SF only if “denied”, gradually increasing SF up to SF8, SF9, SF10, SF11, SF12.

The initial SF (or DR) can be set with:
mac set dr 5 // DR5 = SF7

[Bryan Tran]

Hi All,

I just upgraded my Microchip to version 1.0.1 and tested it against with AEP-1.3.3 and I have tried 10 times OTAA and it worked 10 times.

I am using the Lora Development Utility software to configure my Microchip using the software in the following link. Click on the ‘Download’ link.

https://www.thethingsnetwork.org/forum/t/ttn-uno-beta-release-documentation/290/46.

Below is my configuration.

Microchip – version – 1.0.1:
—————————-

Under LoraWan tab:

AppKey: 2b7e151628aed2a6abf7158809cf4f3c

AppEUI: 0000000000000000

Hit ‘Save’ button and then ‘Join’ button.

Conduit – AEP-1.3.3:
——————-

Channel Plan: EU868
Public: Enable.
EUI: 0000000000000000
Key: 2b7e151628aed2a6abf7158809cf4f3c

Everything else is at default.

Click on ‘Submit’ button.

May be, try to reload the firmware on the Microchip using the tutorial above and then reconfig it as above and see if it helps ?

If not, create a support case at http://www.multitech.com/support/support

Thanks,

BT

[wojtek t]

Bryan,
Let me ask you a question. Did you guys release new version of the lora radio with SPI instead of USB? If yes, are you using JIT or the version 1 protocol to communicate between the packet forwarder and your network server?
Anyway, i am glad that it works for you, so Yuqian should be able to get it going as well.

[Bryan Tran]

Hi wojtek,

I am using USB version and with the old hardware V1.0 – MTAC-LORA card.

Thanks,

BT

[wojtek t]

Thanks, so we are using the same hardware.
We already have the support case open #5078000

[lorawan2016]

Hello,

Today I did new tests and I got the same problem as Yuqian Li got i.e. denied, not_joined and no_free_ch using RN2483 firmware version 1.0.1 and Multitech Conduit gateway 1.3.2. though there was just one RN2483 to try to connect to Conduit gateway.
After trying the disconnection of the USB cable several times it worked after the 5th try.

[Jon Pearce]

@LoRaWAN2016 – I take it that you are testing close to the gateway. Please try defaulting to SF7 (mac set dr 5) as it will ease the duty cycle limitations of LoRaWAN.

[Yuqian Li]

Hi Jon,

I tired set our node to “mac set sync 12”, the Conduit server even can’t receive any messages from node now.

[00:00:16|LOR|DEBUG] RX:[off] = 0
[00:00:16|LOR|DEBUG] TX:[mac set sync 12..] = 0
[00:00:16|LOR|DEBUG] RX:[ok] = 0
[00:00:16|LOR|DEBUG] TX:[mac get rxdelay1..] = 0
[00:00:16|LOR|DEBUG] RX:[1000] = 0
[00:00:16|LOR|DEBUG] TX:[mac get rxdelay2..] = 0
[00:00:16|LOR|DEBUG] RX:[2000] = 0
[00:00:16|LOR|DEBUG] TX:[mac get sync..] = 0
[00:00:16|LOR|DEBUG] RX:[12] = 0

[Yuqian Li]

Hi Loranwan2016,

Sorry for heard that.

Hi, Jon, I just tried changed DR5 and SF7, it is working good now. 10 times, and joined with first try. thank you 🙂

[lorawan2016]

Thanks Jon, … it works at dr5.

Hi Yuqian,

Happy to know it works for you, it works for me as well after setting dr5 on the end-device.

Is the SF7 on the gateway or the end-device?

[Yuqian Li]

Hi Lorawan2016,

There is a config option for the “Rx 2 Datarate” in the Conduit server, you can change it to SF7.

I am glad you fixed it as well 🙂

[lorawan2016]

Yes it’s already SF7 on the gateway, that’s why it works.

[Jason Reiss]

In module calibration we have noticed issues with DR0 and DR1 when the crystal tuning was off by 10 KHz. Being near to the gateway also affects the low-datarates and leads to packet loss when not in a chamber, multi-path effects.

You may want to look at the frequency accuracy of the module.

[Yuqian Li]

Hi Jason,

Do you mean the RN2483 radio crystal?

[Jason Reiss]

You can check both if you want.

[lorawan2016]

Hi Jon,

If RN2483 has adaptive data rate enabled then why we need to set it manually?

Because we set it manually then I suspect it’s not enabled or there’s no support for ADR in firmware version 1.0.1 …. what’s your comment on this?

[Jon Pearce]

ADR is fully supported in all firmware versions. My comment is about the INITIAL value of DR/SF. ADR has to start with some initial value before the control loop kicks in.

But there is one other thing to say. By default ADR is disabled, so as well as setting a preferred initial value, you should set ADR to on

mac set dr 5
mac set adr on

The preference for initial SF is different depending on which network owner you are talking to. Some prefer SF=12, some prefer SF=7, some information from the Alliance would suggest SF=10 is a good default. Hence its not possible for any module to have a default that satisfies all, so better to manually set it in your code.

[Jon Pearce]

In module calibration we have noticed issues with DR0 and DR1 when the crystal tuning was off by 10 KHz

We have noticed the same, and have been working with Semtech on that.
LoRa should be capable of handling frequency error of +/-30kHz (specifically 25% of the 125kHz BW) and during our regression testing we saw a narrower window in SF12 (DR0).
Semtech released a patch for SX1301 HAL a couple of days ago and it corrects this back to +/-30kHz for SF12.
I’m confident it will have a demonstrable affect on the issues seen in this thread.

[Author]

Posts