1. Home
  2. Getting Started
  3. LoPy
  4. Multitech Conduit

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

Multitech Conduit

  • D

    @arneme and @stuart other users have reported the sams issue, but we have Multi-Tech Gateways as well and we don't have any problems when joining.

    Would you be so kind to share with us the configuration of your Multi-Tech Gateways? In the same way that I posted ours before in this same thread? That will help shed some light into the issue... Thanks!

    Cheers,
    Daniel

    0 A 1 Reply
  • S

    @arneme said in Multitech Conduit:

    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.

    Hi @arneme and thanks for replying. Aye, what you've described there is exactly the behavior I've seen when attempting to connect my LoPy to the Conduit.

    0
  • A

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

    0 S 1 Reply
  • S

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

    0 A 1 Reply
  • A

    @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

    0 S 1 Reply
  • S

    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_sent

    but 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:

    0_1477571092167_upload-a8b8dc93-6632-449a-8ea7-5f900fd0de1c

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

    0
  • Ralph

    Thanks @Xykon, you were faster :)

    0
  • X
    administrators

    @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

    0
  • bmarkus

    @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 :)

    0 X 1 Reply
  • Ralph

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

    0
  • J

    What country did you select?

    0
  • S

    @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?

    0
  • J

    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

    0 S 1 Reply
  • S

    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:48934

    Thanks in advance for any help on this.

    Stuart

    0
  • D

    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 the time.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

    0
  • J

    Daniel

    Could you publish the python side of the connection that worked for you?

    Justin

    0
  • J

    Realised that my my hex values where not consistant now getting a bit further

    Parsing 1 rx packets
    20:58:22:731|DEBUG| Received packet

    000 00 08 00 00 08 08 00 00
    008 08 01 00 00 00 08 00 00
    010 08 03 20 03 e5 d3 6e

    20: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

    0
  • J

    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 packet

    000 00 08 00 00 08 08 00 00
    008 08 01 00 00 00 08 00 00
    010 08 1b 7f e9 ec 58 b3

    20: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

    0
  • D

    Could it be this:

    "joinByteOrder" : "LSB"

    ??

    0
  • D

    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.

    1 A 1 Reply
Log in to reply
 

Pycom on Twitter