Regarding future plans for LoRaWAN Class B/C support

[ChangYanChu]

Regarding future plans for LoRaWAN Class B/C support, I would like to inquire if there are any developments in this area. Our team has conducted extensive research (through Google and GitHub) but has yet to find existing libraries that natively support Class B or C implementations. This gap significantly impacts several of our applications requiring rapid response capabilities, where implementing Class B or C functionality would be transformative for real-time operations.

Given the numerous user discussions on forums regarding this feature request, and understanding your team's previous indication of potential consideration in future versions, could you clarify if there are technical constraints or specific challenges delaying implementation? We recognize this would require substantial engineering effort, but knowing the conditions under which this functionality might be prioritized would help us align our development roadmap.

As active contributors to open-source projects, we're prepared to collaborate closely with your team. With a fully deployed device ecosystem in CN470 environments, we can provide field testing resources and validation data to accelerate development. Our team is also willing to assist in codebase adaptation or documentation efforts if such collaboration aligns with your development strategy.

Thank you for maintaining this exceptional library, and we look forward to receiving guidance on how we may contribute to advancing this functionality. :)

[StevenCellist]

Hi @ChangYanChu, thank you for the compliments on the RadioLib library.
I see you found topic #905; in that topic I mentioned that fully implementing Class A had the main priority back then. Since then, we've had a few rounds of informal certification testing, which has shown that RadioLib is pretty much fully compliant for Class A using LoRa datarates. Soon, we hope to do another informal round for verifying FSK as well. While I'd love to have an official certification run after that, it costs money that I don't have as a hobbyist. But that roadblock/milestone is pretty much done now.

Supporting Class C isn't particularly difficult in itself, as the existing code can be fully re-used for the additional methods. Supporting Class B is much more challenging as it will require both new code, but also gateways that support sending beacons - I don't have those, they're usually a bit more expensive if I'm not mistaken.

The main roadblock for Class B/C would be my available time. Right now, I'm fully occupied by my job to make enough money to be able to afford my life and moving to my own house which is the main side project now. So if there's a need for your company to be able to use Class B/C in somewhat near/medium future, that would require funding my/our development hours so that I/we can leave some other stuff aside. (As well as looking at a Class B gateway.)

Of course, providing field testing resources and validation data would be useful to debug & verify a solution, but that doesn't take away the required development upfront to get anything useful going. Helping by actually implementing Class B and C could be an option, but LoRaWAN isn't easy and our development strategy isn't particularly focused at supporting your company's needs, rather providing a robust, foolproof stack that is easy to use and supports more than one specific usecase.

If you are willing to fund development or discuss other ways of supporting the project, we can discuss this on a private thread somewhere else than a public topic.

[ChangYanChu]

I have chosen to personally advance the application of LoRaWAN in factory settings. Actually, what other solutions exist in China? The network coverage of NB-IoT and 4G in China is already quite comprehensive. My boss wants to experiment with multiple solutions, so I'm conducting this research using my personal time. I've purchased the HELTEC HT-CT62 module because their library directly supports both Class C and Class B operations. I'm not unwilling to pay for commercial solutions, but I prefer an open-source approach where technology's benefits can be accessible to everyone collectively, rather than being controlled by individuals or single entities.

[HeadBoffin]

There appear to be some contradictions in your previous post: "Regarding our previous discussions, I regret to inform you that after internal negotiations, the company cannot provide financial support for the LoRaWAN project at this stage." plus other plural forms and your reply to me. I'm sure you can imagine how confusing this could be.

Linking "Far Eastern phrases" to assumptions of "commercial exploitation" may inadvertently reinforce cultural divides.

You appear to have misunderstood the sentence construction & thereby, the intent. I quoted a British phrase & said that there may be an equivalent - for instance 'les flatteries ouvrent des portes' or 'la adulación te ayudará mucho' or 'lob kann dich weit bringe' - same idea, slightly different phrasing. I used a British perspective of a situation of lots of flattery followed by asking for something - although I've not found any part of the world where this strategy is not used. This is my perception of a common human trait based on some years of experience working in an international arena.

The HT-CT62, which we use as one of the test modules for RL LW, does have the Heltec library - a very much older Semtech LoRaMac-node v1.0.2 implementation - so its Class C abilities would need validating against the current LNS versions.

If you can live with a few minutes response time and the devices are on power, then you could do an empty uplink at more frequent intervals than would normally be used. The code is pretty modular so having a loop that calls receiveCommon with zero delays and several windows would be a bit hacky but get you through for now.

Alternatively, use an STM32WL module like the Wio-E5 which is the same price as the HT-CT62 with the most recent (but bizarrely now deprecated) LoRaMac-node. If the code is modular you can port it back to RL at a later date. But that's not ESP32 so no WiFi/BLE easily to hand.

[StevenCellist]

Not taking away any valid point that @HeadBoffin makes in the second half of the last comment, I would really like to urge him to be more culturally aware. Having a sister & brother-in-law currently living in Asia, I can say that the European mindset does NOT apply there. There may be sayings in French, German, British, but those are all Western-European countries. And Australia is definitely not Asia.

It took me a complete re-read of @ChangYanChu's message to figure out that he is taking out personal time to work on business projects - things that are very common in countries like China, and are almost crucial for surviving in the (to us Europeans bizarre) corporate environment there. So let us please keep this conversation civil and try to work around the cultural differences from both sides of the globe.

[StevenCellist]

Definitely not available yet, but the basis is there:

09:28:40.431 > RLB_PRO: Downlink (AFCntDown = 4) encoded:
09:28:40.437 > RLB_PRO: 00000000: 49 00 00 00 00 01 1c 0c 0b 26 04 00 00 00 00 0d  I........&......
09:28:40.445 > RLB_PRO: 00000010: 60 1c 0c 0b 26 80 04 00 01 31 c5 6e 33 92 16 97  `...&....1.n3...
09:28:40.451 > RLB_PRO: 00000020: 07                                               .
09:28:40.463 > Received a Class C downlink!
09:28:40.467 > Downlink data:
09:28:40.468 > 00010203
09:28:40.469 > [LoRaWAN] RSSI:          -14.00 dBm
09:28:40.474 > [LoRaWAN] SNR:           10.50 dB
09:28:40.478 > [LoRaWAN] Event information:
09:28:40.481 > [LoRaWAN] Confirmed:     0
09:28:40.482 > [LoRaWAN] Confirming:    0
09:28:40.482 > [LoRaWAN] Datarate:      3
09:28:40.487 > [LoRaWAN] Frequency:     869.525 MHz
09:28:40.490 > [LoRaWAN] Frame count:   4
09:28:40.491 > [LoRaWAN] Port:          1
09:28:40.494 > [LoRaWAN] Time-on-air:   56 ms
09:28:40.495 > [LoRaWAN] Rx window:     3
09:29:05.297 > RLB_PRO: Downlink (AFCntDown = 5) encoded:
09:29:05.300 > RLB_PRO: 00000000: 49 00 00 00 00 01 1c 0c 0b 26 05 00 00 00 00 0d  I........&......
09:29:05.308 > RLB_PRO: 00000010: 60 1c 0c 0b 26 80 05 00 01 d6 43 71 1a 59 da 62  `...&.....Cq.Y.b
09:29:05.316 > RLB_PRO: 00000020: 00                                               .
09:29:05.327 > Received a Class C downlink!
09:29:05.327 > Downlink data:
09:29:05.333 > 04050607
09:29:05.333 > [LoRaWAN] RSSI:          -14.00 dBm
09:29:05.338 > [LoRaWAN] SNR:           10.00 dB
09:29:05.338 > [LoRaWAN] Event information:
09:29:05.345 > [LoRaWAN] Confirmed:     0
09:29:05.347 > [LoRaWAN] Confirming:    0
09:29:05.349 > [LoRaWAN] Datarate:      3
09:29:05.351 > [LoRaWAN] Frequency:     869.525 MHz
09:29:05.352 > [LoRaWAN] Frame count:   5
09:29:05.356 > [LoRaWAN] Port:          1
09:29:05.358 > [LoRaWAN] Time-on-air:   56 ms
09:29:05.361 > [LoRaWAN] Rx window:     3

Notice the lack of uplink in between.. these are sent straight down.

I will not be at the development desk this weekend, so I suggest some patience, it'll likely be a week before there's more news.

[HeadBoffin]

I would really like to urge him to be more culturally aware

You do not know enough about my family & colleagues to make such a statement and ad hominem attacks are always inappropriate. NB, there are many forms of that phrase available in Chinese.