cancel
Showing results for 
Search instead for 
Did you mean: 

[STM32 + LoRaWAN] Join requests issue

Waneock
Associate

Hello guys,

I'm new in LoRaWAN so if my question is dumb - sorry guys. 

Context:
Initial info:

  • custom board with STM32WLE5CCUX family MCU on it;
  • LoRa gateway from P-NUCLEO-LRWAN3 pack;
  • private network gateway;
  • activation type OTAA;

What is done:

  • gateway from P-NUCLEO-LRWAN3 has been configured on TTN;
  • End Node is configured on TTN (no problem with traffic monitoring: uplinks/downlinks);

I'm having some problems with Join requests to private network gateway. When I'm connecting through gateway from P-NUCLEO-LRWAN3 pack which is in the same room as end node everything works perfectly. But when I'm trying to connect to private network gateway something goes wrong (I have configured different DevEUI for local/private gateways and when I want to switch between them I just change DevEUI). Sometimes End Node is connected after 20 minutes, sometimes after 1h the end node is still not connected to the private network gateway.

I know that network coverage is very bad, but other devices somehow connects (up to 30 mins) but connects.

Join Procedure:

  • Duty cycle is enabled (LoRaWAN-EU868 region);
  • I send first 6 join requests with a recurrence of 1 min, after that increase the recurrence to remain compliant with duty cycle restrictions;
  • After each join request I'm waiting for OnJoinRequest event. In case when join fails (joinParams->Status != LORAMAC_HANDLER_SUCCESS)  go to standby mode, until the next join request must be transmitted.

Question:
What can be done to fix that? I thinking to disable duty cycle until end node is not joined but this is not the best solution.

P.S The application was started from End Node skeleton. 

1 ACCEPTED SOLUTION

Accepted Solutions
Waneock
Associate

Problem Solved

Cause of the Problem:
As I mentioned in the original post, the application was started from the End Node Skeleton. The Tx Rfo Config from radio_board_if was set to CONF_RFO_LP_HP. This means the TX Radio Output Frequency is assigned dynamically based on power level:

When power ≤ 15 dBm, the Low Power Radio Output Frequency (RFO_LP) is used.

When power > 15 dBm, the High Power Radio Output Frequency (RFO_HP) is used.

RFO_LP is suitable for short distance communication, while RFO_HP is better for long distances.
According to the EU868 region, the transmission power is limited to 14 dBm. As a result, the application was always using RFO_LP. This was sufficient for communication with the local gateway (which is close to the end device), but not enough to reach the private network gateway.

After changing the configuration parameter to CONF_RFO_HP, everything worked correctly.

How the problem was caught:
I checked the SNR and RSSI values of the uplinks to the local gateway. These values were abnormal and resembled those expected from a long distance transmission, even though the actual distance between the end node and the gateway was only a few meters.

View solution in original post

1 REPLY 1
Waneock
Associate

Problem Solved

Cause of the Problem:
As I mentioned in the original post, the application was started from the End Node Skeleton. The Tx Rfo Config from radio_board_if was set to CONF_RFO_LP_HP. This means the TX Radio Output Frequency is assigned dynamically based on power level:

When power ≤ 15 dBm, the Low Power Radio Output Frequency (RFO_LP) is used.

When power > 15 dBm, the High Power Radio Output Frequency (RFO_HP) is used.

RFO_LP is suitable for short distance communication, while RFO_HP is better for long distances.
According to the EU868 region, the transmission power is limited to 14 dBm. As a result, the application was always using RFO_LP. This was sufficient for communication with the local gateway (which is close to the end device), but not enough to reach the private network gateway.

After changing the configuration parameter to CONF_RFO_HP, everything worked correctly.

How the problem was caught:
I checked the SNR and RSSI values of the uplinks to the local gateway. These values were abnormal and resembled those expected from a long distance transmission, even though the actual distance between the end node and the gateway was only a few meters.