Diagnosing unreliable join-accept reception

[hraftery (Heath Raftery)]

Thank you for those excellent replies. Those nuggets of discovery really do help track this issue down.

After another solid weekend of experimentation I have some more clarifying data. Really hard going this, but the picture is slowly becoming clearer. In the following table, “works” means with the latest software available today unless indicated, downlinks are >80% reliable for “YES”, <20% reliable for “NO”. There was no in-between.

|    *LoRa Card*     | *Plan* |  *LBT*   | *Forwarder* | *Works* |
|--------------------|--------|----------|-------------|---------|
| MTAC-LORA-1.5 v31  | AS923  | disabled | mp-pkt-fwd  | YES     |
| MTAC-LORA-1.5 v33  | AS923  | enabled  | mp-pkt-fwd  | NO      |
| MTAC-LORA-1.0      | AS923  | disabled | gps-pkt-fwd | YES     |
| MTAC-LORA-1.0      | AS923  | disabled | mp-pkt-fwd  | NO      |
| MTAC-LORA-1.0      | AU915  | N/A      | mp-pkt-fwd  | NO      |

For the AS923 scenarios I tried both AS1 and AS2 with no change. For the gps-pkt-fwd scenarios I even tried the TTN global_conf.json and for the mp-pkt-fwd the MultiTech global_conf.json, all with no change.

There was two major challenges that made the going tough - once you know them they are not a problem, so for posterity:

1. gps-pkt-fwd is the forwarder that gets run by MultTech’s Lora Packet Forwarder if the config file has fake_gps set to true. gps-pkt-fwd (and its non-gps brother, basic-pkt-fwd) are “Legacy Semtech Packet Forwarders”. That means they use UDP on port 1700, and require a gateway in TTN’s console explicitly for the legacy forwarder (click the “using Semtech forwarder” checkbox and note the gateway ID will be eui-xxx where xxx is the gateway’s EUI). Authorisation is not supported, so the gateway key is not used. The global_conf.json files provided by MultiTech are all you need, provided you override gateway_ID, server_address, serv_port_up and serv_port_down, with the gateway’s EUI (use mts-io-sysfs show lora/eui and remove the colons), which ever router you want to use, 1700 and 1700 respectively. Oh, and to enable gps-pkt-fwd also add "fake_gps": true,"ref_latitude": -x.x,"ref_longitude": x.x,"ref_altitude": x where the x's are appropriate numbers.
2. /etc/init.d/ttn-packet-forwarder stop doesn’t. I think at one stage it relied on mp-pkt-fwd killing itself if /var/run/run-lora is missing, but that doesn’t work for me at the moment. Judging by the source, it just responds to HUP by rotating the log file. Maybe my install is hosed, but I had to remove the HUP signals from ttn-packet-forwader (the -s 1 and -1 flags) so the start-stop-daemon and killall calls would actually kill mp-pkt-fwd.

So these signs are pointing to an issue with the new mp-pkt-fwd and the old MultiTech LoRa cards. Further investigation is necessary to see if it’s something to do with the rx delay.

[hraftery (Heath Raftery)]

One more tidbit before I hit the hay. Here is the start of the log file when gps-pkt-fwd boots up:

*** GPS Packet Forwarder for Lora Gateway ***
Version: 1.4.1
*** Lora concentrator HAL library version info ***
Version: 1.7.0; Options: ftdi sx1301 sx1257 full mtac-lora private;

And here is the equivalent for mp-pkt-fwd:

20:28:15  *** Multi Protocol Packet Forwarder for Lora Gateway ***
Version: 3.0.20
20:28:15  *** Lora concentrator HAL library version info ***
Version: 5.0.1; Options: ftdi;

Significant difference?

[kersing (Jac Kersing)]

Thanks for the thorough investigation and report!

@hraftery

/etc/init.d/ttn-packet-forwarder stop doesn’t. I think at one stage it relied on mp-pkt-fwd killing itself if /var/run/run-lora is missing, but that doesn’t work for me at the moment.

No it didn’t. It relied on SIGHUP not being used to cycle the logfile (introduced in a newer version of the software and I simply forgot to update the script).

@hraftery

Judging by the source, it just responds to HUP by rotating the log file. Maybe my install is hosed, but I had to remove the HUP signals from ttn-packet-forwader (the -s 1 and -1 flags) so the start-stop-daemon and killall calls would actually kill mp-pkt-fwd .

You can substitute the 1 by 2 or 15 (also the default if none specified) to fix the script.

@hraftery

Significant difference?

Could well be. I had to apply a patch to get the HAL to recognize the older MultiTech fpga firmwares. There might be a breaking change for 915MHz in there (I haven’t seen any release notes for the fpga firmware so I don’t know the changes) Also hard for me to test being in EU868.