Setting up Multitech Conduit Gateway for TTN

markstanley · November 24, 2015, 11:18am

Thanks @kersing
I downloaded https://github.com/kersing/packet_forwarder/blob/master/poly_pkt_fwd/global_conf_multitech-eu868.json and used that as the basis for my global_conf.json.

You are right, there is a LOT more in here!

So my gateway is working again, this time using poly_pkt_fwd. Many thanks.

I can update the wiki to use poly_pkt_fwd instead. Gps_pkt_fwd worked fine for me but if I understand the various bits in the forum correctly, the gps_pkt_fwd is not reliable, whereas poly_pkt_fwd is more reliable. Is this correct?

kersing · November 24, 2015, 8:16pm

While setting up the gateway I noticed the number of packets received successfully decreased over time when running gps_pkt_fwd. The number was constant while running basic_pkt_fwd. See the this thread for details on the subject. Feel free to verify my findings or even better disprove them.

As I wanted status updates for TTN I decided to compile poly_pkt_fwd. It has the added advantage of being able to connect to both TTN and iot.semtech.com, allowing to (successfully) test OTAA and sending packets to the node as well. (It would also allow connecting to the stack running on the MultiTech, however as I haven’t found sufficient documentation on how to use it I’ve disabled the connection to localhost for now.)

markstanley · November 25, 2015, 9:31am

Ok, thanks for the explanation. I updated the wiki page yesterday to use poly_pkt_fwd, and I’ll keep an eye on reliability on my conduit.

Many thanks again for your help.

robbo · January 5, 2016, 5:19pm

@kersing Thank you for writing the updated poly_pkt_fwd!

I am in the process of trying to get it to work without any luck so far. Before I start again from scratch I thought I would ask for help. My configuration is as follows:

I have installed your poly-packet-forwarder_2.1-r1_arm926ejste.ipk
I have updated my /var/config/lora/global_conf.json based on your https://github.com/kersing/packet_forwarder/blob/master/poly_pkt_fwd/global_conf_multitech-us915.json
I have edited /etc/init.d/lora-network-server to run poly_pkt_fwd

My log file shows the following:

root@mathworks1:~# /etc/init.d/lora-network-server restart
Stopping lora-network-server: OK
Found lora card MTAC-LORA-915
Starting lora-network-server: OK
root@mathworks1:~# tail -f /var/log/lora-pkt-fwd.log
INFO: Beacon is disabled
INFO: Monitor is disabled
INFO: Platform configured to "MultiTech"
INFO: Contact email configured to "my@email.com"
INFO: Description configured to "MathWorks01"
INFO: Successfully contacted server 54.229.214.112
INFO: [main] Starting the concentrator
INFO: [main] concentrator started, radio packets can now be received.
INFO: [down] Thread activated for all server 54.229.214.112
INFO: [up] Thread activated for all servers.

    ##### 2016-01-05 16:34:09 GMT #####
    ### [UPSTREAM] ###
    # RF packets received by concentrator: 0
    # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
    # RF packets forwarded: 0 (0 bytes)
    # PUSH_DATA datagrams sent: 0 (0 bytes)
    # PUSH_DATA acknowledged: 0.00%
    ### [DOWNSTREAM] ###
    # PULL_DATA sent: 3 (0.00% acknowledged)
    # PULL_RESP(onse) datagrams received: 0 (0 bytes)
    # RF packets sent to concentrator: 0 (0 bytes)
    # TX errors: 0
    ### [GPS] ###
    # Invalid gps time reference (age: 1452011649 sec)
    # Manual GPS coordinates: latitude 42.29956, longitude -71.35191, altitude 20 m
    ##### END #####

Here are my issues:

I do not see my gateway at: http://thethingsnetwork.org/api/v0/gateways/
I can no longer send messages to the api: http://thethingsnetwork.org/api/v0/nodes/02013E00/

I am receiving CRC errors now:

 ##### 2016-01-05 17:12:09 GMT #####
 ### [UPSTREAM] ###
 # RF packets received by concentrator: 1
 # CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
 # RF packets forwarded: 0 (0 bytes)
 # PUSH_DATA datagrams sent: 1 (221 bytes)
 # PUSH_DATA acknowledged: 0.00%
 ### [DOWNSTREAM] ###
 # PULL_DATA sent: 3 (0.00% acknowledged)
 # PULL_RESP(onse) datagrams received: 0 (0 bytes)
 # RF packets sent to concentrator: 0 (0 bytes)
 # TX errors: 0
 ### [GPS] ###
 # Invalid gps time reference (age: 1452013929 sec)
 # Manual GPS coordinates: latitude 42.29956, longitude -71.35191, altitude 20 m
 ##### END #####

and even when I appear to receive valid messages:

##### 2016-01-05 17:18:10 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 1
# CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 1 (30 bytes)
# PUSH_DATA datagrams sent: 2 (473 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
### [GPS] ###
# Invalid gps time reference (age: 1452014290 sec)
# Manual GPS coordinates: latitude 42.29956, longitude -71.35191, altitude 20 m
##### END #####

They do not end up at the api.

Any help would be much appreciated.

Batilan · January 5, 2016, 5:46pm

Hi @robbo,

It seems you are using an old IP address, please use 54.72.145.119 instead. See also this discussion. And it would be nice if @kersing can adjust the configuration on Github

robbo · January 5, 2016, 6:17pm

@Batilan Thanks! That fixed my problem. Now if I had only asked a day ago I would have more hair

There is one oddity though. My messages are getting through perfectly but my CRC is seldom 100% - i.e.

Message gets through:

{
    "data_raw": "QAA+AQIADgABSHuBh0kALLWLNXtzI6XoxGs9ENXEgswSO7pdw7vC",
    "gateway_eui": "0080000000009CB4",
    "node_eui": "02013E00",
    "frequency": 912.3,
    "data_plain": "Hello number 3 from Natick",
    "time": "2016-01-05T18:12:49.685Z",
    "rssi": -93,
    "snr": -6.2,
    "datarate": "SF9BW125",
    "data": "SGVsbG8gbnVtYmVyIDMgZnJvbSBOYXRpY2s="
},

and I get the following in the log.

 ##### 2016-01-05 18:13:38 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 3
# CRC_OK: 33.33%, CRC_FAIL: 66.67%, NO_CRC: 0.00%
# RF packets forwarded: 1 (39 bytes)
# PUSH_DATA datagrams sent: 2 (484 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
### [GPS] ###
# Invalid gps time reference (age: 1452017618 sec)
# Manual GPS coordinates: latitude 42.29956, longitude -71.35191, altitude 20 m
##### END #####

I also get a log update every 30 seconds now:

##### 2016-01-05 18:17:38 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (221 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
### [GPS] ###
# Invalid gps time reference (age: 1452017858 sec)
# Manual GPS coordinates: latitude 42.29956, longitude -71.35191, altitude 20 m
##### END #####
INFO: [down] for server 54.72.145.119 PULL_ACK received in 105 ms
INFO: [down] for server 54.72.145.119 PULL_ACK received in 105 ms
INFO: [down] for server 54.72.145.119 PULL_ACK received in 105 ms
##### 2016-01-05 18:17:08 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (221 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
### [GPS] ###
# Invalid gps time reference (age: 1452017828 sec)
# Manual GPS coordinates: latitude 42.29956, longitude -71.35191, altitude 20 m
##### END #####
INFO: [down] for server 54.72.145.119 PULL_ACK received in 105 ms
INFO: [down] for server 54.72.145.119 PULL_ACK received in 105 ms
INFO: [down] for server 54.72.145.119 PULL_ACK received in 105 ms

Batilan · January 5, 2016, 6:45pm

Haha, yes now I see what it did to you

Glad to have helped to get the first TTN gateway in the whole of North America online The TTN maps http://ttn.lpwan.uk/ and http://www.ttnmap.org/ are looking much better now

I’m not sure about the CRC errors, but saw the same effect in this discussion before. Maybe it is the node you are using. If the rate is always 33/67 the node software is probably the cause I guess.

robbo · January 5, 2016, 7:55pm

Thanks. The rate jumps around. When using the basic forwarder I got 100% with the same mDot node. Odd. Thanks again for your help

kersing · January 5, 2016, 8:31pm

Are all packets transmitted by your node received and forwarded? The settings are different so you might be picking up more noise.
With EU settings I’m picking up rather a lot of noise, with no nodes transmitting I’ll see at least one CRC error every status interval, however it has no negative impact on packet reception as every packet I know to have been transmitted is forwarded to TTN.

robbo · January 6, 2016, 2:02pm

@kersing re: Are all packets transmitted by your node received and forwarded? I believe so as I am using the following settings:

    "forward_crc_valid": true,
    "forward_crc_error": false,
    "forward_crc_disabled": true,

It may be noise since I do get 100% CRC too:

##### 2016-01-06 14:03:10 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 1
# CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 1 (37 bytes)
# PUSH_DATA datagrams sent: 2 (485 bytes)
# PUSH_DATA acknowledged: 0.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
### [GPS] ###
# Invalid gps time reference (age: 1452088990 sec)
# Manual GPS coordinates: latitude 42.29956, longitude -71.35191, altitude 20 m
##### END #####

kersing · January 14, 2016, 11:58pm

I have just uploaded a new installation package to github. This package contains the adapted frequencies for TTN in 868 region, the gateway specific parameters have been moved to the local_conf.json file (where they should have been from the start) and the IP address for TTN has been updated.

For those updating from the previous package:

Download the new package from github
Transfer it to the MultiTech gateway.
run opkg install poly-packet-forwarder_2.1-r2_arm926ejste.ipk, sample output:
Upgrading poly-packet-forwarder on root from 2.1-r1 to 2.1-r2…
Removing obsolete file /var/config/lora/global_conf.json.sample.
Configuring poly-packet-forwarder.
YOU NEED TO CONFIGURE YOUR GATEWAY BY EDITTING
/var/config/lora/local_conf.json
Collected errors:
- file_md5sum_alloc: Failed to open file /var/config/lora/local_conf.json: No such file or directory.
- resolve_conffiles: Existing conffile /var/config/lora/global_conf.json is different from the conffile in the new package. The new conffile will be placed at /var/config/lora/global_conf.json-opkg.
Go to /var/config/lora
Move old config: mv global_conf.json global_conf.old
Rename new config mv global_conf.json-opkg global_conf.json
Edit local_conf.json, data can be found in a copy of the old config called global_conf.json.save

The wiki page has been adapted for the new installer.

wojciech · January 20, 2016, 1:56am

another 915MHz Multitech box online (Canada).
Its mLinux converted to AEP and then with poly packet forwarder for better usability
Great job Gents
Wojtek

markstanley · January 22, 2016, 5:05pm

Hi @kersing - I’ve just set up the new poly on a new conduit. I get the following error in var/log/lora-pkt-fwd:

ERROR: [main] failed to find any configuration file named /var/config/lora/1/global_conf.json, /var/config/lora/1/local_conf.json OR /var/config/lora/1/debug_conf.json

Any ideas?

kersing · January 22, 2016, 5:42pm

@markstanley Looks like there is an additional ‘/1’ at the end of your conf_dir variable. Do you have two cards in the gateway? If not, try removing the ‘/1’.

markstanley · January 22, 2016, 6:06pm

Whoops! How embarrassing - sorry for wasting your time and thanks (again) for your help Have a great weekend!

wojciech · February 5, 2016, 10:34am

Just want to confirm that the same configuration works with 1.1.2 version of AES Conduit. After the update, you will however need to reinstall poly-packet-forwarder and modify your startup file the same way.
Cheers
Wojtek

fredz · February 18, 2016, 3:48pm

I am at a loss here - I followed the instructions as per http://thethingsnetwork.org/wiki/Installing-your-Multitech-mLinux-Conduit .
What I now get is this:

root@mtcdt:/etc# /etc/init.d/lora-network-server restart
Stopping lora-network-server: OK
Found lora card MTAC-LORA-868
Starting lora-network-server: /etc/init.d/lora-network-server: line 62: start: command not found
OK

The odd thing is, the system works just fine and the gateway shows up at http://thethingsnetwork.org/api/v0/gateways/
The log also shows no errors.

These are the relevant contents of lora-network-server

  echo -n "Starting $NAME: "
    mkdir -p $run_dir
    # start network server
    #start-stop-daemon --start --background --make-pidfile \
    #    --pidfile $net_server_pidfile --exec $net_server -- \
    #    -c $conf_file --lora-eui $lora_eui --lora-path $run_dir --db $conf_db \
    #    --noconsole -l $net_server_log
    #sleep 2
    start packet forwarder
    start-stop-daemon --start --background --make-pidfile \
        --pidfile $pkt_fwd_pidfile --exec $pkt_fwd -- \
        -c $conf_dir -l $pkt_fwd_log
    echo "OK"

I replaced $conf_dir/1 by $conf_dir as well, maybe somewhere I have to add the /1 back in the file?

markstanley · February 18, 2016, 4:25pm

I think you may have uncommented the comment!

it should read:

#start packet forwarder
start-stop-daemon --start --background etc…

fredz · February 18, 2016, 4:31pm

Anyone know what range a Multitech will have in real life? I have set it at 5 km on the community page, but it seems quite a lot to me…

Why is there a micro USB connector on the mDot Developer kit? Is this just for power or can one use it instead of the serial connection.
And also, how do you guys power the mDot developer kit? Using USB or the power jack?

markstanley · February 18, 2016, 5:44pm

I use the micro usb and the serial connection to the dev board, can’t remember why! Oh I think one is for programming it and one is for the console.
We have 4 Multitech gateways in Reading and get typical range of 1-1.5km in built up areas. My gateway can be reached by a guy who is 4km away on another hill - we’ve not quite got line of site but close enough!