Hello guys!
I am using WLR089U0 module but it only joined once. I remove the power and connect it again but the device cannot join. I am using OTAA. I tried disabling “Enforce” duty cycle on my gateway side but nothing works.
Here is what gateway console shows to me:
Here is what device console shows:
My device works on North America (902-928 Mhz). Also gateway is configured in NA settings.
I am getting “No Free Channel found” error while debugging.
Any advice?
Thanks!
Gateway console info? Device console information? Any serial output from the module?
Today my car doesn’t start. I let some air out of the tires but it still doesn’t start…
Why do you expect your change makes a difference? Is there a message in the gateway console stating the gateway ran out of air time?
You need to supply significantly more information for us to be able to help.
Do you see join requests in the console gateway traffic? Anything listed in the device traffic in the console?
Hello Kersing!
I added some pics of the gateway and the end-device. I can see join requests on gateway traffic.
Serial output gives me “No Free Channel Found”. I am using a 16-Rx channel gateway (Kona Macro from Tektelic)
Does your device use subband 1?
That means your device is sending join requests too rapidly and needs to wait for the next attempt.
Yes, I also tried with subband 2 and I am getting the same error. I found that the gateway has a lot of CRC fails. And Rx packet error rate: 0.78. Rx packet error rate is decreasing as more packets are received
That typically means that either you’re picking up a lot of traffic from other non-TTN systems, or else your node is too close to the gateway and overloading it.
Posting the actual join requests reports received by the gateway - as text NOT pictures would be helpful.
It looks like you may have an RSSI of -49 which is “shouting in your ear” loud and suggests you may want to move the systems further apart.
Yes, the end-node and gateways are less than 10 meters. I don’t believe that is the problem because when I use Xplained Pro, it joins correctly. Only with the node I developed the problem appears randomly. Suddenly it joins correctly but most of the time not.
Here are the join requests reports.
From “Recieve uplink message”:
{
"name": "gs.up.receive",
"time": "2021-03-23T02:04:34.771347279Z",
"identifiers": [
{
"gateway_ids": {
"gateway_id": "tests-outdoor-2-mya",
"eui": "647FDAFFFE007CEF"
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
"raw_payload": "AAANflANswAHseUBGBklBAA1qxp188Q=",
"payload": {
"m_hdr": {},
"mic": "GnXzxA==",
"join_request_payload": {
"join_eui": "0700B30D507E0D00",
"dev_eui": "000425191801E5B1",
"dev_nonce": "AB35"
}
},
"settings": {
"data_rate": {
"lora": {
"bandwidth": 125000,
"spreading_factor": 10
}
},
"coding_rate": "4/5",
"frequency": "902900000",
"timestamp": 3804152508
},
"rx_metadata": [
{
"gateway_ids": {
"gateway_id": "tests-outdoor-2-mya",
"eui": "647FDAFFFE007CEF"
},
"timestamp": 3804152508,
"rssi": -61,
"channel_rssi": -61,
"snr": 12.8,
"uplink_token": "CiEKHwoTdGVzdHMtb3V0ZG9vci0yLW15YRIIZH/a//4AfO8QvIX7lQ4aDAiymeWCBhCLtuDvAiDg3KLJ2+gC",
"channel_index": 3
}
],
"received_at": "2021-03-23T02:04:34.771234571Z",
"correlation_ids": [
"gs:conn:01F1E1D1JYFK7F0YBBVSQWQZB5",
"gs:uplink:01F1ED76JK9P8EAF3KX6ANA9XK"
]
},
"correlation_ids": [
"gs:conn:01F1E1D1JYFK7F0YBBVSQWQZB5",
"gs:uplink:01F1ED76JK9P8EAF3KX6ANA9XK"
],
"origin": "ip-10-22-15-195.us-west-1.compute.internal",
"context": {
"tenant-id": "CgZtZXhpY28="
},
"visibility": {
"rights": [
"RIGHT_GATEWAY_TRAFFIC_READ"
]
},
"unique_id": "01F1ED76JKN4QMJQAKDDA8SJWK"
}
From forward uplink messange
{
"name": "gs.up.forward",
"time": "2021-03-23T02:04:34.774371737Z",
"identifiers": [
{
"gateway_ids": {
"gateway_id": "tests-outdoor-2-mya",
"eui": "647FDAFFFE007CEF"
}
}
],
"correlation_ids": [
"gs:conn:01F1E1D1JYFK7F0YBBVSQWQZB5",
"gs:up:host:01F1E1D1QH5XK4J0FJKJH4049T",
"gs:uplink:01F1ED76JK9P8EAF3KX6ANA9XK"
],
"origin": "ip-10-22-15-195.us-west-1.compute.internal",
"context": {
"tenant-id": "CgZtZXhpY28="
},
"visibility": {
"rights": [
"RIGHT_GATEWAY_TRAFFIC_READ"
]
},
"unique_id": "01F1ED76JP4YED0AAHR7X90VXW"
}
From forward uplink message 2
{
"name": "gs.up.forward",
"time": "2021-03-23T02:04:34.977096469Z",
"identifiers": [
{
"gateway_ids": {
"gateway_id": "tests-outdoor-2-mya",
"eui": "647FDAFFFE007CEF"
}
}
],
"correlation_ids": [
"gs:conn:01F1E1D1JYFK7F0YBBVSQWQZB5",
"gs:up:host:01F1E1D1QHGFT15RQZ8CS7MPF0",
"gs:uplink:01F1ED76JK9P8EAF3KX6ANA9XK"
],
"origin": "ip-10-22-15-195.us-west-1.compute.internal",
"context": {
"tenant-id": "CgZtZXhpY28="
},
"visibility": {
"rights": [
"RIGHT_GATEWAY_TRAFFIC_READ"
]
},
"unique_id": "01F1ED76S16Z6ZRQFG3Z2EE1MF"
}
From send downlink message
{
"name": "gs.down.send",
"time": "2021-03-23T02:04:36.595758554Z",
"identifiers": [
{
"gateway_ids": {
"gateway_id": "tests-outdoor-2-mya",
"eui": "647FDAFFFE007CEF"
}
}
],
"data": {
"@type": "type.googleapis.com/ttn.lorawan.v3.DownlinkMessage",
"raw_payload": "IILBDLbpxU0zCKCgoar6hsk=",
"scheduled": {
"data_rate": {
"lora": {
"bandwidth": 500000,
"spreading_factor": 10
}
},
"data_rate_index": 10,
"coding_rate": "4/5",
"frequency": "925100000",
"timestamp": 3809152508,
"downlink": {
"tx_power": 28.15,
"invert_polarization": true
}
},
"correlation_ids": [
"gs:conn:01F1E1D1JYFK7F0YBBVSQWQZB5",
"gs:up:host:01F1E1D1QHGFT15RQZ8CS7MPF0",
"gs:uplink:01F1ED76JK9P8EAF3KX6ANA9XK",
"ns:downlink:01F1ED78BJA180ADX43FB6F36H",
"ns:uplink:01F1ED76JNVGJ731A3S5P6T68B",
"rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01F1ED76JN9WCV7CR1YJ0CB83K",
"gs:conn:01F1E1D1JYFK7F0YBBVSQWQZB5",
"rpc:/ttn.lorawan.v3.NsGs/ScheduleDownlink:01F1ED78BKQEPFCZEVX80RKQEK"
]
},
"correlation_ids": [
"gs:conn:01F1E1D1JYFK7F0YBBVSQWQZB5",
"rpc:/ttn.lorawan.v3.NsGs/ScheduleDownlink:01F1ED78BKQEPFCZEVX80RKQEK"
],
"origin": "ip-10-22-15-195.us-west-1.compute.internal",
"context": {
"tenant-id": "CgZtZXhpY28="
},
"visibility": {
"rights": [
"RIGHT_GATEWAY_TRAFFIC_READ"
]
},
"unique_id": "01F1ED78BKK4K7MAXTYYKJ5DVH"
}
From transmit downlink message succesfull
{
"name": "gs.down.tx.success",
"time": "2021-03-23T02:04:39.023718287Z",
"identifiers": [
{
"gateway_ids": {
"gateway_id": "tests-outdoor-2-mya",
"eui": "647FDAFFFE007CEF"
}
}
],
"correlation_ids": [
"gs:conn:01F1E1D1JYFK7F0YBBVSQWQZB5",
"gs:tx_ack:01F1ED7AQF8PV49CCM2JB4Z52J"
],
"origin": "ip-10-22-15-195.us-west-1.compute.internal",
"context": {
"tenant-id": "CgZtZXhpY28="
},
"visibility": {
"rights": [
"RIGHT_GATEWAY_TRAFFIC_READ"
]
},
"unique_id": "01F1ED7AQF05PZ1HQBHD18A5FX"
}If you are asking for help then perhaps it helps if you listen to suggestions from experts. Why ask for help if you ignore them? To difficult to test with more distance?
Distance between gateway and node is an issue that has bitten many users. Your other device(s) might behave differently due to a different antenna.
So they are both likely to be shouting at each other and not processing the RF properly.
That is not a frequency used by TTN in the “North America (902-928 Mhz)” band you said you are trying to use.
To see the actual frequencies used, look at: https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html
Both your gateway and your node will need to be configured to use correct frequencies.
Yes, the end-node and gateways are less than 10 meters. I don’t believe that is the problem because when I use Xplained Pro, it joins correctly. Only with the node I developed the problem appears randomly.
Random success/failure is exactly what would tend to result from overload.
Though of course that is not the only thing that could be causing it.
Might be helpful to look at the LoRaWAN header file settings of the WLR089 project.
At one stage I did a file compare between supplied LoRaWAN libraries and found the new library and code added a random channel feature…except it was coded to 64 random channels, but the gateway only has 8.
LoRa being an RF transmitter design… do you have access to a SDR or spectrum analyzer to prove you are transmitting only on the desired gateway channels?
That’s required by the spec; RF regulations typically require distributing usage over channels too
That’s recommended by the spec its in the general sense it’s not knowable which channels would be in use. The network would then send a channel map indicating which channels are actually supported.
You can pre-optimize the channel map (and for TTN probably should) but it’s an optimization relative to the spec.
MarcoAndrade’s channel problem is more that their gateway is configured to listen on the wrong channels - that needs to be fixed first.
Then the node can either be pre-optimized to use the same channel bank as TTN, or left in the more flexible but less efficient full band randomization until it starts getting through and gets configured.
do you have access to a SDR or spectrum analyzer to prove you are transmitting only on the desired gateway channels?
A connection to capture serial debug output costs a fraction of what a spectrum analyzer does, and gives more information.
Hello! I have been trying to put gateway in different locations and moving far from it but still cannot Join. I changed from TTN to The Things Industries Network Server but I am having the same issue. I tried with FSB 1 and FSB 2.
I am using Kona Macro Gateway and this is the configuration:
Kona Macro hast 16 Rx Channels and 2 Tx
Have you checked your gateway is listening at the frequencies listed in the TTN frequency plan for US915? Next, is you node transmitting at one of the listed frequencies using an allowed SF?
Does the node listen at the right time (join 5 / 6 seconds after transmit) to receive the answer? And does it listen at the right frequency? Check the LoRaWAN specification for the frequencies used for downlink relative to the uplink used.
Yes. I found that when joinBackoffEnable is set to True, it won’t join. But if it is set to False, it joins immediately.
Here I found this:
“Disabled Join back-off in Demo application Needs to be enabled in Production Environment Retransmission back-off mechanism is avoid flooding the network when all the nodes in the network start-up at the same time. Details are given in section 7 of LoraWAN 1.0.2 core specification. This feature is enabled by a macro JOIN_BACKOFF_SUPPORT in FEATURES_SUPPORTED Macro for each band in conf_regparams.h”
Do I need to enable JOIN_BACKOFF_SUPPORT on the gateway side or why the device is not joining when enabling that feature? There are no other LoRaWAN devices near where I am; neither >100 devices as the specification describes. Could you please explain to me more about that feature?
Thanks!
When the “Debug” version is uploaded, the device joins in both scenarios, JOIN_BACKOFF_SUPPORT = true and JOIN_BACKOFF_SUPPORT = false. While JOIN_BACKOFF_SUPPORT is TRUE, suddenly it does not join.
But when it is set to “Release”, it not joins when JOIN_BACKOFF_SUPPORT is TRUE, and when FALSE, it remains trying to join.
It looks like you’ve got a good handle on the issue - you’ll probably need to take it up with Microchip as it will be implemented in the very heart of its code.