Uplink channel not found

[DylanGWork]

Hi all,

We are trying to use this library for OTAA with TTI (Same settings as TTN) V3 and having trouble understanding why we are getting Uplink channel not found during the join process. We are on the Australian frequencies and using Sub-Band 2 as per the setup in TTI/TTN.
The end nodes work on 8 channel OEM gateways with no issues and no apparent difference other the the frequency being 916799987 instead of 916800000.

This issue appears to be identical to this here:
https://www.thethingsnetwork.org/forum/t/v3-drop-join-request-uplink-channel-not-found/38712/6

Which is also using this library so I'm surprised I don't see this issue raised yet (unless I somehow missed it?).

I have developed the end device so I have complete control and understand the expectations required on the end-node end.

Has anyone experienced this issue before?

Cheers,
Dylan

[Westiewombat]

I have had no luck with OTA either TTN v2 or v3 (AU) or Chirpstack (Home hosted)
ABP works just fine.
Saying that I haven't ruled out my device so could be gateway or device (pro mini 3.3v)

[IoTThinks]

I believe OTAA needs at least two frequencies.

ABP should be ok for this single channel gateway.

[den3y]

I am encountering the exact same problem along with Chirpstack.
In the meantime I found out that this issue must be related to the following lines of code:
In the file _txrx.ino in line 657 the following is executed:
ftoa((double)freqs[gwayConfig.ch].upFreq / 1000000, cfreq, 6); // XXX This can be done better
and it seems like that here some precision is lost when calling the function "ftoa" that is defined in _utils.ino.

[den3y]

I finally found the solution: The pull request from @tfuk did the trick.
I simply updated the _utils.ino and _txrx.ino accordingly and it worked fine.

https://github.com/things4u/ESP-1ch-Gateway/pull/100/commits

[cstratton]

You are mistaken; there can be no software solution to the actual problem, because the hardware is simply not capable of doing the job of a gateway. LoRaWAN requires that a gateway simultaneously monitor 42 frequency and spreading factor combinations, but this device can only monitor one. When you try to use this, you create a misleading situation where a gateway exists for only one combination, but does not exist for any of the other combinations that a proper LoRaWAN node is not just allowed, but actually required to make use of.

This completely screws up the ADR algorithm for settings spreading factor, and the fair channel selection algorithm required not only by the LoRaWAN spec, but actually by law.

Worse, when you do this on a public network, your mess things up for other people's nodes, even if you're not noticing the problem on you own nodes that you may have rigged to violate the LoRaWAN spec and radio laws, but only using a single frequency and spreading factor.

TTN absolutely prohibits connection of these devices - not because they have software bugs, but because they can never do the job of LoRaWAN gateways.

[errolt]

@cstratton Please stop copy/pasting that response on every issue.
A proper gateway needs to monitor 8 frequencies, not 42, of which only 3 are mandatory, ie the join frequencies.
The single channel gateway DOES support OTA, as the first listen window is the same as the TX frequency.
No, I'm not connecting to TTN, I'm running a local Chirpstack server, so I don't care about TTN's policy, which seems to be trying to sell their routers.
This project DOES seem to have issues with OTA, but OTA works fine on https://github.com/JaapBraam/LoRaWanGateway connected to my Chirpstack server.

[cstratton]

@errolt you are demonstrating that you do not understand the technical issue.

LoRaWAN uses not only multiple frequencies, but multiple spreading factors on each frequency - eg in the US SF7-10 (4) and in Europe SF7-SF12 (6)

What I specifically said was "42 frequency and spreading factor combinations" - eg 4-6 spreading factors on each of 8 frequencies, plus two dedicated channels.

Even if you're in a region with only 3 join channels and not 8, you still need to monitor multiple spreading factors on each
A "single channel" device can only monitor one spreading factor on one frequency.

You'd need something like 12-15 of these boards to properly cover 3 join channels.

Accusing TTN of trying to sell hardware is just silly - nobody uses their's, it was just a placeholder. But they are serious about using proper LoRaWAN gateways built around proper multi-channel multi-SF concentrator chips - from any vendor, including DIY.

If you're going to use this hack on your own private Chirpstack network, that's partially better, though

• you need to be very careful that you're not violating airtime regulations, which is drastically limiting if you only have one frequency's airtime allotment
• it needs to not be misrepresented as fit for a purpose where it is not. The many posts where people try to misapply this hack are why the explanation of what's wrong with it keeps needing to be reposted

[errolt]

@cstratton This project can handle ALL the spreading factors, but only on one frequency.
I saw it receive multiple SF on the web interface hosted on the ESP32.
See

ESP-1ch-Gateway/src/configGway.h

Line 124 in 3b02352

// This function will scan for valid LoRa headers and determine the Spreading

So, no, you would need 3 boards, not 21-15.

Yes, the chip can only decode 1 SF, but the code does tricks to scan all the spreading factors to see if any decode.

BTW, I saw the 3 mandatory frequencies in code somewhere, but they match with these, for EU868, and it is the three channels that my node tries to use to join:
https://www.rfwireless-world.com/Terminology/LoRaWAN-Europe-Frequency-Bands-and-Channels.html

[cstratton]

This project can handle ALL the spreading factors, but only on one frequency.

That's simply false.

The radio chip itself can only receive one spreading factor at a time - read the data sheet!

In contrast, a proper LoRaWAN concentrator chip receives not only 8 frequencies, but at least SF7-SF12 on each frequency.

Radios made for end devices (nodes) which this hack software tries to use as a gateway simply can't do that.

It's a hardware limitation.

the code does tricks to scan all the spreading factors to see if any decode.the code does tricks to scan all the spreading factors to see if any decode.

That introduces an overwhelming chance of missing packets - unlike a proper gateway radio, it can only be monitoring one of them at a time.

[errolt]

I guess I have done more source code reading in the last few days:

ESP-1ch-Gateway/src/_stateMachine.ino

Line 405 in 3b02352

// S_CAD: In CAD mode we scan every SF for high RSSI until we have a DETECT.

I have seen a clearer explanation elsewhere:
The code waits for high RSSI.
It tries to receive the first symbol on lowest SF.
If that doesn't work then the radio missed 2 symbols of the lowest SF, but only one symbol at the next higher SF
So it tries to receive the second symbol at the higher SF. If it works then it receives the packet, if it doesn't work then it lost 2 symbols at current SF, but only 1 at higher SF, so switch to higher SF and try to receive next symbol. ETC.

In other words, IN ONE PACKET, it cycles through all the SFs to try and receive the packet.

Yes, a proper gateway is better, but this attitude of "No, you need a $100 - $500 gateway to start experimenting with Lora" is going to be the death of the protocol.

And locally, only gateways I can find is the Kickstarter TTN gateway($150), which is locked to TTN, and some MOKO gateway($300) with very little info. Everything else, like MicroTek wAP LR8 is out of stock. So, I'm not running a single channel gateway because I LIKE the issues that comes with it, I DON'T HAVE MUCH CHOICE.

[cstratton]

The code waits for high RSSI.
It tries to receive the first symbol on lowest SF.
If that doesn't work then the radio missed 2 symbols of the lowest SF, but only one symbol at the next higher SF

It tries, but that's nowhere near as reliable as the hardware in a proper concentrator chip

Seems like your mistake may be in looking at full gateway products, rather than for LoRaWAN concentrator cards you can hang off a pi or more robust embedded system of your choice. Those have typically been fairly available, though yeah, the Helium bros have been snarfing them up at times.

If you are going to try this hack for supporting multiple SF's it might be smart to spend a little airtime lengthening the preamble transmitted by the end device.

But stepping back, there's a much bigger picture concern. If you're no longer implementing LoRaWAN "by the book" why waste all that airtime on LoRaWAN's global shared network assumptions?

It's not just that LoRaWAN assumes any asymetric radio system with a concentrator that can receive on multiple channels and and multiple SF's in a truly parallel manner.

LoRaWAN as a protocol is also absurdly heavy with overhead - it's trying to solve a global-scale problem. If you're only doing some little private local experiment why are you wasting such an absurd amount of airtime on unecessary LoRaWAN headers? and pedantic MAC command exchanges

There are appropriate ways to use node-type radios for point to point LoRa communication - see the various mesh network schemes, Sidewalk, etc.

When you're talking from one node type radio to another, the protocol overhead and mismatched design assumptions of LoRaWAN make a silly choice.

LoRa the modulation makes sense for that use case. But LoRaWAN the heavyweight protocol, does not.