Setting up Multitech Conduit Gateway for TTN

markstanley · March 10, 2016, 11:17pm

Hi @bickster, You are welcome to try https://drive.google.com/open?id=0BySpTvoKcPfRenNnWW9naU1Cck0 - credit for all the useful connectivity bits goes to Andrew @thinginnovations , I just adapted his program to work with a very simple light sensor. This programme works very reliably for one of my mDots. Just remember to change the device ID to one of your own!

Do you get any errors from the poly packet forwarder or when you run /etc/init.d/lora-network-server start ?

bickster · March 12, 2016, 4:09am

I’m able to join the network now and send data using AT commands, but the packet forward log doesn’t log any of the data I’m sending. I’ve also check the nodes web service and noting is showing up there either, but my gateway is active and is send data according to the gateway web service. I just keep seeing this in the log file. Not sure what I’m missing…

##### 2016-03-12 04:09: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 (192 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: 1457755778 sec)
# no valid GPS coordinates available yet
##### END #####
INFO: [down] for server 54.72.145.119 PULL_ACK received in 123 ms
INFO: [down] for server 54.72.145.119 PULL_ACK received in 124 ms
INFO: [down] for server 54.72.145.119 PULL_ACK received in 126 ms

##### 2016-03-12 04:10: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 (192 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: 1457755808 sec)
# no valid GPS coordinates available yet
##### END #####
INFO: [down] for server 54.72.145.119 PULL_ACK received in 124 ms
INFO: [down] for server 54.72.145.119 PULL_ACK received in 122 ms
INFO: [down] for server 54.72.145.119 PULL_ACK received in 127 ms

Lespagnol · June 2, 2016, 9:31am

Hi everybody,

Can someone explain me something about the global_conf.json ?
Why we need to set radio0 and radio1 ? There is only one SX1301 so only one radio chip capable of 8 channels.
And for the 915MHz gateway i have the same question?

Can someone explain me in detail the lines in the global_conf.json ?

Thank you for your support

kersing · June 2, 2016, 10:23pm

There are two SX1257s, both need to be enabled and set to a certain centre frequency. Next for each frequency we want to use the radio and the frequency offset need to be specified.

Any specific configuration lines you want explained? (See TTN github repo for configurations with comments added)

Lespagnol · June 3, 2016, 7:27am

Hi Kersing,

Tkx for your answer.
The thing I don’t understand is (for exemple) how to configure the channels for USA 915?
In theory we have 63 channels but the SX1301 can only demodulate 8channels so is that means that I only need to add 8 channels in the global_conf ? Or I can add more to avoid collision ?
The last thing is about the tx_lut ? what does it means ?

Thanks for everything

nestorayuso · June 3, 2016, 9:03am

For the US 915 band you need a special gateway 64ch with 8x SX1301, Senet has it.

Or you can use a normal 8ch gateway with 1x SX1301 in HYBRID but you have to configure gateways and nodes to use only 1 of the 8 sub-bands.

tx_lut are calibration values not very important, they don’t affect to performance, are just to calibrate RSSI values

Lespagnol · June 8, 2016, 4:05pm

Thank you for the explanation nestorayuso.

Someone has a link to download the new RN2903 firmware ? Both RN2483 and RN2903 (0.9.5) have a huge bug with updating frame counters so I want to put the RN2903 with a new firmware.

If you have a link like the RN2483 I’m waiting for it pleaaaasseee.

Thx

terrence · June 10, 2016, 1:25am

I am not doubting you, but where can I read up on this bug?
Thanks.

Lespagnol · June 10, 2016, 3:35pm

Hi terrence,

When you send a set uplink counter command the module returns OK but when you read back the counter the value has not been updated.

Start module
Send : mac set upctr 12
Receive : ok

But when you send a frame the sequence number is not 12.

This bug has been seen on every rn2483 0.9.5 and rn2903 0.9.5

ajtalsma · June 13, 2016, 3:25pm

@kersing Hi Jac are you going/willing to provide an ipk package for the latest version of the Packet forwarder? would be great to experiment with a private backend.

kersing · June 13, 2016, 4:31pm

@ajtalsma

Sorry, no, I will not be attempting to build the newest software for MultiTech conduits, the reason:

v2.2.0 - 2015-10-08

Removed FTDI support in makefiles to align with HAL v3.2.0.

As the MultiTech gateways are FTDI based it won’t be possible to run the newest versions of the HAL and packet forwarder on them. The new software requires SPI communications to meet timing requirements.

ajtalsma · June 14, 2016, 3:38pm

Ok thanks for the info. Does that mean the Multitech conduit hardware is obsolete with regards to the development of the packet forwarder? In other words, why buy this gateway if it won’t support future functionality/requirements?

diegogutierrez · June 8, 2017, 2:59pm

I’m at the same point, lora-pkt-pwd is running and registering to TTN. But the Lora server did not.

I want to join my mDot. Any suggestions?

diegogutierrez · June 8, 2017, 4:10pm

I am working with MULTITECH’s “MultiConnect Conduit IoT Starter Kit for LoRa Technology”. I have been able to connect to TTN by following the guide: https://www.thethingsnetwork.org/docs/gateways/multitech/aep.html

I have the following queries:

The kit comes with an mDot box node and it has stopped connecting to the Lora signal. It only connects when from mLinux I launch the lora-network-server but this causes my gateway to stop connecting to TTN.

So, when I run ttn-pkt-forwarder does the Lora Radio service launch? When I used the command sh installer.sh will the packet forwader and the server be installed?
MDot box firmware does not support ttn-packet-forwarder? I just want the mdot to detect the radio signal.

bickster1 · June 8, 2017, 4:27pm

I haven’t used my gateway in awhile. Sorry.

kersing · June 8, 2017, 7:12pm

Have you configured the mDot to use the TTN keys and frequencies?

The ttn-pkt-forwarders interfaces between the conduit radio and the network forwarding all valid LoRaWAN packets to TTN. No additional software in the conduit is required.

diegogutierrez · June 8, 2017, 8:29pm

I’ll be working on it, thank you so much.
Let’s Keep in touch.

davidhrbaty · December 20, 2017, 10:50am

Hello,
I have problem with Multitech gateway. I’m using ttn-pkt-forwarder with 2 uplink servers. One is for our private purposes, connected via semtech protocol. Second is for ttn network. Uplink messages is fully functional to both servers. Problem is with downlink messages. These messages are not sent to nodes. Messages have arrived to gateway, but ther are not sent to nodes.
There is a log from gateay:

lgw_receive:1165: FIFO content: 1 10 0 5 13
lgw_receive:1184: [2 17]
Note: LoRa packet
Info: packet will be sent without CRC
INFO: Enabling TX notch filter
59.20.0.0.9b.ee.8f.9.0.1c.c.1c.0.8.0.0.60.11.1b.1.26.20.5e.1.87.84.5e.74.end
lgw_receive:1165: FIFO content: 1 33 0 5 13
lgw_receive:1184: [1 17]
Note: LoRa packet
Info: packet will be sent without CRC
INFO: Enabling TX notch filter
59.13.33.0.f7.77.47.9.0.1c.c.1c.0.8.0.0.60.11.1b.1.26.20.5f.1.b6.c9.c6.af.end

When I used default lora-packet-forwarder, downlink messages are fully functional, but there is a limitation to one network server, so I cannot expand my gateway to ttn network. Can you tell me, where can be a problem?

Thank you.

kersing · December 20, 2017, 12:30pm

The log you are showing does not contain any downlink message, just uplink. Is the gateway receiving downlink data?

davidhrbaty · December 20, 2017, 12:59pm

Hello, yes, gateway is receiving downlink data. There is more info from log:

lgw_receive:1165: FIFO content: 1 eb 3 5 19
lgw_receive:1184: [5 17]
Note: LoRa packet
lgw_receive:1165: FIFO content: 1 14 0 7 14
lgw_receive:1184: [2 17]
Note: LoRa packet
lgw_receive:1165: FIFO content: 1 38 0 7 13
lgw_receive:1184: [0 17]
Note: LoRa packet
lgw_receive:1165: FIFO content: 1 5b 0 7 16
lgw_receive:1184: [2 17]
Note: LoRa packet
lgw_receive:1165: FIFO content: 1 81 0 5 19
lgw_receive:1184: [4 17]
Note: LoRa packet
lgw_receive:1165: FIFO content: 1 aa 0 5 13
lgw_receive:1184: [0 17]
Note: LoRa packet
Info: packet will be sent without CRC
INFO: Enabling TX notch filter
59.6.66.6.f2.c1.87.9.0.1c.c.1c.0.8.0.0.60.11.1b.1.26.20.66.1.f6.ca.b8.81.end
lgw_receive:1165: FIFO content: 1 cd 0 5 13
lgw_receive:1184: [1 17]
Note: LoRa packet

##### 2017-12-20 12:54:52 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 10
# CRC_OK: 80.00%, CRC_FAIL: 20.00%, NO_CRC: 0.00%
# RF packets forwarded: 8 (201 bytes)
# PUSH_DATA datagrams sent: 9 (2129 bytes)
# PUSH_DATA acknowledged: 100.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
### BEACON IS DISABLED! 
### [JIT] ###
# INFO: JIT queue contains 0 packets.
# INFO: JIT queue contains 0 beacons.
### GPS IS DISABLED! 
### [PERFORMANCE] ###
# Upstream radio packet quality: 80.00%.
# Upstream datagram acknowledgment quality for server "home.jump-soft.com" is 100.00%.
# Downstream heart beat acknowledgment quality for server "home.jump-soft.com" is 100.00%.
# Downstream datagram content quality for server "home.jump-soft.com" is 0.00%.
# Downstream radio transmission quality for server "home.jump-soft.com" is 100.00%.
# Semtech status report send. 
##### END #####

##### 2017-12-20 12:55:22 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 5
# CRC_OK: 80.00%, CRC_FAIL: 20.00%, NO_CRC: 0.00%
# RF packets forwarded: 4 (96 bytes)
# PUSH_DATA datagrams sent: 5 (1165 bytes)
# PUSH_DATA acknowledged: 100.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
### BEACON IS DISABLED! 
### [JIT] ###
# INFO: JIT queue contains 0 packets.
# INFO: JIT queue contains 0 beacons.
### GPS IS DISABLED! 
### [PERFORMANCE] ###
# Upstream radio packet quality: 80.00%.
# Upstream datagram acknowledgment quality for server "home.jump-soft.com" is 100.00%.
# Downstream heart beat acknowledgment quality for server "home.jump-soft.com" is 100.00%.
# Downstream datagram content quality for server "home.jump-soft.com" is 0.00%.
# Downstream radio transmission quality for server "home.jump-soft.com" is 100.00%.
# Semtech status report send. 
##### END #####
INFO: tx_start_delay=1493 (1493.562500) - (1497, bw_delay=1.500000, notch_delay=1.937500)
13:55:52  INFO: Disabling GPS mode for concentrator's counter...
13:55:52  INFO: host/sx1301 time offset=(1513774429s:741029µs) - drift=-28µs
13:55:52  INFO: Enabling GPS mode for concentrator's counter.

Info: packet will be sent without CRC
INFO: Enabling TX notch filter
59.13.33.7.4e.50.5f.9.0.1c.c.1c.0.8.0.0.60.11.1b.1.26.20.67.1.4.67.e0.8a.end
lgw_receive:1165: FIFO content: 1 f0 0 5 13
lgw_receive:1184: [0 17]
Note: LoRa packet

And there is a tcpdump communication:

root@mtcdt:~# tcpdump -i any port 1700i
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes



13:53:52.171425 IP 10.202.3.10.52582 > lora_server1700: UDP, length 12
13:53:52.174004 IP lora_server1700 > 10.202.3.10.52582: UDP, length 4
13:53:56.763379 IP 10.202.3.10.50524 > lora_server1700: UDP, length 230
13:53:56.766245 IP lora_server1700 > 10.202.3.10.50524: UDP, length 4
13:53:57.079007 IP lora_server1700 > 10.202.3.10.52582: UDP, length 168
13:53:57.080646 IP 10.202.3.10.52582 > lora_server1700: UDP, length 12
13:54:02.271861 IP 10.202.3.10.52582 > lora_server1700: UDP, length 12
13:54:02.274458 IP lora_server1700 > 10.202.3.10.52582: UDP, length 4
13:54:03.759242 IP 10.202.3.10.50524 > lora_server1700: UDP, length 231
13:54:03.761959 IP lora_server1700 > 10.202.3.10.50524: UDP, length 4
13:54:04.075545 IP lora_server1700 > 10.202.3.10.52582: UDP, length 169
13:54:04.076596 IP 10.202.3.10.52582 > lora_server1700: UDP, length 12
13:54:08.760092 IP 10.202.3.10.50524 > lora_server1700: UDP, length 231
13:54:08.762751 IP lora_server1700 > 10.202.3.10.50524: UDP, length 4
13:54:09.074455 IP lora_server1700 > 10.202.3.10.52582: UDP, length 169
13:54:09.075512 IP 10.202.3.10.52582 > lora_server1700: UDP, length 12

Thank you.