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 9, 2017 at 4:38 am #16849
Yuqian Li
ParticipantI 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 avgno 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 be9: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 ‘joinedlora-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 0February 9, 2017 at 4:46 am #16850Yuqian Li
Participantalso, 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 🙁
February 9, 2017 at 9:41 am #16853Peter Ferland
BlockedIs the RN2483 configured for OTAA or ABP joins?
February 9, 2017 at 11:25 am #16867wojtek t
ParticipantI can respond on Yuqian’s behave… he is testing it in OTAA mode…
February 9, 2017 at 10:01 pm #16957Yuqian Li
Participantthank 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.February 10, 2017 at 4:22 am #16961lorawan2016
ParticipantHi 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.
February 10, 2017 at 4:42 am #16962Yuqian Li
ParticipantHi Loranwan2016,
Thanks for your suggestions.
The RN2483 actually is enabled three mandatory channels, check this link out http://www.microchip.com/forums/m947922.aspx#947922Now 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,
February 10, 2017 at 4:42 am #16963lorawan2016
ParticipantAnother approach is to configure 8 radio channels in the Multitech gateway rather than the default activated ones ch0 and ch1.
February 10, 2017 at 5:02 am #16964Yuqian Li
ParticipantHi 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
},February 10, 2017 at 5:12 am #16965lorawan2016
ParticipantHi 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.
February 10, 2017 at 5:16 am #16966Yuqian Li
ParticipantHi 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.February 10, 2017 at 6:56 am #16968wojtek t
ParticipantThe 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 8 years, 1 month ago by
wojtek t.
February 10, 2017 at 6:59 am #16970wojtek t
ParticipantAnyone from Multitech?
February 10, 2017 at 7:21 am #16971lorawan2016
ParticipantHello 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!!!February 10, 2017 at 7:23 am #16972wojtek t
ParticipantMicrochip 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…
February 10, 2017 at 7:54 pm #17026Yuqian Li
Participantreally appreciate if some MultiTech tech guys can help out :), as this is very important for us, thank you.
February 11, 2017 at 1:22 pm #17027lorawan2016
ParticipantHi 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?
February 11, 2017 at 1:38 pm #17028lorawan2016
ParticipantI 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 !!
February 12, 2017 at 3:42 am #17029Yuqian Li
ParticipantHi 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 🙁February 12, 2017 at 1:00 pm #17031lorawan2016
ParticipantHi 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.February 12, 2017 at 2:19 pm #17032wojtek t
Participant1.0.1 is the latest publicly available firmware on these modules…
February 13, 2017 at 3:12 am #17034lorawan2016
ParticipantThere’s version 1.0.4 now and that’s why I consider version 1.0.1 is an old version.
February 13, 2017 at 3:17 am #17035Yuqian Li
ParticipantHi Lorawan2016
Thank you, i will try it and let you know results 🙂February 13, 2017 at 4:42 am #17039Yuqian Li
ParticipantHi Lorawan2016,
Hmm, where I can find the RN2483 1.0.4 firmware? thank you.February 13, 2017 at 6:48 am #17041lorawan2016
ParticipantHi 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?
February 13, 2017 at 9:02 am #17051Jon Pearce
ParticipantHello 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 requestAlthough I must admit that when I did this, I used the same value for both AppEUI and DevEUI, so worth checking this.
February 13, 2017 at 9:47 am #17058wojtek t
ParticipantJon,
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
February 13, 2017 at 10:27 am #17062Peter Ferland
BlockedMicrochip & 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.
February 13, 2017 at 10:48 am #17065lorawan2016
ParticipantThanks 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.February 13, 2017 at 10:53 am #17066Jon Pearce
ParticipantIt 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.
-
This reply was modified 8 years, 1 month ago by
-
AuthorPosts
- You must be logged in to reply to this topic.