Multitech Conduit

stuart

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.

daniel

@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

arneme

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

daniel

@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

arneme

@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

@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

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?

egnoske

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

stuart

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

arneme

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

daniel

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

arneme

@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

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

kiwi64ajs

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

arneme

@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

gertjanvanhethof

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

cmsedore

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

gertjanvanhethof

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.

cmsedore

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.

arneme

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

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

Multitech Conduit

Pycom on Twitter