[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.

[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]

@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.

[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

[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.

[Jon Pearce]

It all makes sense, but we don’t want to operate as private network “mac set sync 12″

Understood. I was just flagging Sync Word as one of those parameters that needs to match at both ends of the link. Its often over-looked because the use of 0x12 is kind of “de facto”. I.e. not officially in the LoRaWAN spec.

[Jon Pearce]

Hello All,

To add a little clarity here for RN2483 firmware:
Current production/shipping is version 1.0.1 (certified to LoRaWANv1.0.0)
In the next weeks, there will be a new 1.0.3 (certified to LoRaWANv1.0.1)

There is no 1.0.4 firmware for RN2483 other than a class C prototype, which is being used for internal validation testing only and most likely won’t be productised until the Alliance is ready to certify class C (~ mid-2017).

Microchip & Multitech did work together on interop testing around 1 year ago and all was working fine. I’m not aware of any regression with newer versions.

My first suggestion, just because I didn’t see it specified in the original post, would be to check the Sync word. RN2483 defaults to 0x34 (public network) but maybe Conduit is using 0x12 (private network).

RN2483 Command: mac set sync 12

Second suggestion would be to clarify the correct keys/EUIs are being used, as Microchip & Multitech have different terminology. From my notes:

LoRaWAN -> Multitech
AppKey -> Key (Network Key)
AppEUI -> EUI (Network ID)
DevEUI -> Taken from device during OTAA request

Although I must admit that when I did this, I used the same value for both AppEUI and DevEUI, so worth checking this.

[Author]

Posts