Multitech Conduit
-
Has anyone got a LoPy connecting to a MultiTech Conduit. Not having much luck. lora.has_joined() keeps giving me false. If anyone has some example config it would be appreciated.
MultiTech config:
{ "lora": { "netID": "010203", /* netID for beacon packets */ "frequencyBand": "868", /* US="915", EU="868" */ "frequencySubBand": 7, /* Sub-band for US operation, 1-8 */ "rx1DatarateOffset": 0, /* Datarate offset for mote rx window 1 sent in join response (0-3) */ "rx2Datarate": 12, /* Datarate for mote rx window 2 sent in join response (7-12) */ "maxTxPower": 14, /* Max Tx power (dBm), -6 to 26 */ "frequencyEU": 869500000 /* center freq for extra EU channels (Hz) */ }, "udp": { "appPortUp": 1784, /* port for user-developed application use */ "appPortDown": 1786 /* port for user-developed application use */ }, "addressRange": { "start": "00:00:00:01", /* address range used for mDots */ "end": "FF:FF:FF:FE" }, "network": { "public": true, /* set to false for private LoRa network with mDots + Conduit */ "leasetime": 0, /* time until mDot join expires (minutes) or 0 for no expiration */ "eui": "8008800880088008", "key": "80-08-80-08-80-08-80-08-80-08-80-08-80-08-80-08" }, "log" : { "console" : true, "syslog" : false, "level" : 100, /* error=10, warn=20, info=30, debug=50, trace=60, max=100 */ "path": "/var/log/lora-network-server.log" }, "mqtt": { "enabled": true } }LoPy:
from network import LoRa import socket lora = LoRa(mode=LoRa.LORAWAN) auth = (bytes([8, 0, 0, 8, 8, 0, 0, 8, 8, 0, 0, 8, 8, 0, 0, 8]), bytes([8, 0, 0, 8, 8, 0, 0, 8,8, 0, 0, 8, 8, 0, 0, 8,8, 0, 0, 8, 8, 0, 0, 8,8, 0, 0, 8, 8, 0, 0, 8]), bytes([8, 0, 0, 8, 0, 0, 0, 1])) lora.join(activation=LoRa.OTAA, auth=auth, timeout=0) while not lora.has_joined(): pass s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setblocking(False) s.send('Hello from the LoPy') data = s.recv(64) print(data) -
We have the LoPy working with the Conduit in our test bench, but we have reports of other users trying to connect to TTN Gateways and having issues. The symptom is that the Gateway accepts the join request from the LoPy but the LoPy never receives the join accept message. We are trying to figure it out what is causing that and hopefully we'll provide a solution in the next release.
Cheers,
Daniel -
The configuration of our Multi-tech Gateways is as follows:
{ "__v" : 2, "addressRange" : { "end" : "FF:FF:FF:FE", "start" : "00:00:00:01" }, "db" : "/var/config/lora/lora-network-server.db", "log" : { "console" : false, "level" : 30, "path" : "/var/log/", "syslog" : true }, "lora" : { "ADRStep" : 30, "antennaGain" : 3, "beaconDelay" : 0, "beaconInterval" : 0, "beaconPower" : 27, "channelPlan" : "EU868", "dutyCyclePeriod" : 60, "enabled" : true, "eui_1" : "00:80:00:00:00:00:B6:7D", "frequencyBand" : "EU868", "frequencyEU" : 869500000, "frequencySubBand" : 1, "joinByteOrder" : "LSB", "maxDatarate" : 5, "maxDatarateEU" : 5, "maxDatarateUS" : 4, "maxTxPower" : 26, "minDatarate" : 0, "minDatarateEU" : 0, "minDatarateUS" : 0, "netID" : "000000", "nodeQueueSize" : 16, "packetForwarderConfig" : "", "packetForwarderMode" : false, "rx1DatarateOffset" : 0, "rx2Datarate" : 12 }, "mqtt" : { "enabled" : true, "host" : "127.0.0.1", "port" : 1883 }, "network" : { "eui" : "ada4dae3ac12676b", "key" : "11b0282a189b75b0b4d2d8c7fa38548b", "leasetime" : 0, "name" : "pycomltd", "passphrase" : "goinvent", "public" : true }, "test" : { "disableDutyCycle" : false, "disableRxJoin1" : false, "disableRxJoin2" : false, "disableRxWindow1" : false, "disableRxWindow2" : false }, "udp" : { "appPortDown" : 1786, "appPortUp" : 1784, "downstreamPort" : 1782, "upstreamPort" : 1780 }, "whitelist" : { "devices" : [], "enabled" : true } }Which works all the way...
In case this gives anyone an idea of why on some Gateways the LoPy never receives the Join accept confirmation.
-
Could it be this:
"joinByteOrder" : "LSB"??
-
Are you using the same example code from the docs. This is the log from my multi tech and the appeui and deveui look wrong.
20:18:23:209|TRACE| Parse upstream message 366 bytes
20:18:23:210|TRACE| Gateway 00:80:00:00:00:00:c4:a9 seen
20:18:23:211|INFO| Parsing 1 rx packets
20:18:23:211|WARNING| Recv'd frame failed CRC check
20:18:29:175|TRACE| Parse downstream message 12 bytes
20:18:29:176|TRACE| Gateway 00:80:00:00:00:00:c4:a9 seen IP address 127.0.0.1:57615
20:18:39:263|TRACE| Parse upstream message 459 bytes
20:18:39:264|TRACE| Gateway 00:80:00:00:00:00:c4:a9 seen
20:18:39:265|INFO| Parsing 1 rx packets
20:18:39:266|WARNING| Recv'd frame failed CRC check
20:18:39:375|TRACE| Parse downstream message 12 bytes
20:18:39:376|TRACE| Gateway 00:80:00:00:00:00:c4:a9 seen IP address 127.0.0.1:57615
20:18:45:678|TRACE| Parse upstream message 243 bytes
20:18:45:679|TRACE| Gateway 00:80:00:00:00:00:c4:a9 seen
20:18:45:680|INFO| Parsing 1 rx packets
20:18:45:681|DEBUG| Received packet000 00 08 00 00 08 08 00 00
008 08 01 00 00 00 08 00 00
010 08 1b 7f e9 ec 58 b320:18:45:681|DEBUG| Rx on 868300000, rssi: -29 snr: 55
20:18:45:682|DEBUG| Received frame: type: Join Request
20:18:45:682|INFO| Received join request
20:18:45:682|DEBUG| BUFFER: 00080000080800000801000000080000081b7f
20:18:45:683|DEBUG| App EUI: 08-00-00-08-08-00-00-08
20:18:45:683|DEBUG| Dev EUI: 08-00-00-08-00-00-00-01
20:18:45:684|DEBUG| Nonce: 00007f1b
20:18:45:684|TRACE| SQL query = SELECT appkey FROM appkeys WHERE appeui = "0800000808000008" AND deveui = "0800000800000001";
20:18:45:686|WARNING| Tossing join request, invalid NET EUI and no record of Dev EUI
20:18:49:575|TRACE| Parse downstream message 12 bytes -
Realised that my my hex values where not consistant now getting a bit further
Parsing 1 rx packets
20:58:22:731|DEBUG| Received packet000 00 08 00 00 08 08 00 00
008 08 01 00 00 00 08 00 00
010 08 03 20 03 e5 d3 6e20:58:22:731|DEBUG| Rx on 868100000, rssi: -29 snr: 75
20:58:22:731|DEBUG| Received frame: type: Join Request
20:58:22:731|INFO| Received join request
20:58:22:732|DEBUG| BUFFER: 00080000080800000801000000080000080320
20:58:22:732|DEBUG| App EUI: 08-00-00-08-08-00-00-08
20:58:22:733|DEBUG| Dev EUI: 08-00-00-08-00-00-00-01
20:58:22:733|DEBUG| Nonce: 00002003
20:58:22:734|DEBUG| MIC mismatch, ignore join request da98791b != 03e5d36e -
Daniel
Could you publish the python side of the connection that worked for you?
Justin
-
Hi everyone,
The piece of code below works with the Multi-tech config that I posted before:
from network import LoRa import time lora = LoRa(mode=LoRa.LORAWAN) auth = (bytes([0x11, 0xb0, 0x28, 0x2a, 0x18, 0x9b, 0x75, 0xb0, 0xb4, 0xd2, 0xd8, 0xc7, 0xfa, 0x38, 0x54, 0x8b]), bytes([0xad, 0xa4, 0xda, 0xe3, 0xac, 0x12, 0x67, 0x6b]), lora.mac()) lora.join(activation=LoRa.OTAA, auth=auth, timeout=0) while not lora.has_joined(): time.sleep(2.0) print('Waiting...') import socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setblocking(False) s.send('Pycom')Notice the
time.sleep(2.0)line which is not in the example in the docs :-(
Without thetime.sleep()statement OTAA does not work due to a task priority issue. The problem has already been fixed and will be available on the next release on Tuesday.Cheers,
Daniel -
Hi,
I'm also struggling getting my LoPy to join the LoRaWAN network hosted on a MultiTech Conduit using OTA activation, the
lora.has_joined()condition always returns false. To rule out any byte mistakes on my part, I've used the same AppEUI and AppKey in both the code and the Conduit configuration, as detailed in @daniel's snippet.LoPy v0.9.1.b1 Python Code:
from network import LoRa import time lora = LoRa(mode=LoRa.LORAWAN) print('Running the following LoPy Firmware Version ' + os.uname().release) print('DeviceEui Hex Payload ' + ''.join('{:02x}'.format(x) for x in lora.mac())) auth = (bytes([0x11, 0xb0, 0x28, 0x2a, 0x18, 0x9b, 0x75, 0xb0, 0xb4, 0xd2, 0xd8, 0xc7, 0xfa, 0x38, 0x54, 0x8b]), bytes([0xad, 0xa4, 0xda, 0xe3, 0xac, 0x12, 0x67, 0x6b]), lora.mac()) lora.join(activation=LoRa.OTAA, auth=auth, timeout=0) while not lora.has_joined(): time.sleep(2.0) print('Waiting...') import socket s = socket.socket(socket.AF_LORA, socket.SOCK_RAW) s.setblocking(False) s.send('Hellow LPWAN')MultiTech Conduti ( v1.3.2) LoRaWAN Configuration:
{ "__v" : 1, "addressRange" : { "end" : "FF:FF:FF:FE", "start" : "00:00:00:01" }, "db" : "/var/config/lora/lora-network-server.db", "log" : { "console" : false, "level" : 100, "path" : "/var/log/lora-network-server.log", "syslog" : false }, "lora" : { "ADRStep" : 30, "antennaGain" : 3, "beaconDelay" : 0, "beaconInterval" : 0, "beaconPower" : 27, "channelPlan" : "EU868", "dutyCyclePeriod" : 60, "enabled" : true, "eui_1" : "00:80:00:00:00:00:C4:B5", "frequencyBand" : "EU868", "frequencyEU" : 869500000, "frequencySubBand" : 1, "joinByteOrder" : "LSB", "maxDatarate" : 5, "maxDatarateEU" : 5, "maxDatarateUS" : 4, "maxTxPower" : 26, "minDatarate" : 0, "minDatarateEU" : 0, "minDatarateUS" : 0, "netID" : "000000", "nodeQueueSize" : 16, "packetForwarderConfig" : "", "packetForwarderMode" : false, "rx1DatarateOffset" : 0, "rx2Datarate" : 12 }, "mqtt" : { "enabled" : true, "host" : "127.0.0.1", "port" : 1883 }, "network" : { "eui" : "ada4dae3ac12676b", "key" : "11b0282a189b75b0b4d2d8c7fa38548b", "leasetime" : 0, "name" : "", "passphrase" : "", "public" : true }, "test" : { "disableDutyCycle" : false, "disableRxJoin1" : false, "disableRxJoin2" : false, "disableRxWindow1" : false, "disableRxWindow2" : false }, "udp" : { "appPortDown" : 1786, "appPortUp" : 1784, "downstreamPort" : 1782, "upstreamPort" : 1780 }, "whitelist" : { "devices" : [], "enabled" : true } }Conduit LoRaWAN logs:
11:44:37:99|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen 11:44:37:100|INFO| Parsing 1 rx packets 11:44:37:101|WARNING| Recv'd frame failed CRC check 11:44:46:56|TRACE| Parse downstream message 12 bytes 11:44:46:57|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:44:56:256|TRACE| Parse downstream message 12 bytes 11:44:56:257|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:45:6:456|TRACE| Parse downstream message 12 bytes 11:45:6:457|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:45:16:656|TRACE| Parse downstream message 12 bytes 11:45:16:657|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:45:26:856|TRACE| Parse downstream message 12 bytes 11:45:26:857|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:45:37:56|TRACE| Parse downstream message 12 bytes 11:45:37:57|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:45:47:256|TRACE| Parse downstream message 12 bytes 11:45:47:257|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:45:57:456|TRACE| Parse downstream message 12 bytes 11:45:57:457|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:46:7:656|TRACE| Parse downstream message 12 bytes 11:46:7:656|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:46:17:856|TRACE| Parse downstream message 12 bytes 11:46:17:857|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:46:28:56|TRACE| Parse downstream message 12 bytes 11:46:28:57|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:46:38:256|TRACE| Parse downstream message 12 bytes 11:46:38:257|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:46:48:456|TRACE| Parse downstream message 12 bytes 11:46:48:457|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:46:58:656|TRACE| Parse downstream message 12 bytes 11:46:58:657|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:47:8:856|TRACE| Parse downstream message 12 bytes 11:47:8:856|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:47:19:56|TRACE| Parse downstream message 12 bytes 11:47:19:57|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:47:29:256|TRACE| Parse downstream message 12 bytes 11:47:29:257|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:47:39:456|TRACE| Parse downstream message 12 bytes 11:47:39:457|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:47:49:656|TRACE| Parse downstream message 12 bytes 11:47:49:657|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:47:51:129|TRACE| Parse upstream message 217 bytes 11:47:51:130|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen 11:47:51:131|INFO| Parsing 1 rx packets 11:47:51:131|WARNING| Recv'd frame failed CRC check 11:47:59:857|TRACE| Parse downstream message 12 bytes 11:47:59:858|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:48:10:56|TRACE| Parse downstream message 12 bytes 11:48:10:57|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:48:20:256|TRACE| Parse downstream message 12 bytes 11:48:20:257|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934 11:48:22:449|TRACE| Parse upstream message 431 bytes 11:48:22:450|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen 11:48:22:451|INFO| Parsing 1 rx packets 11:48:22:451|WARNING| Recv'd frame failed CRC check 11:48:30:456|TRACE| Parse downstream message 12 bytes 11:48:30:457|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:48934Thanks in advance for any help on this.
Stuart
-
Stuart
I can confirm that the example code and config allowed me to connect. From my experience you would get more in the log even if the keys and ids were incorrect. Do you have the 868 firmware on the lopy?
Justin
-
@jubbs hi there, and thanks for replying. Does the 868 version refer to the frequency band? Regardless, I'm not sure - I know I updated the LoPys firmware today using the windows update tool, so it's currently on v0.9.1.b1. How do I determine if it's on the 868 version?
-
What country did you select?
-
@stuart The updater choses the frequency based on information in this list. If you select a country that is not in that list, you'll be given the option to flash either the 915 or 868.
There is one exception: if you pick a country where both 915 and 868 are legal to use, the flasher will pick the frequency of one of the nearby countries. If you really want to know, we'll share the exact list of countries / frequencies that the updater is using with you later.
-
@Ralph said in Multitech Conduit:
If you really want to know, we'll share the exact list of countries / frequencies that the updater is using with you later.
Please share :)
-
@bmarkus This is the frequency table used by the Linux updater:
"Argentina",915
"Australia",915
"Austria",868
"Bahrain",868
"Belgium",868
"Brazil",915
"Bulgaria",868
"Canada",915
"China",915
"Colombia",915
"Croatia",868
"Czech Republic",868
"Denmark",868
"Ecuador",915
"Egypt",868
"Estonia",868
"Finland",868
"France",868
"Germany",868
"Greece",868
"Hong Kong",915
"Hungary",868
"India",868
"Indonesia",915
"Ireland",868
"Israel",915
"Italy",868
"Japan",915
"Latvia",868
"Lebanon",868
"Liechtenstein",868
"Lithuania",868
"Luxembourg",868
"Malaysia",915
"Malta",868
"Mexico",915
"Monaco",868
"Netherlands",868
"New Zealand",915
"Norway",868
"Pakistan",868
"Peru",915
"Poland",868
"Portugal",868
"Republic of Korea",915
"Romania",868
"Russian Federation",868
"Saudi Arabia",868
"Singapore",915
"Slovakia",868
"Slovenia",868
"South Africa",915
"Spain",868
"Sweden",868
"Switzerland",868
"Taiwan",915
"Thailand",915
"Turkey",868
"United Arab Emirates",868
"United Kingdom",868
"United States",915
"Not in the list",0 -
Thanks @Xykon, you were faster :)
-
Thanks @Ralph, @jubbs, @bmarkus and @Xykon - I've re-installed the Firmware, selected the UK and started to see some LoraWan log activity which is a good step forward - you can see from the logs here that the device is getting registered:
12:4:42:753|INFO| Parsing 1 rx packets 12:4:42:754|DEBUG| Received packet ================================ 000 00 6b 67 12 ac e3 da a4 008 ad 62 6e 27 96 49 d5 b3 010 70 fc 25 0e 77 cf a6 12:4:42:755|DEBUG| Rx on 868300000, rssi: -18 snr: 75 12:4:42:755|DEBUG| Received frame: type: Join Request 12:4:42:755|INFO| Received join request 12:4:42:756|DEBUG| BUFFER: 006b6712ace3daa4ad626e279649d5b370fc25 12:4:42:756|DEBUG| App EUI: ad-a4-da-e3-ac-12-67-6b 12:4:42:757|DEBUG| Dev EUI: 70-b3-d5-49-96-27-6e-62 12:4:42:757|DEBUG| Nonce: 000025fc 12:4:42:758|DEBUG| MIC is valid 12:4:42:758|DEBUG| Got appkey: 11.b0.28.2a.18.9b.75.b0.b4.d2.d8.c7.fa.38.54.8b 12:4:42:759|DEBUG| DEV NONCE: 25fc 12:4:42:759|DEBUG| APP NONCE: 79745b 12:4:42:759|DEBUG| session keys: 97f3a21d1e2937f3abf9d516c07c380d 56fab4e564aa47a098a58e8eb61836f6 12:4:42:760|TRACE| SQL query = SELECT address FROM nodes WHERE deveui = "70b3d54996276e62"; 12:4:42:761|INFO| Device not found in DB 12:4:42:762|INFO| assigning address: 1 12:4:42:763|TRACE| SQL query = SELECT address FROM nodes where deveui = "70b3d54996276e62"; 12:4:42:765|TRACE| SQL query = INSERT INTO nodes (address, appeui, deveui, authenticationkey, encryptionkey, lastdownmsgseqno, class) VALUES ("00000001", "ada4dae3ac12676b", "70b3d54996276e62", "2b7e151628aed2a6abf7158809cf4f3c", "2b7e151628aed2a6abf7158809cf4f3c", 0, "A") 12:4:42:769|TRACE| SQL query = INSERT INTO packets (node, gateway, seqno, data) VALUES ("00000001", "", 0, ""); 12:4:42:773|TRACE| SQL query = INSERT INTO appkeys (appeui, deveui, appkey) VALUES ("ada4dae3ac12676b", "70b3d54996276e62", "11b0282a189b75b0b4d2d8c7fa38548b"); 12:4:42:776|DEBUG| Update session keys 12:4:42:777|TRACE| SQL query = UPDATE nodes SET authenticationkey = "97f3a21d1e2937f3abf9d516c07c380d", encryptionkey = "56fab4e564aa47a098a58e8eb61836f6" WHERE address = "00000001" 12:4:42:779|DEBUG| Freq 0: 8691000 12:4:42:780|DEBUG| Freq 1: 8693000 12:4:42:780|DEBUG| Freq 2: 8695000 12:4:42:780|DEBUG| Freq 3: 8697000 12:4:42:781|DEBUG| Freq 4: 8699000 12:4:42:781|DEBUG| GenerateJoinRequestIntegrityCode 12:4:42:782|DEBUG| node is active 12:4:42:783|DEBUG| app data size 0 12:4:42:784|INFO| Queue join response 33 bytes 12:4:42:784|DEBUG| Update stats 12:4:42:784|DEBUG| Join packet received 12:4:42:784|DEBUG| transmitController.ReceivedFrame 12:4:42:785|DEBUG| update bestGateway 12:4:42:785|DEBUG| Time: 654662052 12:4:42:785|DEBUG| App Queue Length: 1 12:4:42:786|DEBUG| NewFrame 12:4:42:786|DEBUG| 0 : 00:80:00:00:00:00:c4:b5 == 00:80:00:00:00:00:c4:b5 1 12:4:42:786|DEBUG| update gateway 0 12:4:42:787|DEBUG| DR Index sf: 12 bw: 125 index: 0 12:4:42:787|DEBUG| Rx Frame SEQ 42202 SNR 75 SF 0 12:4:42:787|DEBUG| ADR FindDR : snr : 75 step : 30 12:4:42:788|DEBUG| ADR PRE MIN/MAX DR: 9 12:4:42:788|DEBUG| ADR NEW DR: 5 MIN: 0 MAX: 5 STEP: 30 12:4:42:788|DEBUG| ADR update avgSnr store size: 0 snr: 75 avg: 0 12:4:42:788|DEBUG| ADR update avgSnr store size: 0 snr: 75 avg: 75 12:4:42:789|DEBUG| ReceiveOption : ad 12:4:42:789|TRACE| SQL query = UPDATE nodes SET lastdownmsgseqno = 0 WHERE address = "00000001"; 12:4:42:792|TRACE| SQL query = UPDATE nodes SET jointime = "2016-10-27T12:04:42Z" WHERE address = "00000001" 12:4:42:793|DEBUG| Send MQTT message 228 bytes 12:4:42:794|DEBUG| UDP message: lora/70-b3-d5-49-96-27-6e-62/packet_recv {"chan":1,"codr":"4/5","data":"AGtnEqzj2qStYm4nlknVs3D8JQ53z6Y=","datr":"SF12BW125","freq":868.29999999999995,"lsnr":7.5,"modu":"LORA","rfch":0,"rssi":-18,"size":23,"stat":1,"time":"2016-10-27T12:04:42.751089Z","tmst":654662052} 12:4:42:794|DEBUG| UDP port: 1784 12:4:42:798|TRACE| Published message: 2 12:4:42:798|TRACE| MQTT message: lora/70-b3-d5-49-96-27-6e-62/packet_recv 12:4:42:802|TRACE| SQL query = UPDATE packets SET port = 39, seqno = 0, gateway = "008000000000c4b5", time = "2016-10-27T12:04:42Z", microseconds = 751089, rssi = -18, channel = 1, lsnr_cB = 75, spread = 12, modulationbandwidth = 125, data = "9649d5b370fc25" WHERE node = "00000001" 12:4:42:806|TRACE| SQL query = UPDATE nodes SET lastuppacketid = 1, lastmessagems = 42 WHERE address = "00000001"; 12:4:42:808|TRACE| SQL query = UPDATE gateways SET lastuppacketid = 1 WHERE address = "008000000000c4b5"; 12:4:42:811|DEBUG| getTimeOnAirMs dr: 12 bw: 0 pl: 8 sz: 32 toa: 1810 12:4:42:812|INFO| Send Join Accept - EUI: 70-b3-d5-49-96-27-6e-62 ADDR: 00000001 12:4:42:812|INFO| Schedule TX Time on air: 1820 ms 12:4:42:812|DEBUG| BestGatewayChannel::scheduleAt seq: 0 tm:721931 dur:1820 freq:868300000 12:4:42:813|DEBUG| BestGatewayChannel::scheduleAt gw_seq: 42202 seq: 0 12:4:42:813|DEBUG| BestGatewayChannel 0 : 00:80:00:00:00:00:c4:b5 12:4:42:814|TRACE| Schedule DC band: 1 available: 6312 duration: 1820 freq: 868300000 12:4:42:814|DEBUG| returning 00:80:00:00:00:00:c4:b5 12:4:42:814|DEBUG| Scheduling for Rx Window 1 00:00:00:01 12:4:42:815|DEBUG| Send MQTT message 0 bytes 12:4:42:816|DEBUG| UDP message: lora/70-b3-d5-49-96-27-6e-62/joined 12:4:42:816|DEBUG| UDP port: 1784 12:4:42:817|TRACE| SQL query = SELECT address FROM nodes WHERE deveui = "70b3d54996276e62"; 12:4:42:819|DEBUG| Mosquitto command received 'packet_recv' 12:4:42:819|TRACE| Unknown command 'packet_recv 12:4:42:854|TRACE| Published message: 3 12:4:42:894|TRACE| MQTT message: lora/70-b3-d5-49-96-27-6e-62/joined 12:4:42:894|TRACE| SQL query = SELECT address FROM nodes WHERE deveui = "70b3d54996276e62"; 12:4:42:896|DEBUG| Mosquitto command received 'joined' 12:4:42:896|TRACE| Unknown command 'joined 12:4:44:834|TRACE| Parse downstream message 12 bytes 12:4:44:835|TRACE| Gateway 00:80:00:00:00:00:c4:b5 seen IP address 127.0.0.1:47241 12:4:45:932|TRACE| Parse message 5 bytes 12:4:45:932|TRACE| command: 'stats' 5 12:4:47:505|DEBUG| is frame ready? 12:4:47:506|DEBUG| App Queue Length: 1 12:4:47:506|DEBUG| BestGateway: 8000000000c4b5 12:4:47:507|DEBUG| Start 12:4:47:507|INFO| Frame transmitted to 00:00:00:01 via GW (00:80:00:00:00:00:c4:b5 Chan LC2 127.0.0.1:47241) Seq# 0 12:4:47:508|TRACE| SQL query = UPDATE nodes SET lastdownmsgseqno = 0 WHERE address = "00000001"; 12:4:47:511|DEBUG| App Data Queue: 1 front size: 33 available: 242 12:4:47:511|DEBUG| check if front is join request 33 bytes 12:4:47:511|DEBUG| Start 12:4:47:511|TRACE| App Data Queue - Join Popped 12:4:47:512|DEBUG| Transmitted Frame data ================================ 000 20 c1 4a 1b bf c8 4a 03 008 54 49 c7 31 75 00 3c f3 010 bb e4 f8 27 ae 08 d5 4d 018 56 59 82 4e 24 e2 bc e1 020 8d 12:4:47:514|DEBUG| rx1Offset: 0 rx1Datarate: 12 12:4:47:515|DEBUG| Use JoinResponse Window Time 12:4:47:517|DEBUG| JSON tx: { "txpk" : { "codr" : "4/5", "data" : "IMFKG7/ISgNUSccxdQA887vk+CeuCNVNVlmCTiTivOGN", "datr" : "SF12BW125", "freq" : 868.29999999999995, "ipol" : true, "modu" : "LORA", "ncrc" : false, "powe" : 11, "rfch" : 0, "size" : 33, "tmst" : 659662052 } } 12:4:47:518|DEBUG| Band: 1 DutyCycle: 6362 12:4:47:519|DEBUG| getTimeOnAirMs dr: 12 bw: 0 pl: 8 sz: 33 toa: 1810 12:4:47:519|INFO| Update DC Band: 1 Duration: 1810 time-on-air available: 4552 ms 12:4:47:520|INFO| Transmit UDP message to Gateway 208 bytes 12:4:47:520|DEBUG| Send on socket 212 bytes, payload len: 208 12:4:47:544|DEBUG| Send MQTT message 198 bytes 12:4:47:544|DEBUG| UDP message: lora/70-b3-d5-49-96-27-6e-62/packet_sent {"codr":"4/5","data":"IMFKG7/ISgNUSccxdQA887vk+CeuCNVNVlmCTiTivOGN","datr":"SF12BW125","freq":868.29999999999995,"ipol":true,"modu":"LORA","ncrc":false,"powe":11,"rfch":0,"size":33,"tmst":659662052} 12:4:47:545|DEBUG| UDP port: 1784 12:4:47:548|TRACE| Published message: 4 12:4:47:584|TRACE| MQTT message: lora/70-b3-d5-49-96-27-6e-62/packet_sent 12:4:47:584|TRACE| SQL query = SELECT address FROM nodes WHERE deveui = "70b3d54996276e62"; 12:4:47:586|DEBUG| Mosquitto command received 'packet_sent' 12:4:47:586|TRACE| Unknown command 'packet_sentbut the running code never appears to go past the condition
while not lora.has_joined(): time.sleep(2.5) print('Waiting to join the network...')I can see the confirmation of join stats in the Conduit:
...but no data actually gets sent because as mentioned it doesn't appear to exit the
lora.has_joined()while loop.Any advice on what might be happening here?
Thanks again for all your support.
Stuart
-
@daniel said in Multitech Conduit:
"__v" : 2
What is the significance of "__v" : 2 in the config file for the network server? All Conduits we have (with default setup) uses "__v" : 1
-
@arneme I'm not sure the significance. I connected an xDot to the Conduit today with no problems. I suspect my LoPy LoRa chip may be damaged as it was briefly used without the external antenna attached.
Anyone know if there any way to confirm this?
I can get a join packet out of the LoPy, but that's infrequent and the only packet type I've seen.
-
@stuart Hi Stuart, we have connected different types of devices to the Multitech (including mDot) but we have not been able to connect the LoPy yet. We do see that the LoPy sends a join request and that the Multitech gateway is sending a join ack back, but the LoPy does not manage to "catch" the ack. I think their timing might be off and hopefully they will manage to get this right in later versions of the firmware.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login