[AU915-928] OTAA fails, join-accept not received by mDot

Hi,

I have a multitech conduit setup as a Lora Network Server and I can join an mDot on the network fine. What I’m trying to do now is move that configuration to the open source LoraServer.
I can confirm that the gateway/packet-forwarder is setup and is working (I’m receiving packets and they are getting forwarded to the LoraServer). However when the LoraServer accepts a Join Request (I’m using OTA) the transmit message doesn’t seem to reach the mDot (I get a joined failed).
I am in Australia so I’m using the Australian 915-925MHz bands.

The mDot has the following setup.

[INFO] general configuration
[INFO] =====================
[INFO] version ------------------ 2.0.17-1-mbed139
[INFO] device ID/EUI ------------ 008000000000a6b7
[INFO] frequency band ----------- AU915
[INFO] frequency sub band ------- 4
[INFO] public network ----------- off
[INFO] =========================
[INFO] credentials configuration
[INFO] =========================
[INFO] device class ------------- A
[INFO] network join mode -------- OTA
[INFO] network name ------------- xx
[INFO] network phrase ----------- xxxx
[INFO] network EUI -------------- 8b7c2172937dd4ef
[INFO] network KEY -------------- bce475938d4ba72b290fea7a3e315fa0
[INFO] ========================
[INFO] communication parameters
[INFO] ========================
[INFO] acks --------------------- off, 0 attempts
[INFO] TX datarate -------------- DR0
[INFO] TX power ----------------- 20 dBm
[INFO] atnenna gain ------------- 3 dBm

The working Multitech Lora Server setup has the following

“lora” : {
“ADRStep” : 30,
“antennaGain” : 3,
“beaconDelay” : 0,
“beaconInterval” : 0,
“beaconPower” : 27,
“channelPlan” : “AU915”,
“dutyCyclePeriod” : 60,
“dwelltimeDown” : 0,
“dwelltimeUp” : 0,
“enabled” : true,
“eui_1” : “00:80:00:00:00:00:A9:82”,
“frequencyAS” : 922600000,
“frequencyBand” : “AU915”,
“frequencyEU” : 869500000,
“frequencyKR” : 922900000,
“frequencySubBand” : 4,
“joinByteOrder” : “LSB”,
“joinDelay” : 1,
“maxDatarate” : 4,
“maxDatarateEU” : 5,
“maxDatarateUS” : 4,
“maxEIRP” : 20,
“maxTxPower” : 26,
“minDatarate” : 0,
“minDatarateEU” : 0,
“minDatarateUS” : 0,
“netID” : “000000”,
“nodeQueueSize” : 16,
“packetForwarderConfig” : “”,
“packetForwarderMode” : false,
“rx1DatarateOffset” : 0,
“rx1Delay” : 1,
“rx2Datarate” : 8,
“rx2Frequency” : 925100000
},
“mqtt” : {
“enabled” : true,
“host” : “127.0.0.1”,
“port” : 1883
},
“network” : {
“baseKey” : “”,
“eui” : “8b7c2172937dd4ef”,
“key” : “bce475938d4ba72b290fea7a3e315fa0”,
“leasetime” : 0,
“name” : “xxx”,
“passphrase” : “xx”,
“public” : false,
“salt” : “”
},

I am trying to setup the Loraserver to match these settings exactly so I can use it on a Raspberry Pi.
I don’t know how to extract the LoraServer config data however I can confirm that I am receiving and attempting to transmit messages from the log: These messages are from the packet-forwarder. We can see the LoraServer accepts the join request and attempts to transmit back the join accept message (from my understanding).

INFO: Received pkt from mote: 937DD4EF (fcnt=31777)

JSON up: {"rxpk":[{"tmst":12899618,"chan":8,"rfch":0,"freq":920.700000,"stat":1,"modu":"LORA","datr":"SF8BW500","codr":"4/5","lsnr":10.8,"rssi":0,"size":23,"data":"AO/UfZNyIXyLt6YAAAAAgACU2dZ+T2I="}]}
INFO: [up] PUSH_ACK received in 0 ms
INFO: [down] PULL_RESP received  - token[184:219] :)

JSON down: {"txpk":{"powe":20,"imme":false,"tmst":17899618,"codr":"4/5","datr":"SF7BW500","freq":925.1,"modu":"LORA","rfch":0,"ipol":true,"size":17,"data":"IFtjIqhqnvZPlHYgEC+ojzM="}}
INFO: tx_start_delay=1497 (1497.000000) - (1497, bw_delay=0.000000, notch_delay=0.000000)

In comparison to the working messages from the Multitech Conduit

0:56:38:487|INFO|GW:00:80:00:00:00:00:a9:82|FRAME-RX|Parsing 1 packets
0:56:38:488|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|DATA: 00efd47d9372217c8bb7a6000000008000b7e09bfdf6f9
0:56:38:489|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|FREQ: 921.000000 MHz DR0 RSSI: -42 dB SNR: 92 cB
0:56:38:489|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|TYPE: Join Request
0:56:38:490|DEBUG|GW:00:80:00:00:00:00:a9:82|JOINREQ-RX|00efd47d9372217c8bb7a6000000008000b7e0
0:56:38:490|DEBUG|GW:00:80:00:00:00:00:a9:82|DEV-EUI|00-80-00-00-00-00-a6-b7
0:56:38:490|DEBUG|GW:00:80:00:00:00:00:a9:82|APP-EUI|8b-7c-21-72-93-7d-d4-ef
0:56:38:490|DEBUG|GW:00:80:00:00:00:00:a9:82|DEV-NONCE|e0b7
0:56:38:491|DEBUG|ED:00-80-00-00-00-00-a6-b7|CHECK-KEY|MIC Valid
0:56:38:492|DEBUG|ED:00-80-00-00-00-00-a6-b7|APP-NONCE|ef0b90
0:56:38:494|INFO|ED:00-80-00-00-00-00-a6-b7|DEV-ADDR|Found in DB 1
0:56:38:495|DEBUG|Update session keys
0:56:38:499|DEBUG|GenerateJoinRequestIntegrityCode
0:56:38:500|DEBUG|node is active
0:56:38:501|INFO|ED:00-80-00-00-00-00-a6-b7|QUEUE-TX|JOIN SIZE: 17
0:56:38:501|DEBUG|Update stats
0:56:38:501|DEBUG|Join packet received
0:56:38:502|DEBUG|transmitController.ReceivedFrame
0:56:38:502|DEBUG|ED:00-80-00-00-00-00-a6-b7|PACKET-RX|GW:00:80:00:00:00:00:a9:82 Time_us:20759604
0:56:38:502|DEBUG|ED:00-80-00-00-00-00-a6-b7|PACKET-RX|Downlink Packets Queued: 1
0:56:38:530|INFO|Send Join Accept - EUI: 00-80-00-00-00-00-a6-b7 ADDR: 00000001
0:56:38:531|INFO|Schedule TX Time on air: 92 ms
0:56:38:532|DEBUG|Scheduling for Rx Window 1 00:00:00:01
0:56:38:533|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|JSON: {“chan”:5,“codr”:“4/5”,“data”:“AO/UfZNyIXyLt6YAAAAAgAC34Jv99vk=”,“datr”:“SF10BW125”,“freq”:921,“lsnr”:9.1999999999999993,“modu”:“LORA”,“rfch”:1,“rssi”:-42,“size”:23,“stat”:1,“time”:“2017-11-08T00:56:38.483687Z”,“tmst”:20759604}
0:56:39:243|INFO|GW:00:80:00:00:00:00:a9:82|FRAME-TX|IP: 127.0.0.1:55739 CH: LC6 NODE: 00:00:00:01 FCNT: 00000000 REPEAT: 0
0:56:39:255|INFO|ED:00-80-00-00-00-00-a6-b7|SCHED-TX|Q-SIZE: 1 PKT-SIZE: 17 PKT-ROOM: 242
0:56:39:255|TRACE|App Data Queue - Join Popped
0:56:39:255|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-TX|DATA: 202db3ac132b72cb2222dcb93aacfb91b1
0:56:39:257|DEBUG|GW:00:80:00:00:00:00:a9:82|PACKET-TX|RX1 OFFSET: 1000000
0:56:39:260|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-TX|JSON: {“txpk”:{“appeui”:“8b-7c-21-72-93-7d-d4-ef”,“codr”:“4/5”,“data”:“IC2zrBMrcssiIty5Oqz7kbE”,“datr”:“SF10BW500”,“deveui”:“00-80-00-00-00-00-a6-b7”,“freq”:925.10000000000002,“ipol”:true,“modu”:“LORA”,“ncrc”:true,“powe”:29,“rfch”:0,“size”:17,“tmst”:21759604}}
0:56:39:262|INFO|GW:00:80:00:00:00:00:a9:82|UDP-TX|JSON-SIZE:255
0:56:42:56|TRACE|GW:00:80:00:00:00:00:a9:82|SEEN|127.0.0.1:55739
0:56:44:959|TRACE|GW:00:80:00:00:00:00:a9:82|SEEN|
0:56:44:960|INFO|GW:00:80:00:00:00:00:a9:82|FRAME-RX|Parsing 1 packets
0:56:44:960|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|DATA: 400100000000000001f6608a5f13cc46da57fd37
0:56:44:961|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|FREQ: 920.400000 MHz DR0 RSSI: -40 dB SNR: 70 cB
0:56:44:961|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|TYPE: Unconfirmed Up
0:56:44:961|DEBUG|GW:00:80:00:00:00:00:a9:82|PACKET-RX|ADDR: 00:00:00:01 FCnt:0000
0:56:44:962|TRACE|Checking 00000000 sequence number
0:56:44:963|INFO|ED:00-80-00-00-00-00-a6-b7|CHECK-PKT|FCNT: 00000000 LAST-FCNT: 00000000 Duplicate: no
0:56:44:963|INFO|ED:00-80-00-00-00-00-a6-b7|CHECK-MIC|ADDR: 00:00:00:01 passed
0:56:44:963|INFO|ED:00-80-00-00-00-00-a6-b7|PER|nan%
0:56:44:969|DEBUG|ED:00-80-00-00-00-00-a6-b7|PACKET-RX|GW:00:80:00:00:00:00:a9:82 Time_us:27237132
0:56:44:969|DEBUG|ED:00-80-00-00-00-00-a6-b7|PACKET-RX|Downlink Packets Queued: 0
0:56:44:969|INFO|ED:00-80-00-00-00-00-a6-b7|FCTRL|ADR:0 ADRACK:0 ACK:0 CLASS:A OPTS:0
0:56:44:984|INFO|ED:00-80-00-00-00-00-a6-b7|SCHED-TX|Use RX1 TOA:82 ms
0:56:44:986|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|JSON: {“chan”:2,“codr”:“4/5”,“data”:“QAEAAAAAAAAB9mCKXxPMRtpX/Tc=”,“datr”:“SF10BW125”,“freq”:920.39999999999998,“lsnr”:7,“modu”:“LORA”,“rfch”:0,“rssi”:-40,“size”:20,“stat”:1,“time”:“2017-11-08T00:56:44.958092Z”,“tmst”:27237132}
0:56:45:715|INFO|ED:00-80-00-00-00-00-a6-b7|FRAME-TX|Nothing to transmit

From the mDot when it tries to join I get the following for an unsuccessful join.

[INFO] Send join request RxDelay: 1 Rx1Offset: 0 Rx2Freq: 923300000 Rx2Dr: 8
[INFO] Configure radio for TX
[INFO] Configure radio for TX
[INFO] Configure radio for TX
[INFO] Rx Window 1
[INFO] Rx Window 2
[ERROR] Failed to join network
[ERROR] failed to join network -4:Join Error

What I notice straight up is that the Rx2 frequency of the mDot is 923.3MHz wheras both the working Multitech Conduit and the not working Loraserver are transmitting on 925.1MHz.
I’m not exactly sure what I should be looking at, any help would be much appreciated.

Could you also share some logs from the loraserver and lora-app-server process?

One common pitfall is that it is not always (directly) clear in which byte order the DevEUI, AppEUI and AppKey must be entered. Please see also https://docs.loraserver.io/lora-app-server/use/devices/ for an example (also mDot).

Thanks for your response. I don’t think it can be the byte order because the node gets accepted by the lorawan server. So that must confirm the the DevID, AppEUI and AppKey are all in the correct endianess?

I moved on to trying with your lorawan-server (the standalone single install) because I thought it would could be my implementation, however I have the exact same problem here.
I’ll try to get you the logs from the loraserver and lora-app-server

And here is the loraserver and lora-app-server logs:

Lora-App-Server

Nov 10 06:26:52 raspberrypi systemd[1]: Starting LoRa Server…
Nov 10 06:26:52 raspberrypi systemd[1]: Started LoRa Server.
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“starting LoRa Server” band=“AU_915_928” docs=“https://docs.loraserver.io/” net_id=010203 version=0.21.0
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“setup redis connection pool” url=“redis://localhost:6379”
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“connecting to postgresql”
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“backend/gateway: connecting to mqtt broker” server=“tcp://localhost:1883”
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“connecting to application-server” ca-cert= server=“127.0.0.1:8001” tls-cert= tls-key=
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“backend/gateway: connected to mqtt server”
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“backend/gateway: subscribing to rx topic” topic=“gateway/+/rx”
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“no network-controller configured”
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“applying database migrations”
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“backend/gateway: subscribing to stats topic” topic=“gateway/+/stats”
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“migrations applied” count=0
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“starting api server” bind=“0.0.0.0:8000” ca-cert= tls-cert= tls-key=
Nov 10 06:26:52 raspberrypi loraserver[18385]: time=“2017-11-10T06:26:52Z” level=info msg=“starting gateway api server” bind=“0.0.0.0:8002” ca-cert= tls-cert= tls-key=
Nov 10 06:27:43 raspberrypi loraserver[18385]: time=“2017-11-10T06:27:43Z” level=info msg=“gateway deleted” mac=aa555a0000000101
Nov 10 06:28:23 raspberrypi loraserver[18385]: time=“2017-11-10T06:28:23Z” level=error msg=“backend/gateway: mqtt connection error: EOF”
Nov 10 06:28:24 raspberrypi loraserver[18385]: time=“2017-11-10T06:28:24Z” level=info msg=“backend/gateway: connected to mqtt server”
Nov 10 06:28:24 raspberrypi loraserver[18385]: time=“2017-11-10T06:28:24Z” level=info msg=“backend/gateway: subscribing to rx topic” topic=“gateway/+/rx”
Nov 10 06:28:24 raspberrypi loraserver[18385]: time=“2017-11-10T06:28:24Z” level=info msg=“backend/gateway: subscribing to stats topic” topic=“gateway/+/stats”

LoraServer

Nov 10 07:02:46 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:02:46Z” level=info msg=“node updated” dev_eui=008000000000a6b7
Nov 10 07:02:46 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:02:46Z” level=info msg=“join-request accepted” app_eui=8b7c2172937dd4ef application_name=TestApp dev_addr=077aa330 dev_eui=008000000000a6b7 node_name=testnode
Nov 10 07:02:46 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:02:46Z” level=info msg=“handler/mqtt: publishing join notification” topic=“application/1/node/008000000000a6b7/join”
Nov 10 07:02:51 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:02:51Z” level=info msg=“node updated” dev_eui=008000000000a6b7
Nov 10 07:02:51 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:02:51Z” level=info msg=“join-request accepted” app_eui=8b7c2172937dd4ef application_name=TestApp dev_addr=072669a2 dev_eui=008000000000a6b7 node_name=testnode
Nov 10 07:02:51 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:02:51Z” level=info msg=“handler/mqtt: publishing join notification” topic=“application/1/node/008000000000a6b7/join”
Nov 10 07:02:55 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:02:55Z” level=info msg=“node updated” dev_eui=008000000000a6b7
Nov 10 07:02:55 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:02:55Z” level=info msg=“join-request accepted” app_eui=8b7c2172937dd4ef application_name=TestApp dev_addr=06e67b1c dev_eui=008000000000a6b7 node_name=testnode
Nov 10 07:02:55 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:02:55Z” level=info msg=“handler/mqtt: publishing join notification” topic=“application/1/node/008000000000a6b7/join”
Nov 10 07:02:59 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:02:59Z” level=info msg=“node updated” dev_eui=008000000000a6b7
Nov 10 07:02:59 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:02:59Z” level=info msg=“join-request accepted” app_eui=8b7c2172937dd4ef application_name=TestApp dev_addr=063abdb6 dev_eui=008000000000a6b7 node_name=testnode
Nov 10 07:02:59 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:02:59Z” level=info msg=“handler/mqtt: publishing join notification” topic=“application/1/node/008000000000a6b7/join”
Nov 10 07:03:03 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:03:03Z” level=info msg=“node updated” dev_eui=008000000000a6b7
Nov 10 07:03:03 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:03:03Z” level=info msg=“join-request accepted” app_eui=8b7c2172937dd4ef application_name=TestApp dev_addr=06b17775 dev_eui=008000000000a6b7 node_name=testnode
Nov 10 07:03:03 raspberrypi lora-app-server[18316]: time=“2017-11-10T07:03:03Z” level=info msg=“handler/mqtt: publishing join notification” topic=“application/1/node/008000000000a6b7/join”

Yes, that confirms that the DevEUI, AppEUI and AppKey are in the right byte order. Could you also post the output of the gateway/# MQTT topic? That should give some more information regarding the frequencies used for uplink / downlink.

Here is the output from MQTT

gateway/b827ebfffea5d79d/stats {"mac":"b827ebfffea5d79d","time":"2017-11-10T06:31:33Z","latitude":10,"longitude":20,"altitude":-1,"rxPacketsReceived":1,"rxPacketsReceivedOK":0,"txPacketsReceived":0,"txPacketsEmitted":0,"customData":null}
gateway/b827ebfffea5d79d/rx {"rxInfo":{"mac":"b827ebfffea5d79d","time":"0001-01-01T00:00:00Z","timestamp":276519476,"frequency":920200000,"channel":1,"rfChain":0,"crcStatus":1,"codeRate":"4/5","rssi":-42,"loRaSNR":9.5,"size":23,"dataRate":{"modulation":"LORA","spreadFactor":10,"bandwidth":125}},"phyPayload":"AO/UfZNyIXyLt6YAAAAAgABr8BTwtFs="}
gateway/b827ebfffea5d79d/tx {"txInfo":{"mac":"b827ebfffea5d79d","immediately":false,"timestamp":281519476,"frequency":923900000,"power":20,"dataRate":{"modulation":"LORA","spreadFactor":10,"bandwidth":500},"codeRate":"4/5","iPol":null},"phyPayload":"IA6Lpj8eajQtzHqpZ4rwuFU="}
gateway/b827ebfffea5d79d/rx {"rxInfo":{"mac":"b827ebfffea5d79d","time":"0001-01-01T00:00:00Z","timestamp":280913498,"frequency":920700000,"channel":8,"rfChain":0,"crcStatus":1,"codeRate":"4/5","rssi":-41,"loRaSNR":10.8,"size":23,"dataRate":{"modulation":"LORA","spreadFactor":8,"bandwidth":500}},"phyPayload":"AO/UfZNyIXyLt6YAAAAAgAA3qWz858o="}
gateway/b827ebfffea5d79d/tx {"txInfo":{"mac":"b827ebfffea5d79d","immediately":false,"timestamp":285913498,"frequency":925100000,"power":20,"dataRate":{"modulation":"LORA","spreadFactor":7,"bandwidth":500},"codeRate":"4/5","iPol":null},"phyPayload":"IHWtK+TAYlFgNvHLsniDJMs="}
gateway/b827ebfffea5d79d/rx {"rxInfo":{"mac":"b827ebfffea5d79d","time":"0001-01-01T00:00:00Z","timestamp":285650476,"frequency":920200000,"channel":1,"rfChain":0,"crcStatus":1,"codeRate":"4/5","rssi":-43,"loRaSNR":10,"size":23,"dataRate":{"modulation":"LORA","spreadFactor":10,"bandwidth":125}},"phyPayload":"AO/UfZNyIXyLt6YAAAAAgADCIj6FnRk="}
gateway/b827ebfffea5d79d/tx {"txInfo":{"mac":"b827ebfffea5d79d","immediately":false,"timestamp":290650476,"frequency":923900000,"power":20,"dataRate":{"modulation":"LORA","spreadFactor":10,"bandwidth":500},"codeRate":"4/5","iPol":null},"phyPayload":"IOJqKPS4EPcOz2clE5Yxa8M="}
gateway/b827ebfffea5d79d/rx {"rxInfo":{"mac":"b827ebfffea5d79d","time":"0001-01-01T00:00:00Z","timestamp":288810224,"frequency":920700000,"channel":8,"rfChain":0,"crcStatus":1,"codeRate":"4/5","rssi":-42,"loRaSNR":11,"size":23,"dataRate":{"modulation":"LORA","spreadFactor":8,"bandwidth":500}},"phyPayload":"AO/UfZNyIXyLt6YAAAAAgAAOqQrcet4="}
gateway/b827ebfffea5d79d/tx {"txInfo":{"mac":"b827ebfffea5d79d","immediately":false,"timestamp":293810224,"frequency":925100000,"power":20,"dataRate":{"modulation":"LORA","spreadFactor":7,"bandwidth":500},"codeRate":"4/5","iPol":null},"phyPayload":"IISwxnGWq6WnzZeheRnYfTQ="}
gateway/b827ebfffea5d79d/stats {"mac":"b827ebfffea5d79d","time":"2017-11-10T06:31:51Z","latitude":10,"longitude":20,"altitude":-1,"rxPacketsReceived":3,"rxPacketsReceivedOK":2,"txPacketsReceived":0,"txPacketsEmitted":0,"customData":null}
gateway/b827ebfffea5d79d/rx {"rxInfo":{"mac":"b827ebfffea5d79d","time":"0001-01-01T00:00:00Z","timestamp":294545164,"frequency":920000000,"channel":0,"rfChain":0,"crcStatus":1,"codeRate":"4/5","rssi":-43,"loRaSNR":8.8,"size":23,"dataRate":{"modulation":"LORA","spreadFactor":10,"bandwidth":125}},"phyPayload":"AO/UfZNyIXyLt6YAAAAAgAAaSGsMcYQ="}
gateway/b827ebfffea5d79d/tx {"txInfo":{"mac":"b827ebfffea5d79d","immediately":false,"timestamp":299545164,"frequency":923300000,"power":20,"dataRate":{"modulation":"LORA","spreadFactor":10,"bandwidth":500},"codeRate":"4/5","iPol":null},"phyPayload":"IMaBI8exY8t1Kq0GgvaM/FM="}
gateway/b827ebfffea5d79d/rx {"rxInfo":{"mac":"b827ebfffea5d79d","time":"0001-01-01T00:00:00Z","timestamp":299937206,"frequency":920700000,"channel":8,"rfChain":0,"crcStatus":1,"codeRate":"4/5","rssi":-43,"loRaSNR":10.8,"size":23,"dataRate":{"modulation":"LORA","spreadFactor":8,"bandwidth":500}},"phyPayload":"AO/UfZNyIXyLt6YAAAAAgADny+9FfxE="}
gateway/b827ebfffea5d79d/tx {"txInfo":{"mac":"b827ebfffea5d79d","immediately":false,"timestamp":304937206,"frequency":925100000,"power":20,"dataRate":{"modulation":"LORA","spreadFactor":7,"bandwidth":500},"codeRate":"4/5","iPol":null},"phyPayload":"INY/gXPj/0R753IIEj4bVas="}
gateway/b827ebfffea5d79d/stats {"mac":"b827ebfffea5d79d","time":"2017-11-10T06:32:03Z","latitude":10,"longitude":20,"altitude":-1,"rxPacketsReceived":4,"rxPacketsReceivedOK":3,"txPacketsReceived":6,"txPacketsEmitted":5,"customData":null}

To take an example:

gateway/b827ebfffea5d79d/rx {"rxInfo":{"mac":"b827ebfffea5d79d","time":"0001-01-01T00:00:00Z","timestamp":294545164,"frequency":920000000,"channel":0,"rfChain":0,"crcStatus":1,"codeRate":"4/5","rssi":-43,"loRaSNR":8.8,"size":23,"dataRate":{"modulation":"LORA","spreadFactor":10,"bandwidth":125}},"phyPayload":"AO/UfZNyIXyLt6YAAAAAgAAaSGsMcYQ="}
gateway/b827ebfffea5d79d/tx {"txInfo":{"mac":"b827ebfffea5d79d","immediately":false,"timestamp":299545164,"frequency":923300000,"power":20,"dataRate":{"modulation":"LORA","spreadFactor":10,"bandwidth":500},"codeRate":"4/5","iPol":null},"phyPayload":"IMaBI8exY8t1Kq0GgvaM/FM="}

Uplink:
Freq: 920000000 = Channel 24
SF10 @ 125kHz = DR2

Expected downlink:

Channel: 24%8 = 0 = Freq 923300000
DR2 uplink => DR10 downlink
DR10 = SF10 @ 500kHz

This matches exactly the properties of .../tx. In other words, it seems that the properties of the downlink join-accept are according to the LoRaWAN Regional Parameters for the AU915-928 band. Could it be that you have some non-standard config on your mDot?

Yes this is really quite possible as it felt like it was an ‘ad-hoc’ firmware Multitech built for the mDot to work in Australia. So it is quite possible that it does not meet the standard LoraWAN.
Knowing this, I started to compare between the Multitech Conduit (which does connect successfully) and the private lorawan server I’m building with your software.
As a comparison I monitored the outputs from the Conduit and this is the response: Nothing here points out to me but hopefully with your knowledge it becomes clear where I’ve setup wrongly.

0:56:38:487|INFO|GW:00:80:00:00:00:00:a9:82|FRAME-RX|Parsing 1 packets
0:56:38:488|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|DATA: 00efd47d9372217c8bb7a6000000008000b7e09bfdf6f9
0:56:38:489|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|FREQ: 921.000000 MHz DR0 RSSI: -42 dB SNR: 92 cB
0:56:38:489|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|TYPE: Join Request
0:56:38:490|DEBUG|GW:00:80:00:00:00:00:a9:82|JOINREQ-RX|00efd47d9372217c8bb7a6000000008000b7e0
0:56:38:490|DEBUG|GW:00:80:00:00:00:00:a9:82|DEV-EUI|00-80-00-00-00-00-a6-b7
0:56:38:490|DEBUG|GW:00:80:00:00:00:00:a9:82|APP-EUI|8b-7c-21-72-93-7d-d4-ef
0:56:38:490|DEBUG|GW:00:80:00:00:00:00:a9:82|DEV-NONCE|e0b7
0:56:38:491|DEBUG|ED:00-80-00-00-00-00-a6-b7|CHECK-KEY|MIC Valid
0:56:38:492|DEBUG|ED:00-80-00-00-00-00-a6-b7|APP-NONCE|ef0b90
0:56:38:494|INFO|ED:00-80-00-00-00-00-a6-b7|DEV-ADDR|Found in DB 1
0:56:38:495|DEBUG|Update session keys
0:56:38:499|DEBUG|GenerateJoinRequestIntegrityCode
0:56:38:500|DEBUG|node is active
0:56:38:501|INFO|ED:00-80-00-00-00-00-a6-b7|QUEUE-TX|JOIN SIZE: 17
0:56:38:501|DEBUG|Update stats
0:56:38:501|DEBUG|Join packet received
0:56:38:502|DEBUG|transmitController.ReceivedFrame
0:56:38:502|DEBUG|ED:00-80-00-00-00-00-a6-b7|PACKET-RX|GW:00:80:00:00:00:00:a9:82 Time_us:20759604
0:56:38:502|DEBUG|ED:00-80-00-00-00-00-a6-b7|PACKET-RX|Downlink Packets Queued: 1
0:56:38:530|INFO|Send Join Accept - EUI: 00-80-00-00-00-00-a6-b7 ADDR: 00000001
0:56:38:531|INFO|Schedule TX Time on air: 92 ms
0:56:38:532|DEBUG|Scheduling for Rx Window 1 00:00:00:01
0:56:38:533|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|JSON: {“chan”:5,“codr”:“4/5”,“data”:“AO/UfZNyIXyLt6YAAAAAgAC34Jv99vk=”,“datr”:“SF10BW125”,“freq”:921,“lsnr”:9.1999999999999993,“modu”:“LORA”,“rfch”:1,“rssi”:-42,“size”:23,“stat”:1,“time”:“2017-11-08T00:56:38.483687Z”,“tmst”:20759604}
0:56:39:243|INFO|GW:00:80:00:00:00:00:a9:82|FRAME-TX|IP: 127.0.0.1:55739 CH: LC6 NODE: 00:00:00:01 FCNT: 00000000 REPEAT: 0
0:56:39:255|INFO|ED:00-80-00-00-00-00-a6-b7|SCHED-TX|Q-SIZE: 1 PKT-SIZE: 17 PKT-ROOM: 242
0:56:39:255|TRACE|App Data Queue - Join Popped
0:56:39:255|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-TX|DATA: 202db3ac132b72cb2222dcb93aacfb91b1
0:56:39:257|DEBUG|GW:00:80:00:00:00:00:a9:82|PACKET-TX|RX1 OFFSET: 1000000
0:56:39:260|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-TX|JSON: {“txpk”:{“appeui”:“8b-7c-21-72-93-7d-d4-ef”,“codr”:“4/5”,“data”:“IC2zrBMrcssiIty5Oqz7kbE”,“datr”:“SF10BW500”,“deveui”:“00-80-00-00-00-00-a6-b7”,“freq”:925.10000000000002,“ipol”:true,“modu”:“LORA”,“ncrc”:true,“powe”:29,“rfch”:0,“size”:17,“tmst”:21759604}}
0:56:39:262|INFO|GW:00:80:00:00:00:00:a9:82|UDP-TX|JSON-SIZE:255
0:56:42:56|TRACE|GW:00:80:00:00:00:00:a9:82|SEEN|127.0.0.1:55739
0:56:44:959|TRACE|GW:00:80:00:00:00:00:a9:82|SEEN|
0:56:44:960|INFO|GW:00:80:00:00:00:00:a9:82|FRAME-RX|Parsing 1 packets
0:56:44:960|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|DATA: 400100000000000001f6608a5f13cc46da57fd37
0:56:44:961|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|FREQ: 920.400000 MHz DR0 RSSI: -40 dB SNR: 70 cB
0:56:44:961|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|TYPE: Unconfirmed Up
0:56:44:961|DEBUG|GW:00:80:00:00:00:00:a9:82|PACKET-RX|ADDR: 00:00:00:01 FCnt:0000
0:56:44:962|TRACE|Checking 00000000 sequence number
0:56:44:963|INFO|ED:00-80-00-00-00-00-a6-b7|CHECK-PKT|FCNT: 00000000 LAST-FCNT: 00000000 Duplicate: no
0:56:44:963|INFO|ED:00-80-00-00-00-00-a6-b7|CHECK-MIC|ADDR: 00:00:00:01 passed
0:56:44:963|INFO|ED:00-80-00-00-00-00-a6-b7|PER|nan%
0:56:44:969|DEBUG|ED:00-80-00-00-00-00-a6-b7|PACKET-RX|GW:00:80:00:00:00:00:a9:82 Time_us:27237132
0:56:44:969|DEBUG|ED:00-80-00-00-00-00-a6-b7|PACKET-RX|Downlink Packets Queued: 0
0:56:44:969|INFO|ED:00-80-00-00-00-00-a6-b7|FCTRL|ADR:0 ADRACK:0 ACK:0 CLASS:A OPTS:0
0:56:44:984|INFO|ED:00-80-00-00-00-00-a6-b7|SCHED-TX|Use RX1 TOA:82 ms
0:56:44:986|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|JSON: {“chan”:2,“codr”:“4/5”,“data”:“QAEAAAAAAAAB9mCKXxPMRtpX/Tc=”,“datr”:“SF10BW125”,“freq”:920.39999999999998,“lsnr”:7,“modu”:“LORA”,“rfch”:0,“rssi”:-40,“size”:20,“stat”:1,“time”:“2017-11-08T00:56:44.958092Z”,“tmst”:27237132}
0:56:45:715|INFO|ED:00-80-00-00-00-00-a6-b7|FRAME-TX|Nothing to transmit

Received:

0:56:38:533|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-RX|JSON: {“chan”:5,“codr”:“4/5”,“data”:“AO/UfZNyIXyLt6YAAAAAgAC34Jv99vk=”,“datr”:“SF10BW125”,“freq”:921,“lsnr”:9.1999999999999993,“modu”:“LORA”,“rfch”:1,“rssi”:-42,“size”:23,“stat”:1,“time”:“2017-11-08T00:56:38.483687Z”,“tmst”:20759604}

SF10 / BW 125 kHz = DR2 (maps to DR10 downlink)
Freq: 921 Mhz = channel (921-915.2) / 0.2 = 29

Reply:

0:56:39:260|DEBUG|GW:00:80:00:00:00:00:a9:82|FRAME-TX|JSON: {“txpk”:{“appeui”:“8b-7c-21-72-93-7d-d4-ef”,“codr”:“4/5”,“data”:“IC2zrBMrcssiIty5Oqz7kbE”,“datr”:“SF10BW500”,“deveui”:“00-80-00-00-00-00-a6-b7”,“freq”:925.10000000000002,“ipol”:true,“modu”:“LORA”,“ncrc”:true,“powe”:29,“rfch”:0,“size”:17,“tmst”:21759604}}

SF10 / BW500 kHz = DR10 OK
Freq: 925.1 MHz = channel (925.1-923.3) / 0.6) = 3

Expected downlink channel: 29 % 8 = 5. Seems like that is the issue if I didn’t make any mistakes.

Please:

Thanks for directing me to the LoRaWAN Regional Parameters, I’m understanding the spec alot better now.

I’ve done the calculations from the spec and got the same results as what you did. I’ve updated the mDot to the latest version and still getting unexpected downlink frequencies.

Looking at the Multitech Conduit output again I’ve noticed there’s a offset RX1 Offset.

0:56:39:257|DEBUG|GW:00:80:00:00:00:00:a9:82|PACKET-TX|RX1 OFFSET: 1000000

Could this be causing the difference in downlink channel? I’ve tried a bunch of different calculations trying to recreate the Multitech Conduit but haven’t been able to get the same answer.

Looking at the value 1000000 that looks like it maps to 1 second to me, which is the default RX1 receive-window delay (but that is just a guess). Anyway, that should not influence the frequency. This is always uplink channel % 8 = downlink channel

I think it would be best to contact Multitech about this and point them to this discussion and our findings. In the end they should be able to give support for the mDot (firmware).

Ok Thanks @brocaar. I have contacted Multitech and I’ll let the Loraserver.io community know their response.

Getting somewhere I think. Multitech recommended to change the mDot connection to public for the uplink channel % 8 = downlink channel.
When the mDot tries to connect now it shows:
[INFO] Send join request RxDelay: 5 Rx1Offset: 0 Rx2Freq: 923300000 Rx2Dr: 8

An RxDelay of 5 seconds i take it?
How do I set the join delay in the lorawan-server?

I noticed in the lorawan-server.script in /usr/lib/lorawan-server/releases/0.4.1.3 there are specific delay settings for US902-928. Perhaps I have to add the delay or is this already the default?

What’s also concerning is that the transmit message from is sending on SF8BW500. This does not look right to me and I’ll go back to Multitech enquiring about this.

{“rxpk”:[{“tmst”:3556567309,“chan”:8,“rfch”:0,“freq”:920.700000,“stat”:1,“modu”:“LORA”,“datr”:“SF8BW500”,“codr”:“4/5”,“lsnr”:10.5,“rssi”:-16,“size”:23,“data”:“AO/UfZNyIXyLt6YAAAAAgABKHENro5k=”}]}

This is fine. The join-accept message has a delay of 5 seconds (per specification) :slight_smile:

Hi, @Brenton_Gray.

If it’s of any use, we faced a somewhat similar problem using the RAK831 gateway with the MP packet forwarder for the US band. We could see loraserver getting and accepting the join requests, but at the end device we saw a “denied” status after the join request. We switched back to the poly packet forwarder and everything worked fine again, so our guess with @dhinojosac is that there’s some parameter (which we haven’t found/fixed yet) in the newer packet forwarder that messes the downlink messages and thus the join fails at the node’s side.

I’m not sure what packet forwarder you are running, but if it’s the mp_pkt_fwd, you could try switching to the poly_pkt_fwd to confirm or discard issues with the packet forwarder.

Apart from two RAK831s, ee own a Multitech Conduit gateway too, which uses and older packet forwarder, and it works fine with our custom nodes. We also own an mDot node but haven’t tried it with the mp_pkt_fwd. We could do some tests to check if we encounter the same issue as you.

Thanks for your input @iegomez.
I ended up solving it!
Originally I had the mdot and the packet_forwarder set to private in the global_conf:"lorawan_public" : false,
This was leading to the wrong downlink channel being selected as shown above (in private mode it doesn’t adhere to the spec??)

Anyway after setting it to public mode in the global_conf and in the mDot configuration it now joins OTA and I can receive packets. Thanks for all your help.

Good to hear that you got it working.

There was a topic about private/public networks and Multitech devices on the forum some time ago. You might want to take a look at it, the latest replies share some good pointers: https://forum.loraserver.io/t/relation-between-sync-word-private-network-and-end-nodes/191/13