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.
1 Like
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.
1 Like
There is no such thing at the gateway. Gateways are stupid and just forward LoRaWAN packets received from the air to the backend and transmit packets received from the backend at the specified time.
Does the device attempt to join when the feature is enabled?
Nope, that feature is part of the code base and its implementation depends on that particular code base. Anything I write would be a guess. Look at the code if the documentation isn’t sufficient, that is what I would need to do as well.
Sorry but it seems you are contradicting yourself. In debug mode with JOIN_BACKOFF_SUPPORT set to true, does it join or does it not join?
BTW, given that these questions seem very specifically related to the Microchip code it might be a good idea to try their forum as @descartes suggests. If you find a solution, don’t forget to report back. We’re curious what it might be…
I contacted Microchip and they are going to look for what is wrong. Thanks everybody for the help!
Please report back with the solutions. We’re (ok, maybe just me) curious about the outcome.
Hey Marco, let me help you with this! I spent a few weeks breaking my head on this, and finally understood the issue.
The problem is with the Microchip LoRaWAN stack- MLS versions!
The latest MLS 1.0.5 requires LoRaWAN Core 1.0.4 specs, which TTN is not. So you’ll keep having join issues like crazy here.
You need to chose MLS 1.0.4 or lower, which is compatible with LoRaWAN Core 1.0.2 and lower.
So how do you solve this?
For the application examples given by Microchip, choose Atmel Software Framework ASF 3.48 version and lower, and not the latest ASF 3.49+ versions… You can choose between the versions in the application examples… ASF 3.48 incorporates MLS 1.0.4
Let me know if it helped 