You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am intending to leverage your library for a vehicle sharing IoT device integrated with Helium. I've managed to get the examples operational, but it appears that only Class A functionality is currently supported. If my understanding is correct, Class A requires an uplink transmission before a downlink can be received, which isn't an optimal solution for my use case.
My application requires real-time command transmission to the device, such as initiating lock/unlock operations. This demands a continuous ability to receive downlink messages independent of any preceding uplink transmission.
I understand that Class C, which provides continuous listening for downlinks, is currently not implemented in your library. However, I am interested in knowing if Class B, which according to my research opens the downlink window at regular intervals (e.g., every 10 seconds), is supported or can be implemented. This mode would be more than sufficient for my application requirements.
I appreciate your help and clarification on this matter.
Thanks!
Environment
Version of LMIC being used: latest
Environment: Plattform.io
Network provider: Helium
Region: EU868
Board: TTGO T-Beam v1.1
The text was updated successfully, but these errors were encountered:
Issue #711 (moved to discussion #712) received a developer response about why Class C isn't implemented. That's a bummer, because I was also hopeful to use this library for a Class C device.
Support for Class B is specifically mentioned, although it is mentioned that it hasn't been fully tested.
First, I'm really sorry that I've not been contributing the last year or so - very busy on an unrelated project and running the company. Maybe 2024!
If you search issues, a contributor did class B testing in 2018 or 2019 and reported results and requested some changes. I implemented those changes, and also did some other work as I was reviewing the code base. It is therefore possible that Class B is functional at this point. Test reports from the community would be welcome.
I just received a RWC5020B 64-channel tester, after being without a tester for several months. So we may be able to start doing some work in 2024, as without the RWC5020B I had no way to do proper regression tests.
This is one of the most complicated LoRaWAN libraries for LoRaWAN devices.
A bit disappointed as it doesn't support Class C and unlikely to support Class C easily.
Hello,
I am intending to leverage your library for a vehicle sharing IoT device integrated with Helium. I've managed to get the examples operational, but it appears that only Class A functionality is currently supported. If my understanding is correct, Class A requires an uplink transmission before a downlink can be received, which isn't an optimal solution for my use case.
My application requires real-time command transmission to the device, such as initiating lock/unlock operations. This demands a continuous ability to receive downlink messages independent of any preceding uplink transmission.
I understand that Class C, which provides continuous listening for downlinks, is currently not implemented in your library. However, I am interested in knowing if Class B, which according to my research opens the downlink window at regular intervals (e.g., every 10 seconds), is supported or can be implemented. This mode would be more than sufficient for my application requirements.
I appreciate your help and clarification on this matter.
Thanks!
Environment
The text was updated successfully, but these errors were encountered: