WisBlock GPS does not accept join TTN

Issue: I am working with WisBlock kit 2, in AU915, the node sends Join Request and the gateway Join Accept, however, the node seems not to accept it. In Application data, only activations are seen. Other nodes from other brands are connected to the gateway and working normally.
Setup: Wisblock kit 2, Gateway Pygate - Pycom.
Server: TTN
Details:


I am attentive, thank you.

Hello,

Are you using one of the WisBlock examples or your own code?

If you are using your own code, can you give me the parameters used in the lora_param_init structure?

/**@brief Structure containing LoRaWan parameters, needed for lmh_init()
 * 
 * Set structure members to
 * LORAWAN_ADR_ON or LORAWAN_ADR_OFF to enable or disable adaptive data rate
 * LORAWAN_DEFAULT_DATARATE OR DR_0 ... DR_5 for default data rate or specific data rate selection
 * LORAWAN_PUBLIC_NETWORK or LORAWAN_PRIVATE_NETWORK to select the use of a public or private network
 * JOINREQ_NBTRIALS or a specific number to set the number of trials to join the network
 * LORAWAN_DEFAULT_TX_POWER or a specific number to set the TX power used
 * LORAWAN_DUTYCYCLE_ON or LORAWAN_DUTYCYCLE_OFF to enable or disable duty cycles
 *                   Please note that ETSI mandates duty cycled transmissions. 
 */
static lmh_param_t lora_param_init = {LORAWAN_ADR_OFF, DR_3, LORAWAN_PUBLIC_NETWORK, JOINREQ_NBTRIALS, TX_POWER_15, LORAWAN_DUTYCYCLE_OFF};

Specially the JOINREQ_NBTRIALS value.
On the LoRaWAN server, do you see additional join requests coming from the node?

Hi,

Thanks for your answer, I am using the GPS_Tracker example. NBTRIALS = 3 in example, but on the gateway I only see a join attempt and the response from the gateway. The init data is:

bool doOTAA = true;
#define SCHED_MAX_EVENT_DATA_SIZE APP_TIMER_SCHED_EVENT_DATA_SIZE /**< Maximum size of scheduler events. */
#define SCHED_QUEUE_SIZE 60  /**< Maximum number of events in the scheduler queue. */
#define LORAWAN_DATERATE DR_0 /*LoRaMac datarates definition, from DR_0 to DR_5*/
#define LORAWAN_TX_POWER TX_POWER_5 /*LoRaMac tx power definition, from TX_POWER_0 to TX_POWER_15*/
#define JOINREQ_NBTRIALS 3 /**< Number of trials for the join request. */
DeviceClass_t gCurrentClass = CLASS_A; /* class definition*/
lmh_confirm gCurrentConfirm = LMH_UNCONFIRMED_MSG; /* confirm/unconfirm packet definition*/
uint8_t gAppPort = LORAWAN_APP_PORT;   /* data port*/

What is the WisBlock log output on Serial saying?
Does it say it joined? Can you send me the log?

Which of the examples are you using?

For GPS data, the data rate DR0 is not applicable. It allows only small data packages. It is better to use #define LORAWAN_DATERATE DR_3

Hi,

WisBlock say:
14:36:38.101 -> =====================================
14:36:38.101 -> Welcome to RAK4630 LoRaWan!!!
14:36:38.101 -> Type: OTAA
14:36:38.101 -> Region: AU915
14:36:38.101 -> =====================================
14:36:38.101 -> Sensor at 0x18 started.
14:36:38.101 -> gps uart init ok!
14:36:38.101 -> [OTAA ]
14:36:38.101 -> DevEui=88-88-88-88-88-88-33-33
14:36:38.101 -> DevAdd=00000000
14:36:38.101 -> AppEui=B8-27-EB-FF-FE-39-00-00
14:36:38.101 -> AppKey=88-88-88-88-88-88-88-88-88-88-88-88-88-88-33-33
14:36:38.145 -> [FREQ ] REGION_AU915

It does not say that it is joined, however the gateway responds with accept

This is the example: https://github.com/RAKWireless/WisBlock/tree/master/examples/solutions/GPS_Tracker

Change to DR_3 but still not working.

I tried to replicate your problem, but I was not able to do so.

However, I stumbled about a potential problem. You are using AU915 region with TTN.
According to this website TTN uses subband 2 (channels 8 - 15) in AU915.

Can you try to change the example code (in setup() function) like below:

// Setup the EUIs and Keys
	lmh_setDevEui(nodeDeviceEUI);
	lmh_setAppEui(nodeAppEUI);
	lmh_setAppKey(nodeAppKey);

	// Initialize LoRaWan
	err_code = lmh_init(&lora_callbacks, lora_param_init, doOTAA);

	lmh_setSubBandChannels(2);

The function lmh_setSubBandChannels(2); would force the SX126x library to use channels 8 to 15.

Hi,

I made the change and it continues without accepting the join. The Join request is in AU915 subbands https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html (917.2 - 917.4) and the gateway responds in AU915 downlink bands as well (923.3). It is possible that on this frequency will not receive the Wisblock ?. Has anyone made OTA with this module in AU915 ?. I am attentive, thank you and thank you for the help.

If the join request is making it to the network server (as it is) then whatever the issue is, it’s not the sub-band.

Typically (or at least ideally) when a node firmware makes a join request, it should give some debug output to indicate if a join accept was or wasn’t received, and if received, if applied.

Can you try another example like the LoRaWAN-OTAA?

Hello,

Thanks for the help again, the OTAA raw “Hello” had also tried it with the same result. Knowing that I have access to the gateway I reconfigured it and tried it on US915, I readjusted the example and it works, I’m not sure what the error is on AU915, if you want we can try to continue debugging it.

I will ask our software team if they tested the examples on AU915. I am doing some changes on the SX126x library to be able to get more debug output. I hope that helps to find the problem.

Not want to push the responsibility to the gateway, but

This post on PyCom is recent just 6 days old.

1 Like

That’s not really a post about gateways, but about node and network behavior.

LoRaWAN gateways have essentially no participation in the protocol, they just transparently move messages between the air and the Internet backhaul.

Additionally it happens that the gateway the person in that thread is using is a Multitech, not a pygate. The pycom involvement is the node firmware, and the only time a pygate entered into the thread is that it’s what the pycom moderator who responded to the user’s problem was using for their own working reference setup.


One thing it may be interesting to note is that in Juan’s shown TTN console excerpt, the join accept is being sent in RX2 and not RX1. TTN does seem to use RX2 a lot, so any challenges unique to that could be exposed here.

In an ideal world, one would have both a log from the gateway’s packet forwarder component indicating that it made the requested transmission, and a log from the node firmware indicating that it opened an RX2 window to try to receive it.