Appreciate the help. I suppose I need to wait for my node to arrive then. Everything else looks good, so looking forward to it!
Hi there, I’m getting results appear in the Node bit of the API - http://thethingsnetwork.org/api/v0/nodes/02011E01/ but there is no entry for my gateway (008000000000A052) in the Gateway bit of the API.
Any idea what I am missing?
I have an mlinux Conduit with an MTAC-LORA-868 card.
Thanks, Mark
@mark: this sounds like the same problem I had with my DIY gateway: Setting up your first gateway
My gateway wasn’t sending geo-info, and because of that, it didn’t show up in the list.
Ah, yes using gps_pkt_fwd makes it appear in the Gateways , thanks
For info gps_pkt_fwd has different params to basic_pkt_fwd - it doesn’t accept -l logfile, so you need to strip that bit out of /etc/init.d/lora-network-server where it uses the start-stop daemon to launch pkt_fwd.
Follow-up question - how do I configure or display the logitude and latitude? Mine are coming out blank. http://thethingsnetwork.org/api/v0/gateways/008000000000A052/
I just filled them in in the global_conf.json file
Fantastic - thanks both for your help - all working nicely now
Just my 2cts
Would be good if someone knowledgeable could turn this thread into a manual like the one described for Kerlink in the Wiki tree?
@markstanley
Just looked at your write-up. Thank you for creating it, however two remarks (I do not want to start modifying your work right away):
- Have you read my messages concerning the difference in (correctly) received packets between gps_pkt_fw and basic_pkt_fwd? If you want to be shown active on TTN I strongly suggest you try my build of poly_pkt_fwd for the MultiTech. Otherwise stay on basic_pkt_fwd if you want reliable packet reception and forwarding and do not need to be shown active.
(poly_pkt_fwd is a ‘drop in’ replacement for basuc_pkt_fwd with regards to the command line arguments) - Not everyone with a MultiTech gateway will have mdots, as a result not everyone needs to sign-up @ mbed. Also people without an MultiTech gateway might use mdots, so may-be it would be better to split it into two pages?
@kersing - sorry to say but I haven’t got poly_pkt_fwd working here. I installed this one: https://github.com/kersing/packet_forwarder/raw/master/multitech-bin/poly-packet-forwarder_2.1-r1_arm926ejste.ipk
Logfile:
*** Poly Packet Forwarder for Lora Gateway ***
Version: 2.1.0
*** Lora concentrator HAL library version info ***
Version: 3.1.0; Options: ftdi;
INFO: Little endian host
INFO: found global configuration file /var/config/lora/global_conf.json, parsing
INFO: /var/config/lora/global_conf.json does contain a JSON object named SX1301_
WARNING: Data type for lorawan_public seems wrong, please check
WARNING: Data type for clksrc seems wrong, please check
INFO: lorawan_public 0, clksrc 0
INFO: no configuration for tx gain lut 0
INFO: no configuration for tx gain lut 1
…
…
INFO: no configuration for tx gain lut 15
INFO: Configuring TX LUT with 0 indexes
WARNING: Failed to configure concentrator TX Gain LUT
@markstanley You need to use the example global_conf.json included as the newer versions of the software made more settings configurable. Alternatively the GitHub repo has example data for both 868 and 915 MHz setups.
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?
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.)
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.
@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.
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
@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
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.
Thanks. The rate jumps around. When using the basic forwarder I got 100% with the same mDot node. Odd. Thanks again for your help