Conduit 500kHz Channel

[Jeff Clemmer]

Hello,

We have the conduit configured for sub-band 7.
At BW=500kHz, the node TX freq is 912600000Hz
The node should then listen on 926900000Hz for a packet from the gateway
(Which is confirmed by this post, http://www.multitech.net/developer/forums/topic/otaa-join-issue-using-semtech-sx1272rf1-development-board-and-conduit/#post-11687)

From the Conduit log though, the packet is sent on 925.1MHz. See below…
[like it is calculating the channel based on 125kHz channel index – 925.1 would be DN CH 3 (starting at 0) and 912.6 as a 125kHz channel offset in the sub-band rounded down is 3].

Is this a bug?

21:49:17:157|TRACE| Parse upstream message 238 bytes
21:49:17:158|TRACE| Gateway <snip> seen
21:49:17:159|INFO| Parsing 1 rx packets
21:49:17:160|DEBUG| Received packet
================================
000 80 01 00 00 00 c2 34 00
008 03 07 01 de 6f 98 d1 31
010 91 b6 c9

21:49:17:160|DEBUG| Rx on 912600000, rssi: -78 snr: 88
21:49:17:161|DEBUG| Received frame: type: Confirmed Up
21:49:17:161|DEBUG| Packet received from Node 00:00:00:01 GW <snip> (127.0.0.1) Seq# 34
21:49:17:162|DEBUG| Set node active: 1
21:49:17:162|DEBUG| Expecting packet SeqNo: 00000093
21:49:17:162|DEBUG| Check for dup: 0034 == 0033
21:49:17:163|TRACE| Checking SeqNo: 00000034
21:49:17:163|TRACE| AUTH KEY: <snip>
21:49:17:164|DEBUG| MIC Check: 3191b6c9 == 3191b6c9
21:49:17:164|INFO| SeqNo: 00000034 PrevSeqNo: 00000033 Duplicate: no

21:49:17:164|INFO| Addr: 00:00:00:01 MIC Check: passed
21:49:17:164|DEBUG| update bestGateway
21:49:17:165|DEBUG| Time: 177513107
21:49:17:165|DEBUG| App Queue Length: 0
21:49:17:165|DEBUG| NewFrame
21:49:17:166|DEBUG| <snip>
21:49:17:166|DEBUG| update gateway <snip>
21:49:17:167|DEBUG| DR Index sf: 8 bw: 500 index: 4
21:49:17:167|DEBUG| Rx Frame SEQ 52 SNR 88 SF 4
21:49:17:167|DEBUG| FindDR : snr : 88 100 -12
21:49:17:168|DEBUG| ReceiveOption : 03
21:49:17:168|DEBUG| FCtrl c2 00 0
21:49:17:168|DEBUG| RX frame is class A
21:49:17:168|DEBUG| FCtrl c2 00 0
21:49:17:169|DEBUG| FCtrl c2 00 0
21:49:17:171|TRACE| Packet placed in MQTT message queue
21:49:17:171|TRACE| Updating last recv’d packet info
21:49:17:171|TRACE| SQL query = UPDATE packets SET port = 1, seqno = 52, gateway = <snip>, time = “2016-03-01T21:49:17Z”, microseconds = 157425000, rssi = -78, channel = 8, lsnr_cB = 88, spread = 8, modulationbandwidth = 500, data = “1522a03e” WHERE node = “00000001”
21:49:17:175|TRACE| SQL query = UPDATE nodes SET lastuppacketid = 1, lastmessagems = 15 WHERE address = “00000001”
21:49:17:177|DEBUG| Send MQTT message
21:49:17:177|DEBUG| UDP message: lora/<snip>/up {“chan”:8,”cls”:0,”codr”:”4/5″,”data”:”FSKgPg==”,”datr”:”SF8BW500″,”freq”:”912.6″,”lsnr”:”8.8″,”modu”:”LORA”,”port”:1,”rfch”:0,”rssi”:-78,”seqn”:52,”size”:8,”timestamp”:”2016-03-01T21:49:17Z”,”tmst”:177513107}

21:49:17:178|DEBUG| UDP port: 1784
21:49:17:180|TRACE| Published message: 132
21:49:17:182|TRACE| SQL query = UPDATE gateways SET lastuppacketid = 1 WHERE address = <snip>
21:49:17:185|INFO| Packet accepted from Node 00:00:00:01 GW <snip> (127.0.0.1) Seq# 34 ADR enabled SF8BW500
21:49:17:186|DEBUG| Schedule slot in tx queue
21:49:17:186|DEBUG| getTimeOnAirMs dr: 8 bw: 2 pl: 8 sz: 13 toa: 20
21:49:17:186|INFO| Schedule TX Time on air: 30 ms
21:49:17:186|DEBUG| BestGatewayChannel::scheduleAt
21:49:17:187|DEBUG| 0 : <snip>
21:49:17:187|DEBUG| returning <snip>
21:49:17:978|DEBUG| is frame ready?
21:49:17:978|DEBUG| App Queue Length: 0
21:49:17:978|DEBUG| BestGateway: <snip>
21:49:17:979|DEBUG| Start
21:49:17:979|INFO| Frame transmitted to 00:00:00:01 via GW (<snip> Chan ERR 127.0.0.1:54904) Seq# 93
21:49:17:980|TRACE| SQL query = UPDATE nodes SET lastdownmsgseqno = 147 WHERE address = “00000001”
21:49:17:986|DEBUG| rxDR : 4 stDR : 4
21:49:17:987|DEBUG| rxDR : 4 stDR : 4
21:49:17:988|DEBUG| App Data Queue: 0 front size: 6188 available: 242
21:49:17:989|DEBUG| Transmitted Frame data
================================
000 60 01 00 00 00 20 93 00
008 61 9b 36 61

21:49:17:989|DEBUG| rx1Offset: 0 rx1Datarate: 7
21:49:17:989|DEBUG| Use Normal Window Time
21:49:17:991|DEBUG| JSON tx: {
“txpk” : {
“codr” : “4/5”,
“data” : “YAEAAAAgkwBhmzZh”,
“datr” : “SF7BW500”,
“freq” : 925.10000000000002,
“ipol” : true,
“modu” : “LORA”,
“ncrc” : false,
“powe” : 14,
“rfch” : 0,
“size” : 12,
“tmst” : 178513107
}
}

21:49:17:992|INFO| Transmit message 179 bytes
21:49:17:992|DEBUG| Send on socket 183 bytes, payload len: 179

• This topic was modified 8 years, 8 months ago by Jeff Clemmer.

[Jason Reiss]

Yes, this appears to be a bug in the 0.0.9.2 network server.

[Author]

Posts