Node activation OTAA and ABP issue

I have this issue where a node sends a join request and it is accepted by the Match X gateway. The gateway generates the device address, Network session key and Application session key, yet the Uplink frame-counter and down frame-counter remain at zero.

When I attempt the connection using a gateway from another provider it works fine.

Now when attempting to join the gateway with another node in abp mode. I only get Unconfirmed data Up and no acknowledgement from the gateway about the node.

Is there something in the configuration settings that I am missing or any known issues with other customers that have presented this kind of issue? Any help or direction to diagnosing the issue would be highly appreciated.

Hello sebb,

Gateway doesn’t really have anything to do with setting frame counters, accepting join requests or replying to the nodes. They simply forward messages between server and nodes and server is responsible for all of this.

When it comes to Unconfirmed Data Up - well if this is the frame type the server gets from the node you should not expect acknowledgment - as name suggest it is unconfirmed frame. If you want an ack you need to send ConfirmedDataUp message.

And about the Frame Counters - is the node able to join the server? Can it receive the join accept message?

Hello @piotr,
Thanks for your prompt reply. Just to clarify the other gateway I am comparing has an in built Lora server, therefore based on your information it answers my questions but raises a few others.
Apologies if the following questions are simple and probably common knowledge but I am just fairly new to this topic.

That makes sense. So just to clarify aux.matchx.io acts as:
A: Configuration interface for the gateway and Lora packet logger per node.
or
B: All of A plus as a full Lora server (Accepting join requests as you mentioned, decrypt frmPayloads
and all that)

That also makes sense what you are saying. I was just basing it on the behaviour of the other suppliers gateway where an Unconfirmed Data Up is sent not expecting ACK as shown below

and the server “replies” with a TxParamSetupReq MAC Command in an Uncofirmed Data Down message

but you are right I should not be expecting anything back from the server. As a side note I manually decrypted the payload and the result was what I expected so no issues there. However I had to do this using an external application, hence why in my previous point I am asking if this is possible on the match server or should that be done externally?

The node is a commercially available Oyster-Lora 915 GPS. There is no real way to check its activity as it joins but I feel its something to do with the RF and/or timing settings of either the node or the match gateway.

This is a screenshot of the Oysters parameters as reference

And the current config file on the matchbox.

Blockquote{
“SX1301_conf”: {
“lorawan_public”: true,
“clksrc”: 1, /* radio_1 provides clock to concentrator /
“lbt_cfg”: {
“enable”: true,
“rssi_target”: -81, /
dBm /
“chan_cfg”:[ /
8 channels maximum /
{ “freq_hz”: 923300000, “scan_time_us”: 5000 },
{ “freq_hz”: 923900000, “scan_time_us”: 5000 },
{ “freq_hz”: 924500000, “scan_time_us”: 5000 },
{ “freq_hz”: 925100000, “scan_time_us”: 5000 },
{ “freq_hz”: 925700000, “scan_time_us”: 5000 },
{ “freq_hz”: 926300000, “scan_time_us”: 5000 },
{ “freq_hz”: 926900000, “scan_time_us”: 5000 },
{ “freq_hz”: 927500000, “scan_time_us”: 5000 }
],
“sx127x_rssi_offset”: -7 /
dB /
},
“antenna_gain”: 2, /
antenna gain, in dBi /
“radio_0”: {
“enable”: true,
“type”: “SX1257”,
“freq”: 917200000,
“rssi_offset”: -166.0,
“tx_enable”: true,
“tx_freq_min”: 915000000,
“tx_freq_max”: 928000000
},
“radio_1”: {
“enable”: true,
“type”: “SX1257”,
“freq”: 917900000,
“rssi_offset”: -166.0,
“tx_enable”: false
},
“chan_multiSF_0”: {
“desc”: “Lora MAC, 125kHz, all SF, 916.8 MHz”,
“enable”: true,
“radio”: 0,
“if”: -400000
},
“chan_multiSF_1”: {
“desc”: “Lora MAC, 125kHz, all SF, 917.0 MHz”,
“enable”: true,
“radio”: 0,
“if”: -200000
},
“chan_multiSF_2”: {
“desc”: “Lora MAC, 125kHz, all SF, 917.2 MHz”,
“enable”: true,
“radio”: 0,
“if”: 0
},
“chan_multiSF_3”: {
“desc”: “Lora MAC, 125kHz, all SF, 917.4 MHz”,
“enable”: true,
“radio”: 0,
“if”: 200000
},
“chan_multiSF_4”: {
“desc”: “Lora MAC, 125kHz, all SF, 917.6 MHz”,
“enable”: true,
“radio”: 1,
“if”: -300000
},
“chan_multiSF_5”: {
“desc”: “Lora MAC, 125kHz, all SF, 917.8 MHz”,
“enable”: true,
“radio”: 1,
“if”: -100000
},
“chan_multiSF_6”: {
“desc”: “Lora MAC, 125kHz, all SF, 918.0 MHz”,
“enable”: true,
“radio”: 1,
“if”: 100000
},
“chan_multiSF_7”: {
“desc”: “Lora MAC, 125kHz, all SF, 918.2 MHz”,
“enable”: true,
“radio”: 1,
“if”: 300000
},
“chan_Lora_std”: {
“desc”: “Lora MAC, 500kHz, SF8, 917.5 MHz”,
“enable”: true,
“radio”: 0,
“if”: 300000,
“bandwidth”: 500000,
“spread_factor”: 8
},
“chan_FSK”: {
“desc”: “FSK disabled”,
“enable”: false
},
“tx_lut_0”: {
/
TX gain table, index 0 /
“pa_gain”: 0,
“mix_gain”: 8,
“rf_power”: -6,
“dig_gain”: 3
},
“tx_lut_1”: {
/
TX gain table, index 1 /
“pa_gain”: 0,
“mix_gain”: 10,
“rf_power”: -3,
“dig_gain”: 3
},
“tx_lut_2”: {
/
TX gain table, index 2 /
“pa_gain”: 0,
“mix_gain”: 9,
“rf_power”: 0,
“dig_gain”: 0
},
“tx_lut_3”: {
/
TX gain table, index 3 /
“pa_gain”: 0,
“mix_gain”: 12,
“rf_power”: 2,
“dig_gain”: 0
},
“tx_lut_4”: {
/
TX gain table, index 4 /
“pa_gain”: 1,
“mix_gain”: 8,
“rf_power”: 5,
“dig_gain”: 2
},
“tx_lut_5”: {
/
TX gain table, index 5 /
“pa_gain”: 1,
“mix_gain”: 9,
“rf_power”: 11,
“dig_gain”: 0
},
“tx_lut_6”: {
/
TX gain table, index 6 /
“pa_gain”: 1,
“mix_gain”: 11,
“rf_power”: 12,
“dig_gain”: 2
},
“tx_lut_7”: {
/
TX gain table, index 7 /
“pa_gain”: 1,
“mix_gain”: 11,
“rf_power”: 13,
“dig_gain”: 1
},
“tx_lut_8”: {
/
TX gain table, index 8 /
“pa_gain”: 1,
“mix_gain”: 11,
“rf_power”: 14,
“dig_gain”: 0
},
“tx_lut_9”: {
/
TX gain table, index 9 /
“pa_gain”: 1,
“mix_gain”: 12,
“rf_power”: 16,
“dig_gain”: 1
},
“tx_lut_10”: {
/
TX gain table, index 10 /
“pa_gain”: 2,
“mix_gain”: 8,
“rf_power”: 18,
“dig_gain”: 0
},
“tx_lut_11”: {
/
TX gain table, index 11 /
“pa_gain”: 2,
“mix_gain”: 12,
“rf_power”: 20,
“dig_gain”: 2
},
“tx_lut_12”: {
/
TX gain table, index 12 /
“pa_gain”: 2,
“mix_gain”: 14,
“rf_power”: 23,
“dig_gain”: 2
},
“tx_lut_13”: {
/
TX gain table, index 13 /
“pa_gain”: 2,
“mix_gain”: 15,
“rf_power”: 25,
“dig_gain”: 0
},
“tx_lut_14”: {
/
TX gain table, index 14 /
“pa_gain”: 3,
“mix_gain”: 11,
“rf_power”: 26,
“dig_gain”: 3
},
“tx_lut_15”: {
/
TX gain table, index 15 /
“pa_gain”: 3,
“mix_gain”: 13,
“rf_power”: 28,
“dig_gain”: 0
}
},
“gateway_conf”: {
/
change with default server address/ports, or overwrite in local_conf.json /
“server_address”: “aux.matchx.io”,
“serv_port_up”: 1700,
“serv_port_down”: 1700,
/
adjust the following parameters for your network /
“keepalive_interval”: 10,
“stat_interval”: 30,
“push_timeout_ms”: 100,
/
forward only valid packets /
“forward_crc_valid”: true,
“forward_crc_error”: false,
“forward_crc_disabled”: false,
/
GPS configuration /
“gps_tty_path”: “/dev/ttyS1”,
/
GPS reference coordinates */
“ref_latitude”: 0.0,
“ref_longitude”: 0.0,
“ref_altitude”: 0
}
}

Once again this might be pretty basic LoRa knowledge and apologies if the questions seem out of the ordinary but any further direction for resolving the OTAA issue would be appreciated.

Hi @piotr,

I think I’ve realised what went wrong. The config file I attached in the previous post is not the right one, I was using another file where I modified the LUT entry to match the other gateway’s parameters.

“tx_lut_15”: {
/* TX gain table, index 15 */
“pa_gain”: 3,
“mix_gain”: 14,
“rf_power”: 27,
“dig_gain”: 0
}

The correct one was the one that the matchbox gateway came with.

So as a lesson learned and reference for future users DO NOT edit the lut tables unless you need to and know what you are doing. What happened was that the matchx server tells the gateway the transmit power as highlighted below

The gateway will then look for the LUT entry to match the rf_power
rf_power (dBm) = power (dBm) - antenna_gain (dBd)

Using the server parameters:

30 (Server Tx power in dBm) - 2 (Antenna gain in dBd) = 28 (rf_power in dBm)

There should be a LUT entry that the gateway can see and matches the rf_power required as per the default config file below:

  "tx_lut_15": {/* TX gain table, index 15 */
  	"pa_gain": 3,
  	"mix_gain": 13,
  	"rf_power": 28,
  	"dig_gain": 0
  }

By me editing “tx_lut_15” to have “rf_power”: 27, the gateway will never send the downlink packet and therefore the packet will be lost.