RN2483 can't join to Conduit

[Yuqian Li]

I am running AEP1.3.3 of Conduit, I had set the Conduit:
DR is 2
SF is 12
ADR is on
RN2483 same to Conduit.

Now when the RN2483 trying to join the Conduit, the Conduit thinking it is joined like below
————
before RN2483 try to join
admin@mtcdt:~# lora-query -n
Net Addr Dev EUI Class Joined Seq Num Up Down 1st 2nd Dropped RSSI min max avg SNR min max avg

no node joined

after RN2483 try to join

lora-query -n
Net Addr Dev EUI Class Joined Seq Num Up Down 1st 2nd Dropped RSSI min max avg SNR min max avg
00:00:00:01 00-04-a3-0b-00-1c-01-xx A 2017-02-09T09:58:08Z 0 0 0 0 0 0 0 0 0 0 0 0
———–

Conduit said node was joined, but RN2483 keeping tell denied. also, when the RN2483 tried 3 times to join, then the RN2483 keeping tell no free-channel.

Here is the details join log from Conduit, please take a look on that, and welcome any suggestions 🙂

admin@mtcdt:~# 9:57:55:637|TRACE| Parse upstream message 244 bytes
9:57:55:638|TRACE| Gateway 00:80:00:00:00:00:c4:eb seen
9:57:55:639|INFO| Parsing 1 rx packets
9:57:55:640|DEBUG| Received packet
================================
000 00 ff ff 00 fa 47 c7 41
008 db 21 01 1c 00 0b a3 04
010 00 11 69 48 4b 12 be

9:57:55:640|DEBUG| Rx on 868300000, rssi: -47 snr: 85
9:57:55:641|DEBUG| Received frame: type: Join Request
9:57:55:641|INFO| Received join request
9:57:55:641|DEBUG| BUFFER: 00ffff00fa47c741db21011c000ba304001169
9:57:55:642|DEBUG| App EUI: db-41-c7-47-fa-00-ff-ff
9:57:55:642|DEBUG| Dev EUI: 00-04-a3-0b-00-1c-01-21
9:57:55:642|DEBUG| Nonce: 00006911
9:57:55:643|DEBUG| MIC is valid
9:57:55:644|DEBUG| Got appkey: a0.2d.fe.b4.af.7b.52.cb.fd.e0.ae.ce.5c.a6.7e.f2
9:57:55:644|DEBUG| DEV NONCE: 6911
9:57:55:644|DEBUG| APP NONCE: 7e179d
9:57:55:645|DEBUG| session keys: 1068d5b7c377d12234c8d833b412fe20 9a364ee690542623bb898bf87523c321
9:57:55:645|TRACE| SQL query = SELECT address FROM nodes WHERE deveui = “0004a30b001c0121”;
9:57:55:646|INFO| Device not found in DB
9:57:55:647|INFO| assigning address: 1
9:57:55:648|TRACE| SQL query = SELECT address FROM nodes where deveui = “0004a30b001c0121”;
9:57:55:650|TRACE| SQL query = INSERT INTO nodes (address, appeui, deveui, authenticationkey, encryptionkey, lastdownmsgseqno, class) VALUES (“00000001”, “db41c747fa00ffff”, “0004a30b001c0121”, “2b7e151628aed2a6abf7158809cf4f3c”, “2b7e151628aed2a6abf7158809cf4f3c”, 0, “A”)
9:57:55:654|TRACE| SQL query = INSERT INTO packets (node, gateway, seqno, data) VALUES (“00000001”, “”, 0, “”);
9:57:55:659|TRACE| SQL query = INSERT INTO appkeys (appeui, deveui, appkey) VALUES (“db41c747fa00ffff”, “0004a30b001c0121”, “a02dfeb4af7b52cbfde0aece5ca67ef2”);
9:57:55:663|DEBUG| Update session keys
9:57:55:663|TRACE| SQL query = UPDATE nodes SET authenticationkey = “1068d5b7c377d12234c8d833b412fe20”, encryptionkey = “9a364ee690542623bb898bf87523c321” WHERE address = “00000001”
9:57:55:667|DEBUG| Freq 0: 8691000
9:57:55:668|DEBUG| Freq 1: 8693000
9:57:55:668|DEBUG| Freq 2: 8695000
9:57:55:668|DEBUG| Freq 3: 8697000
9:57:55:673|DEBUG| Freq 4: 8699000
9:57:55:673|DEBUG| GenerateJoinRequestIntegrityCode
9:57:55:675|DEBUG| node is active
9:57:55:675|DEBUG| app data size 0
9:57:55:676|INFO| Queue join response 33 bytes
9:57:55:676|DEBUG| Update stats
9:57:55:676|DEBUG| Join packet received
9:57:55:677|DEBUG| transmitController.ReceivedFrame
9:57:55:677|DEBUG| update bestGateway
9:57:55:677|DEBUG| Time: 3844941188
9:57:55:678|DEBUG| App Queue Length: 1
9:57:55:678|DEBUG| NewFrame
9:57:55:678|DEBUG| 0 : 00:80:00:00:00:00:c4:eb == 00:80:00:00:00:00:c4:eb 1
9:57:55:679|DEBUG| update gateway 0
9:57:55:679|DEBUG| DR Index sf: 10 bw: 125 index: 2
9:57:55:679|DEBUG| Rx Frame SEQ 16839 SNR 85 SF 2
9:57:55:680|DEBUG| ADR FindDR : snr : 85 step : 30
9:57:55:680|DEBUG| ADR PRE MIN/MAX DR: 9
9:57:55:681|DEBUG| ADR NEW DR: 5 MIN: 0 MAX: 5 STEP: 30
9:57:55:681|DEBUG| ADR update avgSnr store size: 0 snr: 85 avg: 0
9:57:55:681|DEBUG| ADR update avgSnr store size: 0 snr: 85 avg: 85
9:57:55:682|DEBUG| ReceiveOption : db
9:57:55:682|TRACE| SQL query = UPDATE nodes SET lastdownmsgseqno = 0 WHERE address = “00000001”;
9:57:55:683|DEBUG| Send MQTT message 229 bytes
9:57:55:684|DEBUG| UDP message: lora/00-04-a3-0b-00-1c-01-21/packet_recv {“chan”:1,”codr”:”4/5″,”data”:”AP//APpHx0HbIQEcAAujBAARaUhLEr4=”,”datr”:”SF10BW125″,”freq”:868.29999999999995,”lsnr”:8.5,”modu”:”LORA”,”rfch”:0,”rssi”:-47,”size”:23,”stat”:1,”time”:”2017-02-09T09:57:55.637126Z”,”tmst”:3844941188}
9:57:55:684|DEBUG| UDP port: 1784
9:57:55:687|TRACE| Published message: 124
9:57:55:688|TRACE| MQTT message: lora/00-04-a3-0b-00-1c-01-21/packet_recv
9:57:55:691|TRACE| SQL query = UPDATE nodes SET jointime = “2017-02-09T09:57:55Z” WHERE address = “00000001”
9:57:55:695|TRACE| SQL query = UPDATE packets SET port = 4, seqno = 0, gateway = “008000000000c4eb”, time = “2017-02-09T09:57:55Z”, microseconds = 637126, rssi = -47, channel = 1, lsnr_cB = 85, spread = 10, modulationbandwidth = 125, data = “001169” WHERE node = “00000001”
9:57:55:700|TRACE| SQL query = UPDATE nodes SET lastuppacketid = 1, lastmessagems = 52 WHERE address = “00000001”;
9:57:55:703|TRACE| SQL query = UPDATE gateways SET lastuppacketid = 1 WHERE address = “008000000000c4eb”;
9:57:55:707|DEBUG| getTimeOnAirMs dr: 10 bw: 0 pl: 8 sz: 32 toa: 452
9:57:55:708|TRACE| SQL query = SELECT address FROM nodes WHERE deveui = “0004a30b001c0121”;
9:57:55:709|DEBUG| Mosquitto command received ‘packet_recv’
9:57:55:709|TRACE| Unknown command ‘packet_recv
9:57:55:710|INFO| Send Join Accept – EUI: 00-04-a3-0b-00-1c-01-21 ADDR: 00000001
9:57:55:711|INFO| Schedule TX Time on air: 462 ms
9:57:55:711|DEBUG| BestGatewayChannel::scheduleAt seq: 0 tm:21092532 dur:462 freq:868300000
9:57:55:712|DEBUG| BestGatewayChannel::scheduleAt gw_seq: 16839 seq: 0
9:57:55:712|DEBUG| BestGatewayChannel 0 : 00:80:00:00:00:00:c4:eb
9:57:55:712|TRACE| Schedule DC band: 1 available: 36000 duration: 462 freq: 868300000
9:57:55:713|DEBUG| returning 00:80:00:00:00:00:c4:eb
9:57:55:717|DEBUG| Send MQTT message 0 bytes
9:57:55:729|TRACE| Published message: 125
9:57:55:730|DEBUG| UDP message: lora/00-04-a3-0b-00-1c-01-21/joined
9:57:55:730|DEBUG| UDP port: 1784
9:57:55:768|TRACE| MQTT message: lora/00-04-a3-0b-00-1c-01-21/joined
9:57:55:768|TRACE| SQL query = SELECT address FROM nodes WHERE deveui = “0004a30b001c0121”;
9:57:55:770|DEBUG| Mosquitto command received ‘joined’
9:57:55:770|TRACE| Unknown command ‘joined

lora-query -n
Net Addr Dev EUI Class Joined Seq Num Up Down 1st 2nd Dropped RSSI min max avg SNR min max avg
00:00:00:01 00-04-a3-0b-00-1c-01-21 A 2017-02-09T09:58:08Z 0 0 0 0 0 0 0 0 0 0 0 0

[Yuqian Li]

also, I tried to change Conduit “Disable Duty Cycle” “Disable Join Rx1” “Disable Join Rx2″as somebody said that maybe can help, but nothing was help as well 🙁

[Peter Ferland]

Is the RN2483 configured for OTAA or ABP joins?

[wojtek t]

I can respond on Yuqian’s behave… he is testing it in OTAA mode…

[Yuqian Li]

thank you, Wojtek, yes, I am running OTAA mode.
Does anyone who has same issue as I think this is must be a common issue for RN2483 and Conduit.

[lorawan2016]

Hi Yuqian,

Yes I have seen this behavior previously and I think this is related to radio channels configurations since the LoRaWAN module RN2483 is trying to send in a pre-configured frequency in the activated channel normally ch0 and ch1 as the default settings of the MultiTech conduit gateway require but it fails when there is no enough time during the pre-configured duty cycle for each radio channel especially when there’s interference “causing the return status no_free_channel” as I remember it between LoRaWAN end-device and the gateway.

In my point of view, I recommend to re-configure the radio channels according to your region available legal frequency bands and set on each channel not just the frequency band but also, the duty cycle, data rate and set the channel to on. Don’t forget to save your configuration after setting the new configuration. Try to adjust the frequency until you find the suitable band to communicate to the gateway. The bandwidth in each channel is 125 KHz.

In Europe the activated frequencies in RN2483 are 868.1, 868.3 and 868.5.

Kindly share your findings if you would try this approach and this is would be helpful for others as well.

[Yuqian Li]

Hi Loranwan2016,
Thanks for your suggestions.
The RN2483 actually is enabled three mandatory channels, check this link out http://www.microchip.com/forums/m947922.aspx#947922

Now the problem is the Conduit can see the RN2483 sending join required used one of those 3 channels and replied to RN2483, but the RN2483 can’t receive that in consistently, we are tried to increase the Rx1 window time from 1000ms to 5000ms for RN2483, just get a little bit improves :(.

We still working on that to try find the real reason, and appreciate any suggestions,

[lorawan2016]

Another approach is to configure 8 radio channels in the Multitech gateway rather than the default activated ones ch0 and ch1.

[Yuqian Li]

Hi Lorawan2016,

Thank you.

I am using GUI of Conduit to configured it running in public mode, there is only a “Channel plan” and “Additional Channels”, there is no option to enable and review all channels to enable or disable, how I can to do that, any suggestion?

also, I used “curl -m 5 -s “127.0.0.1/api/loraNetwork”” can get following what is Conduit Lora configured
“lora” : {
“ADRStep” : 30,
“antennaGain” : 3,
“channelPlan” : “EU868”,
“dutyCyclePeriod” : 60,
“enabled” : true,
“frequencyBand” : 868,
“frequencyEU” : 869500000,
“frequencySubBand” : 1,
“maxDatarate” : 4,
“maxTxPower” : 26,
“minDatarate” : 0,
“netID” : “000000”,
“nodeQueueSize” : 16,
“packetForwarderConfig” : “{\n\t\”SX1301_conf\”: {\n\t\t\”radio_0\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”freq\”: 867500000\n\t\t},\n\t\t\”radio_1\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”freq\”: 868500000\n\t\t},\n\t\t\”chan_multiSF_0\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”radio\”: 1,\n\t\t\t\”if\”: -400000\n\t\t},\n\t\t\”chan_multiSF_1\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”radio\”: 1,\n\t\t\t\”if\”: -200000\n\t\t},\n\t\t\”chan_multiSF_2\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”radio\”: 1,\n\t\t\t\”if\”: 0\n\t\t},\n\t\t\”chan_multiSF_3\”: {\n\t\t\t\”enable\”: false,\n\t\t\t\”radio\”: 0,\n\t\t\t\”if\”: -400000\n\t\t},\n\t\t\”chan_multiSF_4\”: {\n\t\t\t\”enable\”: false,\n\t\t\t\”radio\”: 0,\n\t\t\t\”if\”: -200000\n\t\t},\n\t\t\”chan_multiSF_5\”: {\n\t\t\t\”enable\”: false,\n\t\t\t\”radio\”: 0,\n\t\t\t\”if\”: 0\n\t\t},\n\t\t\”chan_multiSF_6\”: {\n\t\t\t\”enable\”: false,\n\t\t\t\”radio\”: 0,\n\t\t\t\”if\”: 200000\n\t\t},\n\t\t\”chan_multiSF_7\”: {\n\t\t\t\”enable\”: false,\n\t\t\t\”radio\”: 0,\n\t\t\t\”if\”: 400000\n\t\t},\n\t\t\”chan_Lora_std\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”radio\”: 1,\n\t\t\t\”if\”: -200000,\n\t\t\t\”bandwidth\”: 250000,\n\t\t\t\”spread_factor\”: 7\n\t\t},\n\t\t\”chan_FSK\”: {\n\t\t\t\”enable\”: true,\n\t\t\t\”radio\”: 1,\n\t\t\t\”if\”: 300000,\n\t\t\t\”datarate\”: 50000,\n\t\t\t\”freq_deviation\”: 25000\n\t\t}\n\t},\n\t\”gateway_conf\”: {\n\t\t\”synch_word\”: 52,\n\t\t\”forward_crc_disabled\”: false,\n\t\t\”forward_crc_error\”: true,\n\t\t\”forward_crc_valid\”: true,\n\t\t\”gateway_ID\” : \”<008000000000C4EB>\”,\n\t\t\”keepalive_interval\”: 12,\n\t\t\”push_timeout_ms\”: 600,\n\t\t\”serv_port_down\”: 1700,\n\t\t\”serv_port_up\”: 1700,\n\t\t\”server_address\”: \”eur1.iothub.ca\”,\n\t\t\”stat_interval\”: 20\n\t}\n}”,
“packetForwarderMode” : false,
“rx1DatarateOffset” : 2,
“rx2Datarate” : 12
},

[lorawan2016]

Hi Yuqian,

Check if this is the correct path to edit the file.

/var/config/lora/lora-network-server.conf

or find its location in your gateway, there should be similar one.

[Yuqian Li]

Hi Loranwan2016,
It is same what I got from “curl -m 5 -s “127.0.0.1/api/loraNetwork”” just a “frequencySubBand” in there.
also I found this link http://openlora.com/forum/viewtopic.php?t=1252, they all talking about the subBand definition.

[wojtek t]

The proper start should be with 3 frequencies as Yuqian is doing. Then, through CFlist upon joining the radio will receive the list of additional frequencies from Conduit….but the problem is that his radio is timing out waiting for join confirmation ….

• This reply was modified 7 years, 2 months ago by wojtek t.

[wojtek t]

Anyone from Multitech?

[lorawan2016]

Hello wojtek t,

If there’s a timeout occurs on the end-device then this could be a bug in the Microchip OR MultiTech firmware to work reliably with each other, LoRaWAN stack problems?

It might be worth raising the same question track at Microchip forum.
This problem was discussed in different forums now but no official answer works!!!

[wojtek t]

Microchip is a single radio with a proper lora alliance approvals. We use it in our devices for both EU and NA without any problems except for this which again only present itself with Multitech…

[Yuqian Li]

really appreciate if some MultiTech tech guys can help out :), as this is very important for us, thank you.

[lorawan2016]

Hi Yuqian,

I am trying to investigate this problem but I need some information from you.
Do you know which Microchip firmware version in your RN2483 module? … you can use Tera term and the version will be printed on the screen upon starting the module.

Have you investigated if it works with earlier firmware versions of the Multi-tech gateway?

[lorawan2016]

I am quite sure that last year I connected RN2483 with MultiTech gateway and it worked without any problem but I’m unsure from which firmware version this problem has been introduced.

Another approach is to investigate this problem if you have another LoRaWAN module from ARM mBed i.e. SX1272 or similar one from Murata and try to connect it to the same Multitech gateway and check if it works. If it works then it’s compatibility problem and Microchip or MultiTech has to find a solution for it.

I don’t know why there’s no official response on this track yet !!

[Yuqian Li]

Hi Lorawan2016,
Thanks for your suggestion, i am using the 1.0.1 of RN2483 firmware, Conduit AEP 1.3.3.
No idea why there is no MultiTech guy in here 🙁

[lorawan2016]

Hi Yuqian,

Since the 1.0.1 is old firmware version, just for testing, try to downgrade the firmware on your gateway to either

Firmware version 1.0.33 (Released 09/25/2015)
OR
Firmware version 1.1.2 (Released 02/02/2016)

You can do this easily by registering your gateway in MultiTech DeviceHQ https://www.devicehq.com

Before doing the downgrade it’s important to save your configuration and then let DeviceHQ do the job for you after scheduling the downgrade to be done on next restart of the gateway. It will take a couple of hours or less depending on your internet connection.

Then test it with RN2483 firmware version 1.0.1 to check if it works better.

Later on, you may upgrade your gateway easily to any firmware version as all of them are available on DeviceHQ.
Another alternative is to do the firmware downgrade/upgrade for your gateway manually if you have the firmware file available on your system.

[wojtek t]

1.0.1 is the latest publicly available firmware on these modules…

[lorawan2016]

There’s version 1.0.4 now and that’s why I consider version 1.0.1 is an old version.

[Yuqian Li]

Hi Lorawan2016
Thank you, i will try it and let you know results 🙂

[Yuqian Li]

Hi Lorawan2016,
Hmm, where I can find the RN2483 1.0.4 firmware? thank you.

[lorawan2016]

Hi Yuqian,

I have heard from one of sales engineers last week that class A and class C is released in one firmware and the version for that firmware is 1.0.4 but I don’t know how to get it.

The idea is not to upgrade the firmware on Microchip module but as I wrote in my previous messages is to downgrade the firmware on the gateway to earlier versions and check if it works. This way we can narrow down the issue and it would be easier to track it.

The strange thing is that there’s no official comment on this problem and why?

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

[wojtek t]

Jon,
It all makes sense, but we don’t want to operate as private network “mac set sync 12”. We are making some additional tests and it seems that the devil is in the new network server implementation from Multitech. Basically, the old and the new packet forwarders behave the same way if using a 3rd party Lora bridge and network servers. It more less works, indicating that the packet forwarder code is fine (as expected). More to come, as Yuqian is testing other combinations. On the RN2483 we use the latest RC…so we should be alright .

Wojtek

[Peter Ferland]

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.

And the same 868/915 LoRa Motes are used to validate each Conduit LoRa software update. During an investigation of this issue it was found that we never updated the firmware on the motes so testing was always performed on firmware version 1.0.0 dated October 2015. Testing is now being done on RN2483 firmware 1.0.1. I will update you as soon as I get results.

[lorawan2016]

Thanks Jon and Peter … finally we see the official response on this track.

I have just tested OTAA with RN2483/firmware version 1.0.1 with Conduit gateway firmware version 1.3.2 and it works from the first run.
I will do more tests to check if it’s reliable in long run or I would get no-free-ch or denied messages as Yuqian is experiencing.

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

[Author]

Posts