RN2483 can't join to Conduit
Home › Forums › Conduit: AEP Model › RN2483 can't join to Conduit
- This topic has 50 replies, 7 voices, and was last updated 8 years ago by
Jon Pearce.
-
AuthorPosts
-
February 13, 2017 at 11:00 am #17067
wojtek t
ParticipantWe 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.February 13, 2017 at 11:00 am #17068Jon Pearce
Participantcheck 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.February 13, 2017 at 11:04 am #17069wojtek t
ParticipantI 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.February 13, 2017 at 11:06 am #17072Jon Pearce
ParticipantIn 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 = SF7February 13, 2017 at 11:27 am #17073Bryan Tran
ModeratorHi 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: 2b7e151628aed2a6abf7158809cf4f3cEverything 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
February 13, 2017 at 11:30 am #17074wojtek t
ParticipantBryan,
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.February 13, 2017 at 11:52 am #17080Bryan Tran
ModeratorHi wojtek,
I am using USB version and with the old hardware V1.0 – MTAC-LORA card.
Thanks,
BT
February 13, 2017 at 12:29 pm #17083wojtek t
ParticipantThanks, so we are using the same hardware.
We already have the support case open #5078000February 14, 2017 at 6:26 am #17088lorawan2016
ParticipantHello,
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.February 14, 2017 at 7:24 am #17089Jon Pearce
Participant@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.
February 14, 2017 at 8:03 am #17090Yuqian Li
ParticipantHi 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] = 0February 14, 2017 at 8:23 am #17091Yuqian Li
ParticipantHi 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 π
February 14, 2017 at 8:27 am #17092lorawan2016
ParticipantThanks 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?
February 14, 2017 at 8:31 am #17093Yuqian Li
ParticipantHi 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 π
February 14, 2017 at 8:33 am #17094lorawan2016
ParticipantYes it’s already SF7 on the gateway, that’s why it works.
February 14, 2017 at 8:33 am #17095Jason Reiss
KeymasterIn 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.
February 14, 2017 at 8:36 am #17096Yuqian Li
ParticipantHi Jason,
Do you mean the RN2483 radio crystal?
February 14, 2017 at 8:57 am #17097Jason Reiss
KeymasterYou can check both if you want.
February 14, 2017 at 10:12 am #17105lorawan2016
ParticipantHi 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?
February 14, 2017 at 10:59 am #17109Jon Pearce
ParticipantADR 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 onThe 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.
February 17, 2017 at 4:02 am #17285Jon Pearce
ParticipantIn 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. -
AuthorPosts
- You must be logged in to reply to this topic.