Hi @Lieutier,
Last night there were some big changes pushed to production, and that’s very likely the cause for some of your issues. InfluxDB was replaced with MongoDB as store and all services were restarted (I noticed that the packet forwarder in my gateway stopped being able to connect to Croft, so I had to restart that as well).
Could you try again and let us know?
cheers
Hello @gonzalocasas
Still not seeing the ACK on the gateway log or http://thethingsnetwork.org/api/v0/
We do see responses from the server from tcpdump like captured above.
Are we the only ones with this problem?
Hi @Lieutier,
I just tested it and it works here, but our gateway is not the Multitech.
Perhaps you can try to uncomment the debugging output on the packet forwarder source (around line 1726 of the poly_pkt_fwd, a line that looks like this: printf("\nJSON up: %s\n", (char *)(buff_up + 12)); /* DEBUG: display JSON payload */), and then recompile it.
After that you should be able to see both the status updates and the packets received from nodes in the gateway log.
You said you tried with a local instance of croft, would be interesting to see what you get there.
Cheers
Gonzalo
@Lieutier
For comparison below data for successful data push to TTN using MultiTech:
Logfile:
##### 2015-11-15 09:58:26 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 1
# CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 1 (29 bytes)
# PUSH_DATA datagrams sent: 1 (253 bytes)
# PUSH_DATA acknowledged: 100.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 1 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
tcpdump:
11:00:21.627984 IP (tos 0x0, ttl 64, id 18249, offset 0, flags [DF], proto UDP (17), length 280)
172.16.253.1.42404 > 54.229.214.112.1700: [udp sum ok] UDP, length 252
0x0000: 4500 0118 4749 4000 4011 3c24 ac10 fd01 E...GI@.@.<$....
0x0010: 36e5 d670 a5a4 06a4 0104 a17d 0187 7500 6..p.......}..u.
0x0020: 0080 0000 0000 a050 7b22 7278 706b 223a .......P{"rxpk":
0x0030: 5b7b 2274 6d73 7422 3a32 3239 3838 3236 [{"tmst":2298826
0x0040: 3739 362c 2274 696d 6522 3a22 3230 3135 796,"time":"2015
0x0050: 2d31 312d 3135 5431 303a 3030 3a32 312e -11-15T10:00:21.
0x0060: 3632 3735 3137 5a22 2c22 6368 616e 223a 627517Z","chan":
0x0070: 312c 2272 6663 6822 3a30 2c22 6672 6571 1,"rfch":0,"freq
0x0080: 223a 3836 382e 3330 3030 3030 2c22 7374 ":868.300000,"st
0x0090: 6174 223a 312c 226d 6f64 7522 3a22 4c4f at":1,"modu":"LO
0x00a0: 5241 222c 2264 6174 7222 3a22 5346 3131 RA","datr":"SF11
0x00b0: 4257 3132 3522 2c22 636f 6472 223a 2234 BW125","codr":"4
0x00c0: 2f35 222c 226c 736e 7222 3a39 2e30 2c22 /5","lsnr":9.0,"
0x00d0: 7273 7369 223a 2d36 352c 2273 697a 6522 rssi":-65,"size"
0x00e0: 3a32 392c 2264 6174 6122 3a22 5141 4d70 :29,"data":"QAMp
0x00f0: 4151 4941 4167 4142 3932 5a49 3739 6d44 AQIAAgAB92ZI79mD
0x0100: 3931 416f 325a 464e 484b 6743 4458 5a42 91Ao2ZFNHKgCDXZB
0x0110: 334b 593d 227d 5d7d 3KY="}]}
Gateway settings:
"gateway_conf" :
{
"forward_crc_disabled" : true,
"forward_crc_error" : false,
"forward_crc_valid" : true,
"gateway_ID" : "008000000000a050",
"keepalive_interval" : 12,
"push_timeout_ms" : 120,
"serv_port_down" : 1700,
"serv_port_up" : 1700,
"server_address" : "54.229.214.112",
"stat_interval" : 20,
"synch_word" : 52
}
Just to check:
Did you upgrade the packet forwarder to lora-packet-forwarder_1.4.1-r8.16_arm926ejste.ipk as listed in the upgrade instructions?
What is the ping response time to 52.229.214.112?
@gonzalocasas
I think they are using the stock MultiTech binaries. Those are delivered in binary format so enabling debugging is not an option. (Available sources are for an older version of the software)
@gonzalocasas @kersing
Thanks for your support!
My gateway cons is exactly as kernings and I am using the latest firmware as per the instructions on Multitechs’ site. I don’t think 54.229.214.112 is configured to respond pings.
Yes, unfortunately the packet-forwarder is in binary form, cannot make the changes suggested.
I did installed Croft and pointed the gateway to this new server and still not getting the ACK.
The RabbitMQ is not showing any packages:
This is the output of Croft’s log:
@Lieutier the current back-end doesn’t ACK packets from the nodes: confirmed up is being implemented in the next version that will replace croft and jolie. Maybe that helps?
Thanks much for your response. The ACK we are talking about it the one coming from the server to the Gateway. We can now see the packets reaching the server, however we cannot see the ACK on the log of the packet forwarder on the Multitech gateway.
@Lieutier I’ve build poly_packet_forwarder for MultiTech, you could try it to see if it helps.
Download installable package here.
Stop the running forwarder with /etc/init.d/lora-network-server stop
After installing with opkg install, go to /var/config/lora, save your current config, copy global_conf.json.sample to global_conf.json and edit to set the correct values in the gateway_conf section. (At least gateway_ID, server settings will require changing, neater is to set ref_latitude, ref_longitude, ref_altitude, contact_email and description to correct values as well)
Next edit /etc/init.d/lora-network-server and change the line 'pkt_fwd=/opt/lora/basic_pkt_fwd' to 'pkt_fwd=/opt/lora/poly_pkt_fwd'.
Restart using /etc/init.d/lora-network-server start and check the log file for results.
Hm, that ACK should work. I’ve seen them last weekend on MultiTech gateways. Can you send me the log file?
Also, which server are you using? croft.thethings.girovito.nl?
@kersing
Great work…thanks! We are using the 915MHZ device here, any changes to the config file? I have tried it and it seems that the gw is not receive any packets?
According to the sample config file, the poly forwarder sends the data to more than on server (i.e. Semtech and TTN?) and to a different port (1680) instead of 1700. Could you please explain ?
Many thanks!
@Lieutier
Config does require changes for 915Mhz. However I do not have the required frequency table to create a sample config. Could you provide me with the contents of the global_conf.json the original software uses?
The sample config uses local server and Semtech. I’ll update it for TTN.
Semtech has several LoRa servers, one for EU iot.semtech.com one for US us01-iot.semtech.com and one for China that I can’t remember:
Both servers use different ports !!! Check it here:
http://iot.semtech.com/resources/SiteHelp/
http://us01-iot.semtech.com/resources/SiteHelp/
Hi Lieutier. I have just gotten the multitech mLinux to send to TNN from Boston. My log looks like this for a successful packet:
##### 2015-11-18 20:15:22 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 2
# CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 2 (72 bytes)
# PUSH_DATA datagrams sent: 1 (498 bytes)
# PUSH_DATA acknowledged: 100.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 2 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
##### END #####
Not sure if this helps?
Robbo
@robbo
Could you check /var/run/lora/ to see if there is a file global_conf.json? If so, could you please post the contents (or send it to me privately) If there isn’t a file there could I get a copy of the contents of /var/config/lora/global_conf.json ?
I’m looking for the frequency settings for a 915MHz MultiTech setup.
Here we go:
{
"SX1301_conf" :
{
"chan_FSK" :
{
"bandwidth" : 250000,
"datarate" : 100000,
"enable" : false,
"if" : 100000,
"radio" : 0
},
"chan_Lora_std" :
{
"bandwidth" : 500000,
"enable" : true,
"if" : 400000,
"radio" : 0,
"spread_factor" : 8
},
"chan_multiSF_0" :
{
"enable" : true,
"if" : -300000,
"radio" : 0
},
"chan_multiSF_1" :
{
"enable" : true,
"if" : -100000,
"radio" : 0
},
"chan_multiSF_2" :
{
"enable" : true,
"if" : 100000,
"radio" : 0
},
"chan_multiSF_3" :
{
"enable" : true,
"if" : 300000,
"radio" : 0
},
"chan_multiSF_4" :
{
"enable" : true,
"if" : -300000,
"radio" : 1
},
"chan_multiSF_5" :
{
"enable" : true,
"if" : -100000,
"radio" : 1
},
"chan_multiSF_6" :
{
"enable" : true,
"if" : 100000,
"radio" : 1
},
"chan_multiSF_7" :
{
"enable" : true,
"if" : 300000,
"radio" : 1
},
"radio_0" :
{
"enable" : true,
"freq" : 912200000
},
"radio_1" :
{
"enable" : true,
"freq" : 913000000
}
},
"gateway_conf" :
{
"forward_crc_disabled" : true,
"forward_crc_error" : false,
"forward_crc_valid" : true,
"gateway_ID" : "my_ID",
"keepalive_interval" : 12,
"push_timeout_ms" : 120,
"serv_port_down" : 1700,
"serv_port_up" : 1700,
"server_address" : "54.229.214.112",
"stat_interval" : 20,
"synch_word" : 52
}
}@Lieutier
Please download a new sample configuration for US 915Mhz frequencies from GitHub. Do not forget to set the correct gateway_id , position information (red_latitude etc) and contact information before use.
@Robbo thanks for sharing your results. My config is the same as yours , my results are the same as yours only that PUSH_DATA acknowledged is always 0.00%.
@Kersing - Used your poly_forward binary and got the seam results, packets forwarded but ACK = 0%
Not sure why on the downstream i got 50% ack.
Thanks again for your support!
YEs I am using croft.thethings.girovito.nl, tried with ip address as well.
Log files is the same as the ones I’ve seen around:
…
“gateway_conf” :
{
“forward_crc_disabled” : true,
“forward_crc_error” : false,
“forward_crc_valid” : true,
“gateway_ID” : “my_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
}
Thought my personal step by step directions to get this set up might be useful to others.
These instructions are designed to enable a non-expert to set up the MultiTech MultiConnect Conduit mLinux LoRaWAN gateway and Multitech Mdot LoRaWAN node to forward packets to The Things Network (TTN).
The instructions are a collation of the MultiTech documentation as well as information from TTN forum and Wiki.
Setting up the MultiConnect conduit mLinux requires a little understanding of Linux, basic networking, and using Terminal tools to access the Conduit. I downloaded and installed TeraTerm to SSH into the Conduit and WinSCP to copy over firmware updates. WinSCP is also useful to use as a general File Explorer for those of us who do not love the command line.
The first step is to install and connect the Lora radio hardware as described here. My Conduit model is a MTCDT-210L-US-EU-GB and does not include cellular connectivity.
As I was setting this up on a company network I needed to work with IT to get the Connect on the network with Ports 1700 opened for UDP traffic. For security reasons IT was not comfortable with putting me on the main network or even in the DMZ. Fortunately a separate network with a DSL modem was available on 192.168.1.xx for me to use.
Out-of-the box the Conduit comes configured to work on a 192.168.2.1 network with no DHCP so I followed the instructions in the MultiTech documentation to change the IP address to a fixed IP (In my case 192.168.1.49) with the gateway at 192.168.1.1 .
Note that the time zone in the documentation is for Chicago so you need to use your own time zone. In my case I ran:
ln -fs /usr/share/zoneinfo/America/New_York /etc/localtime
The next step is to check the currently installed versions of the LoRa Server and Packet Forwarder following the MuliTech instructions here. In my case I had old versions and needed to upgrade.
I downloaded the new packages from the downloads page to my PC used WinSCP to connect to the Conduit. Use the Conduit’s IP address as the Host Name (i.e. 192.168.1.49 in my case).
I copied the new packages to /var/packages (this was simply my choice and there may be a convention that I am not aware of.)
I then installed them by going to the /var/packages directory using TeraTerm and running them using:
$ opkg install lora-packet-forwarder_1.4.1-r8.16_arm926ejste.ipk
$ opkg install lora-network-server_0.0.8-r0.0_arm926ejste.ipk
As described in the Multitech documentation.
Convert mLinux to a basic packet forwarder to The Things Network using the instructions on the MultiTech site and on The Things Network forum.
Note that the gateway configuration for TTN is as follows:
"gateway_conf" :
{
"forward_crc_disabled" : true,
"forward_crc_error" : false,
"forward_crc_valid" : true,
"gateway_ID" : "<GATEWAY_EUI>",
"keepalive_interval" : 12,
"push_timeout_ms" : 120,
"serv_port_down" : 1700,
"serv_port_up" : 1700,
"server_address" : "54.229.214.112",
"stat_interval" : 20,
"synch_word" : 52
}
Don’t forget to add your EUI from the MTAC-LORA accessory card. Note that I used a fixed IP rather than croft.thethings.girovito.nl since I did not set up the Conduit for DNS.
Set up your mDot using manual join as described on the MultiTech site using the settings from TTN wiki.
Setting Up the mDot Using Manual Join
Check TTN rest API using your browser to see if your message came through by going to:
http://thethingsnetwork.org/api/v0/nodes/your_device_address/ and replace your_device_address with your own device address. If successful you should see data like this returned:
{
"node_eui": "02013E00",
"gateway_eui": "00000008004A02BD",
"data_plain": "Hello from Boston",
"_id": "564cd7127585d2ea79ada581",
"time": "2015-11-18T19:52:50.281Z",
"data_raw": "QAA+AQIABwABIpIHLG7lKVjXia0lOpRtIScfJXlQ",
"data": "SGVsbG8gZnJvbSBCb3N0b24="
},
You can also run tail -f /var/log/lora-pkt-fwd.log as described in the documentation and view the log using the Conduit terminal session.
A successful result should look something like this:
##### 2015-11-18 20:15:22 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 2
# CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 2 (72 bytes)
# PUSH_DATA datagrams sent: 1 (498 bytes)
# PUSH_DATA acknowledged: 100.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 2 (0.00% acknowledged)
# PULL_RESP(onse) datagrams received: 0 (0 bytes)
# RF packets sent to concentrator: 0 (0 bytes)
# TX errors: 0
##### END #####
If you have trouble you can post questions on TTN forum here.