SX1302 Using Semtech packet forwarder can not register the gateway

How to get started
22 
pi@raspberrypi:~ $ ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:ae:4d:38  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

*** Packet Forwarder ***
Version: 1.0.5
*** SX1302 HAL library version info ***
Version: 1.0.5;
***
INFO: Little endian host
INFO: found configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX130x_conf, parsing SX1302 parameters
INFO: spidev_path /dev/spidev0.0, lorawan_public 1, clksrc 0, full_duplex 0
INFO: antenna_gain 0 dBi
INFO: Configuring legacy timestamp
INFO: Configuring Tx Gain LUT for rf_chain 0 with 16 indexes for sx1250
INFO: radio 0 enabled (type SX1250), center frequency 474600000, RSSI offset -207.000000, tx enabled 1, single input mode 1
INFO: radio 1 enabled (type SX1250), center frequency 475400000, RSSI offset -207.000000, tx enabled 0, single input mode 1
INFO: Lora multi-SF channel 0>  radio 0, IF -300000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 1>  radio 0, IF -100000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 2>  radio 0, IF 100000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 3>  radio 0, IF 300000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 4>  radio 1, IF -300000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 5>  radio 1, IF -100000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 6>  radio 1, IF 100000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 7>  radio 1, IF 300000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7, Explicit header
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 DCA632FFFEAE4D38
INFO: server hostname or IP address is configured to "asia-se.thethings.network"
INFO: upstream port is configured to "1700"
INFO: downstream port is configured to "1700"
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: Beaconing period is configured to 0 seconds
INFO: Beaconing signal will be emitted at 869525000 Hz
INFO: Beaconing datarate is set to SF9
INFO: Beaconing modulation bandwidth is set to 125000Hz
INFO: Beaconing TX power is set to 14dBm
INFO: Beaconing information descriptor is set to 0
INFO: global_conf.json does contain a JSON object named debug_conf, parsing debug parameters
INFO: got 2 debug reference payload
INFO: reference payload ID 0 is 0xCAFE1234
INFO: reference payload ID 1 is 0xCAFE2345
INFO: setting debug log file name to loragw_hal.log
CoreCell reset through GPIO7...
INFO: Configuring SX1250_0 in single input mode
INFO: Configuring SX1250_1 in single input mode
INFO: [main] concentrator started, packet can now be received
INFO: concentrator EUI: 0x0016c001ff10d3f6

##### 2020-11-10 13:31:35 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
### SX1302 Status ###
# SX1302 counter (INST): 30730218
# SX1302 counter (PPS):  0
# BEACON queued: 0
# BEACON sent so far: 0
# BEACON rejected: 0
### [JIT] ###
src/jitqueue.c:442:jit_print_queue(): INFO: [jit] queue is empty
#--------
src/jitqueue.c:442:jit_print_queue(): INFO: [jit] queue is empty
### [GPS] ###
# GPS sync is disabled
##### END #####

JSON up: {"stat":{"time":"2020-11-10 13:31:35 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0}}

There is still no connection, but I have to thank you for your continuous enthusiastic response.

23

That doesn’t show us your DNS entry (cat /etc/resolv.conf) and it appears you only have IP6 configured - is there some form of gateway / translation on to the internet at large?

What does pinging a known host get you?

24 
pi@raspberrypi:~ $ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.3.1
nameserver fe80::2ec5:46ff:feb3:4e7b%wlan0

I can ping my own Alibaba Cloud server:

pi@raspberrypi:~ $ ping 47.110.36.225
PING 47.110.36.225 (47.110.36.225) 56(84) bytes of data.
64 bytes from 47.110.36.225: icmp_seq=1 ttl=51 time=295 ms
64 bytes from 47.110.36.225: icmp_seq=2 ttl=51 time=252 ms
64 bytes from 47.110.36.225: icmp_seq=3 ttl=51 time=138 ms
64 bytes from 47.110.36.225: icmp_seq=4 ttl=51 time=259 ms
64 bytes from 47.110.36.225: icmp_seq=5 ttl=51 time=232 ms
64 bytes from 47.110.36.225: icmp_seq=6 ttl=51 time=306 ms
64 bytes from 47.110.36.225: icmp_seq=7 ttl=51 time=270 ms
64 bytes from 47.110.36.225: icmp_seq=8 ttl=51 time=198 ms
64 bytes from 47.110.36.225: icmp_seq=9 ttl=51 time=217 ms
64 bytes from 47.110.36.225: icmp_seq=11 ttl=51 time=238 ms
64 bytes from 47.110.36.225: icmp_seq=12 ttl=51 time=202 ms
64 bytes from 47.110.36.225: icmp_seq=13 ttl=51 time=186 ms
64 bytes from 47.110.36.225: icmp_seq=14 ttl=51 time=252 ms
64 bytes from 47.110.36.225: icmp_seq=15 ttl=51 time=231 ms
64 bytes from 47.110.36.225: icmp_seq=17 ttl=51 time=267 ms
^C
--- 47.110.36.225 ping statistics ---
17 packets transmitted, 15 received, 11.7647% packet loss, time 166ms
rtt min/avg/max/mdev = 137.982/236.222/306.036/42.230 ms

However, I cannot ping the asia-se.thethings.network:

pi@raspberrypi:~ $ ping 13.76.41.40
PING 13.76.41.40 (13.76.41.40) 56(84) bytes of data.
^C
--- 13.76.41.40 ping statistics ---
16 packets transmitted, 0 received, 100% packet loss, time 592ms
25

OK, so we know you have basic connectivity - you can’t ping the clusters, they are behind load balancers so that’s quite normal.

However I see you used an IP address so we don’t really actually know if your DNS is active

So try pinging something by name please

26

I ping a search engine in China, and it works well.

pi@raspberrypi:~ $ ping www.baidu.com
PING www.a.shifen.com (180.101.49.11) 56(84) bytes of data.
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=1 ttl=55 time=293 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=2 ttl=55 time=309 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=3 ttl=55 time=258 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=4 ttl=55 time=224 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=5 ttl=55 time=274 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=6 ttl=55 time=262 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=7 ttl=55 time=227 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=8 ttl=55 time=182 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=9 ttl=55 time=235 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=10 ttl=55 time=299 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=12 ttl=55 time=282 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=13 ttl=55 time=289 ms
64 bytes from 180.101.49.11 (180.101.49.11): icmp_seq=14 ttl=55 time=310 ms
^C
--- www.a.shifen.com ping statistics ---
15 packets transmitted, 13 received, 13.3333% packet loss, time 436ms
rtt min/avg/max/mdev = 182.291/265.061/310.472/36.998 ms
27

I find this theory that certain patterns are disallowed rather dubious.

But if it is true, then it should be something that can be confirmed setting such a suspect eui in an ordinary SX1301 packet forwarder, too.

28

I agree, however back in June this was the case, equally why would adding temperature as an extra data element to the JSON string make it fail.

I was reporting my experience on the Mesh server and the issue here is on the SE Asia server. Remember the servers are not all the same, for example, there are a number of Integrations that don’t work off Meshed.

Essentially we were offering some options to explore not know if they applied to the SE Asia server or not. I may also repeat the tests on Meshed and see if its different now.

29

The problem is that a “lore” of unconfirmed suspicions causes people to waste a lot of time trying things without really knowing if they help. That’s magic, not engineering.

If there’s actual a problem with certain EUI patterns, then it’s a problem that can be confirmed using some other sort of packet forwarder, like a standard SX1301 setup.

That would be in contrast to something like say, a bug in the packet forwader, where it might use a different EUI in different situations (though lets hope anything so extreme would have been quickly caught).

why would adding temperature as an extra data element to the JSON string make it fail.

That would be another unconfirmed guess. A JSON parser is not supposed to care about additional fields. Though an implementation that had a fixed length buffer somewhere could choke on a longer message than previously seen. But again that’s something that could be confirmed, for example by modifying a standard packet forwarder to send a few extra bogus fields.

The community is served by having confirmed factual knowledge of issues. In addition to a confirmed dependence on specific gateway-side behavior, any real issue should be recognizable in the server source code, knowable aspects of Internet protocols, etc.

30

Hi, its not a guess, when I modified the SX1302 packet forwarder code last June and removed the temperature field it fixed the problem.

Reasonable idea. Over the next few days I’ll see if I can get the time to do this.

31

Hi @cslorabox, Am I a Magician or an Engineer? :thinking:

To assist, I have repeated the tests performed and reported in June (link provided above) as well as extending these to the V3 platform. I will report on these shortly.

Would be interested to compare these results with tests you could perform on your local server.

32

I have replicated the issue in the V3 stack and its the same as I found last June.

I’m sure this will be resolved in the longer term, but for now I’ve published a modified packet forwarder.

A more detailed description of the issue can be found on GitHub and its associated with the use of V1.3 of the gateway-to-server protocol.

It also includes a second patch to address the problem where the gateway radio module does not have a stts751 temperature sensor.

33

Presumably you mean the theory that the temperature field is causing an issue.

Your repo would be a lot more useful if in its commit history you identified where it forked from Semtech’s code (indeed, if you retained rather than eliminated Semtech’s commit history) and then had a single well-titled commit making the functional changes you feel are appropriate.

34

As I posted last week, I would be interested to see if this can be repeated on another server. I’ve only tried this on the Meshed server and more recently on a V3 instance running on The Things Industries.

I’ll have a look at taking on your suggestion re the Repo, in the interim I’ve deleted the Repo and will have another try.

35

When I use the global.conf and lora_pkt_fwd above, there is an error.

pi@raspberrypi:~/gw1302s/bin $ ./lora_pkt_fwd
*** Packet Forwarder ***
Version: 1.0.5
*** SX1302 HAL library version info ***
Version: 1.0.5;
***
INFO: Little endian host
INFO: found configuration file global_conf.json, parsing it
ERROR: global_conf.json is not a valid JSON file
36

Did you edit the global_config.json file and insert your own gateway ID?

this file has the following which needs to be changed
“gateway_ID”: “Place your gateway ID here”

37

Yes I did, and
When I use your global.conf and my own lora_pkt_fwd, it has the same error above.
When I ues my own global.conf and your lora_pkt_fwd, it has another error:

ERROR: invalid I2C file descriptor
ERROR: invalid I2C file descriptor
ERROR: failed to configure the temperature sensor
ERROR: [main] failed to start the concentrator
pi@raspberrypi:~/gw1302s/bin $ ./lora_pkt_fwd
38

Can you try two things with the combination of your global_config.json (with the 3 extra commands added) and my lora_pkt_fwd.

I suspect it has a temp sensor either not at the standard address or not the same type of sensor

  1. on the Raspberry Pi terminal run the command sudo i2cdetect -y 1 and see if you have a sensor at address 3b
  2. in the global_config.json can you set the “temperature_sensor”: false,
39

My bad, just found an error in my global_config.json

The comment line below did not have the */ at the end. It should look like the following
/* if the following line is missing but required, the default value is 20.0C */

40

QQ截图20201122164341
When I use my own lora_pkt_fwd and your global.config, I can communicate normally, but I can’t see the ‘Status：connection’. When I remove the temperature related code in lora_pkt_fwd , I can see ‘Status：connection’.

Next, I will use the control variable method to achieve a successful connection on the Japanese server.

By the way, in the global.config, I set the ‘gateway_ID’ the same as the ‘concentrator EUI’, and I do not use ‘FF FE’ and something like that.

41

The issue why the server rejects packets with the temp variable has been identified by TTN.
In the V3 stack it is coded as a signed integer while the SX1302 UDP packet forwarder, which is based on version v1.3 of the gateway-to-server protocol, is a float.
This can be seen in the open source code for the V3 stack on Line 118 of the link below.
While a future version of the V3 stack will be adjusted I would not expect the current V2 server to be modified given the freeze on making changes.

2 Likes