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)
    


  • This post is deleted!


  • @gertjanvanhethof We are experiencing LOS of up to 20km using the standard (20cm) antenna on devices.



  • Thx--I'm not actually getting any errors: from monitoring the logs on the gateway, it seems that the RF packet is not seen/received by the gateway. If it does not approve after the firmware update this week, I plan to set up an RF sniffer and see if I can track down what frequencies are actually being used.


  • Pybytes Beta

    Thxs for your answer.

    I thinking about buying one.
    I talked a guy yesterday and gave me some advice about which antenna to use and which cable.

    But regarding the error you talked about: I connected my LoPy to a TTN gateway successfully but had to slow down the sending with a sleep(2) a bit. Not doing this caused an LoRa error.
    Probably the same you have. So try a sleep(2) between each message.



  • @gertjanvanhethof Our testing of the Multitech Conduit has given range out to about 10km, depending on the intervening geography. We have been using the Multitech mDots for our testing thus far because the LoPy is not transmitting on the right frequencies as best I can tell. We have the Conduit installed on the roof of a four story building with an omnidirectional outdoor antenna. It is moving to another building roof 20 stories up in a few weeks and I expect range to improve.

    We coupled the mDots to GPS receivers and have them beacon their location every 5 seconds--we can then drive around and generate a coverage map. I would like to use the LoPy for this, but the add/remove channel function doesn't seem to quite work (or I am not using it correctly) to get the frequencies set for the correct sub-band. In the US, we have 64 channels and the Multitech will only receive on 8, so the channels need to be configured for sub-band 2. I can get the LoPy to join via OTAA and send data, but only 1 out of 5 to 8 attempts/messages are successful.

    Our gateway forwards to The Things Network. TTN works well and we pick up the transmitted data via MQTT and stick it in a database. (And, in the case of the GPS beacons, use a little PHP to generate a KML file to overlay the data on a Google map).


  • Pybytes Beta

    @arneme Just a question: Did you test the max range of these stations? I thinking about buying one, but I have thoughts about the range it can cover.



  • @kiwi64ajs said in Multitech Conduit:

    @arneme said in Multitech Conduit:

    Upgrading the LoPy to the latest version (0.9.7.b1) and getting the order of the parameters right in the auth part of lora.join() call fixed the problem (yes, the order of the parameters actually changed between versions). The LoPy is now again working towards our Multitech stations :-)

    Ok, so what was the order previously and what order did you have to make it to work now?

    For new revisions of the firmware just follow this (scroll down for the OTAA part):
    https://docs.pycom.io/pycom_esp32/library/network.LORA.html?highlight=lora

    As you can see there the DevKey is now implicitly set to the MAC of the device and the order of the remaining parameters in the authorisation part of parameters in join is: AppEUI, AppKey

    The join used to take three parameters in the authorisation part and the order used to be: AppKey, AppEUI, DevEUI



  • @arneme said in Multitech Conduit:

    Upgrading the LoPy to the latest version (0.9.7.b1) and getting the order of the parameters right in the auth part of lora.join() call fixed the problem (yes, the order of the parameters actually changed between versions). The LoPy is now again working towards our Multitech stations :-)

    Ok, so what was the order previously and what order did you have to make it to work now?



  • Upgrading the LoPy to the latest version (0.9.7.b1) and getting the order of the parameters right in the auth part of lora.join() call fixed the problem (yes, the order of the parameters actually changed between versions). The LoPy is now again working towards our Multitech stations :-)



  • @daniel I can provide you with logs, just tell me what you want. I can even allow you to login and install software on the gateway if you want to use your own customised packet forwarder (i.e. to get more verbose log output) or monitoring tool.



  • @arneme Can you provide any logs from the Multitech Gateway? That might help understand the problem.

    We are working this week on fine tuning the timing of the LoRa stack and we are sending our modules for LoRaWAN certification.



  • After upgrading my LoPy to the latest firmware (release='0.9.6.b1', version='v1.8.6-40-gd10463e on 2016-11-25') I am not able to connect to a Multitech gateway (in basic packet forwarder mode) anymore :-(



  • I recently purchased a second LoPy as I previously thought I may have damaged the first one by not immediately attaching the external RF aerial.

    However, I'm still experiencing the same issues on the second LoPy (my LoRaWAN configuration is further down this thread). I still can't connect to the network using OTAA with the Conduit gateway which is pretty frustrating (especially given that other folk seem to have achieved this).



  • I see some folks report that they can connect their LoPy to the Multitech Conduit however I have 0% success on LoPy while I have 100% success on mDot. Are there any absolutely working py scripts with matching conduit configs out there?

    I currently have an identical setup as jubbs and identical results...



  • I took the global_config.json generated by the Network server (when using Daniels original setup of the Network server) and using this file (modified with our network server DNS name) to configure the basic packet forwarder (and setting the Conduit in basic packet forward mode) I actually managed to connect the LoPy. Our network server is now receiving packets from the LoPy after successful join.

    @arneme that's good news. Were you able to understand what part of the config is affecting the behavior of the join procedure?



  • @arneme I took the global_config.json generated by the Network server (when using Daniels original setup of the Network server) and using this file (modified with our network server DNS name) to configure the basic packet forwarder (and setting the Conduit in basic packet forward mode) I actually managed to connect the LoPy. Our network server is now receiving packets from the LoPy after successful join.



  • @daniel Note that you will need a Network server running somewhere. We are using the Semtech Network server but you will have to contact them directly in order to get the binaries or source code for it. It might however be possible to set up a second Multitech station and run the network server there but we have not tested this configuration. Another option is to use the Loriot.io packet forwarder and set up an account with them (we have tested this with the same result as for our own setup). If you want we could set you up to use our network server as well.



  • @arneme thanks for the config. I will test with that and with the Conduit as a simple packet forwarder and see where that gets me.

    Cheers,
    Daniel



  • @daniel When I use your configuration it works. The thing is that our setup is very different since we have set up the Conduit in basic packet forwarder mode. We are running a single cloud based network server for our entire network of 15 gateways in three different geographical locations (three cities in Norway). The configuration for the packet forwarder is like this (Gateway ID and URL to our network server is anonymised with x and y´s):

    {
    	"SX1301_conf": {
            "lorawan_public": true,
    		"radio_0": {
    			"enable": true,
    			"freq": 867500000
    		},
    		"radio_1": {
    			"enable": true,
    			"freq": 868500000
    		},
    		"chan_multiSF_0": {
    			"enable": true,
    			"radio": 1,
    			"if": -400000
    		},
    		"chan_multiSF_1": {
    			"enable": true,
    			"radio": 1,
    			"if": -200000
    		},
    		"chan_multiSF_2": {
    			"enable": true,
    			"radio": 1,
    			"if": 0
    		},
    		"chan_multiSF_3": {
    			"enable": true,
    			"radio": 0,
    			"if": -400000
    		},
    		"chan_multiSF_4": {
    			"enable": true,
    			"radio": 0,
    			"if": -200000
    		},
    		"chan_multiSF_5": {
    			"enable": true,
    			"radio": 0,
    			"if": 0
    		},
    		"chan_multiSF_6": {
    			"enable": true,
    			"radio": 0,
    			"if": 200000
    		},
    		"chan_multiSF_7": {
    			"enable": true,
    			"radio": 0,
    			"if": 400000
    		},
    		"chan_Lora_std": {
    			"enable": true,
    			"radio": 1,
    			"if": -200000,
    			"bandwidth": 250000,
    			"spread_factor": 7
    		},
    		"chan_FSK": {
    			"enable": true,
    			"radio": 1,
    			"if": 300000,
    			"datarate": 50000,
    			"freq_deviation": 25000
    		}
    	},
    	"gateway_conf" : {
    	"gateway_ID": "000800FFFFXXXXX",
        "fake_gps": true,
        "ref_latitude": 69.6816054,
        "ref_longitude": 18.987787,
        "ref_altitude": 16,
    	"server_address" : "xxxxxx.yyyyy.com",
    	"serv_port_up": 1700,
    	"serv_port_down": 1700,
    	"keepalive_interval": 10,
    	"stat_interval": 30,
    	"push_timeout_ms": 100,
    	"forward_crc_valid": true,
    	"forward_crc_error": false,
    	"forward_crc_disabled": false	
      }
    }
    

Log in to reply
 

Pycom on Twitter