Mulitech AEP with AS923 (Australia)

Gateways MultiTech Gateways
1

Hi there,
I’ve been having some issues getting a Multitech AEP Conduit (MTCDT-LEU1-247A-915) relaying data to TTN. The gateway shows join requests and accepts, however will not progress to the data transaction. I am using an xDot as my end device, and am looking at working with AS923 due to band plan changes in Australia (using frequency sub-band 2). The device does connect to local public network, and data flows as expected. This has led me to believe that it is this gateway I am using that is causing the issues. The conduit is connected to the internet using a cellular back haul.

Upon viewing the log output for the packet forwarder, the error that occurs within the gateway is : Cannot send packet, channel is busy (LBT). I have followed the steps mentioned in this forum discussion (Multilink Conduit install problems), with the FPGA updated to the required version successfully. I have also changed the global config to set LBT to false, along with making sure the TTN latest is not pulled and updated at packet forwarder run time. I have tried various settings and config files, but there has been no luck in successfully getting data through.

Any help or guidance in the right direction will be greatly appreciated.
Cheers,
Vanja

2

After the changes to the configuration, do you still see the channel is busy messages?

3

I just had a very similar experience and it turns out that the /opt/lora/run_forwarder script was downloading a new ttn_global_conf.json that enabled LBT, overwriting my changes. I commented that line out and now the packet forwarder runs without LBT and the device works.

Now the question is why does LBT not work? These are the messages I get in the log:

15:35:03  INFO: [up] TTN lora packet send to server "bridge.us-west.thethings.network"
15:35:08  INFO: [down] TTN received downlink with payload
15:35:08  INFO: [TTN] downlink 33 bytes
INFO: Enabling TX notch filter
66.cc.cc.53.cc.8f.57.9.0.9a.21.10.0.8.0.0.20.c6.a7.e0.de.37.4b.55.7f.c5.20.68.3.d1.12.51.59.2f.6a.37.8f.2d.e0.ef.5a.85.b4.33.e8.40.fb.17.de.end
ERROR: Cannot send packet, channel is busy (LBT)
4

Yes, there are still busy channel messages

5

What band change is this? Are you going from AU915 to AS923?

6

Exactly, there’s a push for 923 over here at the moment so I’m trying to port some devices over

7

At the moment with low traffic levels we can happily run both a 915 and a 923 channel configuration in Australia. However when traffic levels increase and we move to a mode where Gateways are placed on the basis of Capacity Planning the two different schemes will most likely reduce the potential capacity of overall ISM band. Also remember there are other system (even LoraWan) in use that are not in the Block 2 as used by TTN.

Just something to consider.

8

Im not yet seeing large scale congestion, There is however other thigns operating in the AU915 sub-band 02 space… My gateway is seeing several packets per minute that are not TTN.

Capture

9

For the gateway to decode the signal I assume it must be a LoraWan packet, probably from another LoraWan system, ie not a TTN system, most likely LoraServer.io. The other users of the ISM band should not result in an output from the gateway.
To help people set up LoraServer.io systems outside of Block2 I contributed to its development and created the ability to commission that system on other blocks. Otherwise Block 2 would become congested by being the default for everyone.