Setting up Multitech Conduit Gateway for TTN

Gateways MultiTech Gateways
41

Hi @johan at present I wasn’t sure if my gateway was connecting or not. I am using mDot modules and as there doesn’t appear to be any previous example of them being used I’m having to work it out myself. At present I’m in the process of debugging a new node that hopefully should work if I actually knew the gateway was connected!

I tried the gateways API call with my gateway UID but it returns empty response.

Not had much time to look at this over the previous few days either, which doesnt help.

Thanks
Andrew

42

Andrew,

Brandon here from MultiTech. Yes, you can use the mDot with TTN. When I had the call with @johan, I was using an mDot (with AT Command Firwmare) to send data to TTN. To configure the mDot, follow the instructions on the page @johan linked to. The only unique configuration peice for TTN is the network and data session keys for which you need to use the default key on this page. But in fact the mDot’s default session keys are the same as TTN, so you’ll just need to confirm they match.

Then you can tail the packet forwarder log and see when lora packets are received. You won’t see the data, but you’ll see that a lora packet has been received.

-Brandon

4 Likes
43

Hey Brandon,

We meet again!! Thanks for helping out with my Conduit MTAC-Lora card replacement.

I’ve been looking at the packet forwarder logs and see that it isnt forwarding CRC errors so my mDot isnt yet setup correctly, but it almost there!

Thanks again

Andrew

44

Hi Brandon @brandon-multitech,
We’re using the AEP version. We want to enable local people to use NodeRED to set up devices. Johan has answered part of this question. Just want to get your take on it too — If we’re going to use NodeRED on the Local side before packets are sent to TTN, should we just tap in to TTN with MQTT. Or, is there another NodeRED enabled option planned! Thanks for all your help!
Patrick

45

Patrick,

Yes, as @johan has mentioned, you’ll either want to by-pass the Conduit Node-RED and use the TTN cloud network server, or use the Conduit’s local network server with Node-RED sending data to TTN application handler’s via MQTT.

-Brandon

46

TTN is a public network, instead of Conduit+NodeRed that is a private network (i think).

@thinginnovations you should configure mDot to use a public network. Use this: AT+PN 1

47

Hi @nestorayuso
Yes, public is what I’m using but I don’t use the AT commands, I go all the way and program the mDot using the mbed IDE.

Thanks

Andrew

48

Does anything need to be setup on TTN side to accept my gateway communications? I dont yet see anything when I query the gateways API, either for all gateways or for my specific ID.

Using tcpdump on the Conduit, I can see traffic including the json being sent from the packet forwarder and responses coming back. I’m actually using the gps_pkt_fwd with the fake_gps settings in order to send regular status updates that are missing from the basic_pkt_fwd application.

I can see UDP packets with my gateway ID in but have not yet got as far as looking at the packet forwarder and gateway code to determine the format of the packets.

Thanks

Andrew

49

Hi,

It looks like I’m actually sending something and it gets through if I allow Lora packets with invalid CRC to be forwarded. I also see the node ID isnt set correctly so something else to work on. But I do now see this in the nodes output:

    {
    "time": "2015-10-19T22:08:43.342397Z",
    "gateway_eui": "0080000000009D62",
    "data_raw": "gAAAAAAAAQABbiCwdCcnnPr/o+F+nNVFoA==",
    "node_eui": "00000000",
    "data": "eyJ0bXAiOjIxLjB9",
    "data_plain": "{\"tmp\":21.0}",
    "data_json": {
        "tmp": 21.0
    }
},

This is using a MultiTech mDot, the Conduit AEP with GPS packet forwarder setup with fake GPS details. Once the mDot is working correctly then I can release some example code.

Thanks

Andrew

50

Any updates here @thinginnovations?

I’m also seeing CRC errors, both in nodeRed and mLinux

51

@Ropu if you’re able to get that page on the Conduit AEP then you’re running a local server and not connecting to TTN. On my Conduit AEP, the network server and packet forwarder have been disabled. I did see high CRC error counts on my Conduit when I was using it in private mode.

Its currently re-configured back to private mode for some testing so I now see this page.

Andrew

52

Hi All,
I`m in Sao Paulo-Brazil with @flavio and we have a RasPI working but our gateway is not in the TTN Status. How can I debug this comunication?

Regards,
Viola

53

@Ropu & @thinginnovations, a high number of CRC errors only means you have a lot radio interference. This cyclic redundancy check is used to verify message integrity.

-Brandon

1 Like
54

Thanks @brandon-multitech I’m borrowing some test gear to check this out. In private mode, there seems to be a lot less of them too.

thanks

Andrew

1 Like
55

Weird @brandon-multitech , the nodes are 3 feet away…

thoughts?

56

Could be too close and the signal is swamping the receiver?
Try a few metres away.

57

Hint: the “gateway_conf” with a host name in the server_address requires DNS resolving to be set up. The MultiTech setup instructions do not take DNS into account for static IP configuration. To configure DNS, remove the existing ‘/etc/resolv.conf’ (it is a link) and create a file with a valid nameserver:
nameserver 8.8.8.8

Edit: after gateway restart resolv.conf has been reset to an empty file. Using an IP address in the server_address field might be easier right now.

58

We have a Conduit with mLinux that sends the package to the server (it seems), but we don’t get any ACKs. We also don’t see any packets through the API web interface or InfluxDB.

We have also installed an instance of the server (croft, jolly, server) and don’t seem to get any packets there either.

LOG from the gateway:

The config is as follows (with our gateway EUI):

“gateway_conf” :
{
“forward_crc_disabled” : true,
“forward_crc_error” : false,
“forward_crc_valid” : true,
“gateway_ID” : “our EUI”,
“keepalive_interval” : 12,
“push_timeout_ms” : 120,
“serv_port_down” : 1700,
“serv_port_up” : 1700,
“server_address” : “croft.thethings.girovito.nl”,
“stat_interval” : 20,
“synch_word” : 52
}

Any ideas?

2 Likes
59

Are you using DHCP? If not mLinux will probably not have valid name resolving in place. I had to use the IP address for the server in the configuration. (I’m using fixed IP and resolv.conf gets reset to an empty file at boot)

Try running ‘tcpdump -i eth0 -n -vvvX host 54.229.214.112’ to see if there is any traffic.

3 Likes
60

@Kersing Thanks for your prompt response.
I am using static IP and fixed your DNS issue as per your previous suggestion. In any event , I have tried with the url and the ip. I did the tcpdump as per your suggestion and it seems that i do get a response from the server (see below), however it does not show on the % of ACK on the log or on the InfluxDB.