Issues with New Pi-based LoRa Gateway using Linklabs Shield


(Sd79) #1

Hi there,

Currently in the process of setting up a new LoRa Gateway at home using a Raspberry Pi, LinkLabs Shield (https://www.amazon.co.uk/868-MHz-LoRaWAN-RPi-Shield/dp/B01G7G54O2) etc - based the install on the project here: https://github.com/mirakonta/Raspberry-PI-Link-Labs-LoRaWAN-Gateway BUT…despite my best efforts I am currently finding that i get errors on running the start.sh script - details as follows:

*** GPS Packet Forwarder for Lora Gateway ***
Version: 2.2.1
*** Lora concentrator HAL library version info ***
Version: 3.2.1;


INFO: Little endian host
INFO: found global configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
INFO: lorawan_public 1, clksrc 1
INFO: Configuring TX LUT with 16 indexes
INFO: radio 0 enabled (type SX1257), center frequency 867500000, RSSI offset -166.000000, tx enabled 1
INFO: radio 1 enabled (type SX1257), center frequency 868500000, RSSI offset -166.000000, tx enabled 0
INFO: Lora multi-SF channel 0> radio 1, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 1> radio 1, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 2> radio 1, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 3> radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 4> radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 5> radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 6> radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 7> radio 0, IF 400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7
INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate
INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: server hostname or IP address is configured to "router.eu.thethings.network"
INFO: upstream port is configured to "1700"
INFO: downstream port is configured to "1700"
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: found local configuration file local_conf.json, parsing it
INFO: redefined parameters will overwrite global parameters
ERROR: local_conf.json is not a valid JSON file

I’ve checked the local_conf.json in Json Lint tool which says there is an error:

Error: Parse error on line 1:
{“ gateway_conf”: {“
-^
Expecting ‘STRING’, ‘}’, got ‘undefined’

But - everything looks fine on inspection - e.g. no trailing " etc - anyone else get this issue or can share their config file?

ALSO - I am having trouble trying to see where to get the Gateway ID from - there is only a long LLXXXXXX number on the board itself - anyone else know how to get this?

Thanks in advance!!


Gateway ID : x-FFFF-y or x-FFFE-y?
Microchip Gateway is online but not showing in TTN
(Jac Kersing) #2

Did you cut-and-paste from a document? The quotes look suspicious, you should be using ", not “.
Also, quotes should be adjacent to the identifier, no spaces in between, so you config should start with:

{
    "gateway_conf": {
        "gateway_ID":

For the gateway ID you need to use the MAC address from your ethernet interface with FFFE inserted in the middle. So if your MAC is: 0123456789AB the gateway ID is 012345FFFE6789AB.


(Sd79) #3

Ah - okay, so thanks!! I managed to get that resolved, but then hit other issues which i have worked through - predominantly down to config values etc - but things now appear to be working to a point where I get the following:

INFO: [main] concentrator started, packet can now be received

However, when i go to TTN and look at the Console, the gateway i registered through their tool is saying that it ‘isn’t connected’ - looking at the pi logs, i see the following:

##### 2018-03-06 15:57:55 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 2
# CRC_OK: 0.00%, CRC_FAIL: 100.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 time reference (age: 1520351875 sec)
# no valid GPS coordinates available yet
##### END #####

##### 2018-03-06 16:02:55 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 4
# CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (111 bytes)
# PUSH_DATA acknowledged: 0.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
### [GPS] ###
# Invalid time reference (age: 1520352175 sec)
# no valid GPS coordinates available yet
##### END #####

Any ideas? Not sure how to test this any further right now, hardware appears to be working okay locally, and has a working wireless comms path back to TTN…


(Sd79) #6

Note that the debug output from ‘start’ varies from what i shared previously with the 100% fail, to the following:

##### 2018-03-06 16:27:55 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 3
# CRC_OK: 33.33%, CRC_FAIL: 66.67%, NO_CRC: 0.00%
# RF packets forwarded: 1 (16 bytes)
# PUSH_DATA datagrams sent: 2 (311 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 time reference (age: 1520353675 sec)
# no valid GPS coordinates available yet
##### END #####

##### 2018-03-06 16:32:55 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 3
# CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (111 bytes)
# PUSH_DATA acknowledged: 0.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
### [GPS] ###
# Invalid time reference (age: 1520353975 sec)
# no valid GPS coordinates available yet
##### END #####

##### 2018-03-06 16:37:55 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 (111 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 time reference (age: 1520354275 sec)
# no valid GPS coordinates available yet
##### END #####

##### 2018-03-06 16:42:55 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 1
# CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 1 (16 bytes)
# PUSH_DATA datagrams sent: 2 (311 bytes)
# PUSH_DATA acknowledged: 0.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
### [GPS] ###
# Invalid time reference (age: 1520354575 sec)
# no valid GPS coordinates available yet
##### END #####

(Jac Kersing) #7

Which server have you configured for packet destination?


(Sd79) #8
{
...
"servers": [ { "server_address": "router.eu.thethings.network", "serv_port_up": 1700, "serv_port_down": 1700, "serv_enabled": true } ],
...
}

(Sd79) #9

Plus, i’ve also tried to now configure the main router firewall to allow UDP as follows:

#	Enable	Service Name	Action	LAN Users	                                WAN Servers
Any(UDP)	ALLOW always	192.168.0.81 -192.168.0.82 (1:65535)	0.0.0.0 (1:65535)

(Jac Kersing) #10

Try tcpdump to check if there is traffic. You should be seeing poll packets and replies. Make sure return UDP traffic is allowed as well.
BTW, I would restrict firewall traffic to allow traffic to destination port 1700.


(Sd79) #11

Thanks - well, TCPDump is only showing packets between Raspberry Pi and my Laptop, that’s it - nothing else going to the TTN server…


(Jac Kersing) #12

Does name resolving work?


(Sd79) #13

Yes, if I ping www.bbc.com for example, that resolves without any issues…

Doing a little more digging, ran iptraf to see what connections were open on the Pi - again, don’t see anything connecting out to the TTN server, simply between my Mac and the Pi, and vice versa…e.g.

│ UDP (339 bytes) from 192.168.0.28:5353 to 224.0.0.251:5353 on eth0                                                                                                                                                            │
│ UDP (339 bytes) from 192.168.0.30:5353 to 224.0.0.251:5353 on eth0                                                                                                                                                            │
│ UDP (339 bytes) from 192.168.0.76:5353 to 224.0.0.251:5353 on eth0                                                                                                                                                            │
│ UDP (256 bytes) from 192.168.0.19:17500 to 255.255.255.255:17500 on eth0                                                                                                                                                      │
│ UDP (256 bytes) from 192.168.0.19:17500 to 192.168.0.255:17500 on eth0                                                                                                                                                        │
│ UDP (65 bytes) from 192.168.0.19:5353 to 224.0.0.251:5353 on eth0                                                                                                                                                             │
│ UDP (68 bytes) from 192.168.0.25:5353 to 224.0.0.251:5353 on eth0                                                                                                                                                             │
│ UDP (238 bytes) from 192.168.0.25:5353 to 224.0.0.251:5353 on eth0                                                                                                                                                            │
│ UDP (73 bytes) from 192.168.0.19:5353 to 224.0.0.251:5353 on eth0                                                                                                                                                             │
│ UDP (93 bytes) from fe80::bae8:56ff:fe33:2a34:5353 to ff02::fb:5353 on eth0                                                                                                                                                   │
│ UDP (339 bytes) from 192.168.0.76:5353 to 224.0.0.251:5353 on eth0                                                                                                                                                            │
│ UDP (339 bytes) from 192.168.0.30:5353 to 224.0.0.251:5353 on eth0                                                                                                                                                            │
│ UDP (339 bytes) from 192.168.0.28:5353 to 224.0.0.251:5353 on eth0                                                                                                                                                            │
│ UDP (512 bytes) from 192.168.0.28:32768 to 255.255.255.255:1900 on eth0                                                                                                                                                       │
│ UDP (565 bytes) from 192.168.0.28:32768 to 255.255.255.255:1900 on eth0                                                                                                                                                       │
│ UDP (515 bytes) from 192.168.0.28:32768 to 255.255.255.255:1900 on eth0                                                                                                                                                       │
│ UDP (65 bytes) from 192.168.0.19:5353 to 224.0.0.251:5353 on eth0                                                                                                                                                             │
│ UDP (147 bytes) from 192.168.0.10:9956 to 192.168.0.255:9956 on eth0                                                                                                                                                          │
│ UDP (173 bytes) from 192.168.0.10:9956 to 192.168.0.255:9956 on eth0                                                                                                                                                          │
│ UDP (65 bytes) from 192.168.0.19:5353 to 224.0.0.251:5353 on eth0                                                                                                                                                             │
│ UDP (65 bytes) from 192.168.0.19:5353 to 224.0.0.251:5353 on eth0    

Even looking at the netstat results, as follows:

sudo netstat -lptu
...
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN      411/sshd            
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      411/sshd            
udp        0      0 0.0.0.0:mdns            0.0.0.0:*                           317/avahi-daemon: r 
udp        0      0 0.0.0.0:46912           0.0.0.0:*                           317/avahi-daemon: r 
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*                           365/dhcpcd          
udp6       0      0 [::]:mdns               [::]:*                              317/avahi-daemon: r 
udp6       0      0 [::]:dhcpv6-client      [::]:*                              365/dhcpcd          
udp6       0      0 [::]:45723              [::]:*                              317/avahi-daemon: r

(Sd79) #14

Also worth mentioning i have tried to do a tcpdump on port 1700, and shows nothing:

sudo tcpdump -n udp dst port 1700
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Running a test on general UDP packets shows up as before:

linklabs@raspberrypi:~ $ sudo tcpdump -n udp 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:50:30.018278 IP 192.168.0.58.58186 > 239.255.255.250.1900: UDP, length 403
09:50:30.018507 IP 192.168.0.58.58186 > 239.255.255.250.1900: UDP, length 412
09:50:30.018852 IP 192.168.0.58.58186 > 239.255.255.250.1900: UDP, length 451
09:50:30.019134 IP 192.168.0.58.60576 > 239.255.255.250.1900: UDP, length 447
09:50:30.019510 IP 192.168.0.58.53677 > 239.255.255.250.1900: UDP, length 443
09:50:30.019773 IP 192.168.0.58.51083 > 239.255.255.250.1900: UDP, length 443
09:50:30.120973 IP 192.168.0.58.60942 > 239.255.255.250.1900: UDP, length 403
09:50:30.121289 IP 192.168.0.58.60942 > 239.255.255.250.1900: UDP, length 412
09:50:30.121510 IP 192.168.0.58.60942 > 239.255.255.250.1900: UDP, length 451
09:50:30.121840 IP 192.168.0.58.53643 > 239.255.255.250.1900: UDP, length 447
09:50:30.122191 IP 192.168.0.58.65036 > 239.255.255.250.1900: UDP, length 443
09:50:30.122690 IP 192.168.0.58.54490 > 239.255.255.250.1900: UDP, length 443
09:50:30.701009 IP 192.168.0.19.17500 > 255.255.255.255.17500: UDP, length 228
09:50:30.702204 IP 192.168.0.19.17500 > 192.168.0.255.17500: UDP, length 228
09:50:32.789914 IP 192.168.0.19.5353 > 224.0.0.251.5353: 41253 PTR (QM)? _arduino._tcp.local. (37)
09:50:36.567627 IP 192.168.0.58.59268 > 239.255.255.250.1900: UDP, length 403
09:50:36.567853 IP 192.168.0.58.59268 > 239.255.255.250.1900: UDP, length 412
09:50:36.568073 IP 192.168.0.58.59268 > 239.255.255.250.1900: UDP, length 449
09:50:36.568402 IP 192.168.0.58.61801 > 239.255.255.250.1900: UDP, length 451
09:50:36.669946 IP 192.168.0.58.56744 > 239.255.255.250.1900: UDP, length 403
09:50:36.670183 IP 192.168.0.58.56744 > 239.255.255.250.1900: UDP, length 412
09:50:36.670439 IP 192.168.0.58.56744 > 239.255.255.250.1900: UDP, length 449
09:50:36.670756 IP 192.168.0.58.59098 > 239.255.255.250.1900: UDP, length 451
09:50:36.796287 IP 192.168.0.19.5353 > 224.0.0.251.5353: 56098 PTR (QM)? _arduino._tcp.local. (37)
09:50:39.473271 IP 192.168.0.58.49933 > 239.255.255.250.1900: UDP, length 403
09:50:39.473498 IP 192.168.0.58.49933 > 239.255.255.250.1900: UDP, length 412
09:50:39.473829 IP 192.168.0.58.49933 > 239.255.255.250.1900: UDP, length 447
09:50:39.474067 IP 192.168.0.58.59367 > 239.255.255.250.1900: UDP, length 447
09:50:39.474475 IP 192.168.0.58.60834 > 239.255.255.250.1900: UDP, length 451
09:50:39.576016 IP 192.168.0.58.53323 > 239.255.255.250.1900: UDP, length 403
09:50:39.576463 IP 192.168.0.58.53323 > 239.255.255.250.1900: UDP, length 412
09:50:39.576698 IP 192.168.0.58.53323 > 239.255.255.250.1900: UDP, length 447
09:50:39.577005 IP 192.168.0.58.64925 > 239.255.255.250.1900: UDP, length 447
09:50:39.577406 IP 192.168.0.58.52989 > 239.255.255.250.1900: UDP, length 451
09:50:40.801710 IP 192.168.0.19.5353 > 224.0.0.251.5353: 49484 PTR (QM)? _arduino._tcp.local. (37)
09:50:43.054962 IP 192.168.0.10.9956 > 224.0.0.113.9956: UDP, length 119
09:50:43.055273 IP 192.168.0.10.9956 > 192.168.0.255.9956: UDP, length 119
09:50:43.055551 IP 192.168.0.10.9956 > 224.0.0.113.9956: UDP, length 145
09:50:43.055794 IP 192.168.0.10.9956 > 192.168.0.255.9956: UDP, length 145
09:50:44.809128 IP 192.168.0.19.5353 > 224.0.0.251.5353: 35082 PTR (QM)? _arduino._tcp.local. (37)
09:50:48.814587 IP 192.168.0.19.5353 > 224.0.0.251.5353: 46167 PTR (QM)? _arduino._tcp.local. (37)
09:50:51.125634 IP 192.168.0.58.53869 > 239.255.255.250.1900: UDP, length 403
09:50:51.125866 IP 192.168.0.58.53869 > 239.255.255.250.1900: UDP, length 412
09:50:51.126718 IP 192.168.0.58.53869 > 239.255.255.250.1900: UDP, length 451
09:50:51.127214 IP 192.168.0.58.59798 > 239.255.255.250.1900: UDP, length 447
09:50:51.127560 IP 192.168.0.58.58128 > 239.255.255.250.1900: UDP, length 443
09:50:51.127989 IP 192.168.0.58.61206 > 239.255.255.250.1900: UDP, length 443
09:50:51.229948 IP 192.168.0.58.50017 > 239.255.255.250.1900: UDP, length 403
09:50:51.230188 IP 192.168.0.58.50017 > 239.255.255.250.1900: UDP, length 412
09:50:51.230418 IP 192.168.0.58.50017 > 239.255.255.250.1900: UDP, length 451
09:50:51.230701 IP 192.168.0.58.57656 > 239.255.255.250.1900: UDP, length 447
09:50:51.230963 IP 192.168.0.58.64537 > 239.255.255.250.1900: UDP, length 443
09:50:51.231330 IP 192.168.0.58.59229 > 239.255.255.250.1900: UDP, length 443
^C
53 packets captured
53 packets received by filter
0 packets dropped by kernel
linklabs@raspberrypi:~ $

(Sd79) #15

Looking at the startup messages, i noticed that the upstream / downstream ports are different than what is in the local_config file, plus the damn server name / address:

*** GPS Packet Forwarder for Lora Gateway ***
Version: 2.2.1
*** Lora concentrator HAL library version info ***
Version: 3.2.1;
***
INFO: Little endian host
INFO: found global configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
INFO: lorawan_public 1, clksrc 1
INFO: Configuring TX LUT with 16 indexes
INFO: radio 0 enabled (type SX1257), center frequency 867500000, RSSI offset -166.000000, tx enabled 1
INFO: radio 1 enabled (type SX1257), center frequency 868500000, RSSI offset -166.000000, tx enabled 0
INFO: Lora multi-SF channel 0>  radio 1, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 1>  radio 1, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 2>  radio 1, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 3>  radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 4>  radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 5>  radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 6>  radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 7>  radio 0, IF 400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7
INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate
INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to B827EBFFFEAA5501
INFO: server hostname or IP address is configured to "localhost"
INFO: upstream port is configured to "1680"
INFO: downstream port is configured to "1680"
INFO: downstream keep-alive interval is configured to 10 seconds
INFO: statistics display interval is configured to 30 seconds
INFO: upstream PUSH_DATA time-out is configured to 100 ms
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: GPS serial port path is configured to "/dev/ttyAMA0"
INFO: found local configuration file local_conf.json, parsing it
INFO: redefined parameters will overwrite global parameters
INFO: local_conf.json does not contain a JSON object named SX1301_conf
INFO: local_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to B827EBFFFEAA5501
INFO: downstream keep-alive interval is configured to 120 seconds
INFO: statistics display interval is configured to 300 seconds
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: Reference latitude is configured to XX.XXXXX deg
INFO: Reference longitude is configured to -X.XXXXX deg
INFO: Reference altitude is configured to 0 meters
INFO: [main] TTY port /dev/ttyAMA0 open for GPS synchronization
INFO: [main] concentrator started, packet can now be received

Changed the Global_conf.json file values (including just giving the TTN EU endpoint IP Address instead of the dns name) as a test and all of a sudden i get a new message to say the following:

INFO: [down] PULL_ACK received in 38 ms

Nothing else though after that ATM…and looking in the TTN Console, still says ‘not connected’ - any ideas??!

And here was me thinking this might be a nice simple way to get something running and help my local village! lol

TIA


(Sd79) #16

OKAY!! :slight_smile:

I’ve got it working and the TTN Gateway status is now showing as ‘Connected’ - FINALLY!!

Having left the Pi Gateway to run for a few minutes, it seems further up and down messages were received! So, the issue looks to have been something to do with the global_conf not being entirely overwritten by the values in the local_conf for some reason - hence the IP address and ports not being correct…changed those in both files (although i know i shouldn’t need to!) and things have started working for me! Now, just to test with a sensor and see if i can actually see anything useful!


(Jac Kersing) #17

May-be it would be easier to use one of the resin.io based installations next time :wink: (I use https://github.com/jpmeijers/ttn-resin-gateway-rpi)