A bit off-topic, but I would like to reply on this particular point: the “semtech stack” is not more or less dead, the last release came out 22 days ago. Or maybe you mean the semtech-loramac package in RIOT ? Well, I’m still maintaining it as it is and it works. Several regions are supported, I use it my course, it’s now also used in the Mooc. But yes it needs some update and I know its drawbacks. Someone in the community willing to give a hand ? You could start by having a look at this 2 years old PR.
Regarding the in-house RIOT gnrc_lorawan implementation, I always thought it was a bad idea from the start to integrate it directly into RIOT rather than provide it as an external package (and I shared this thought with @jia200x, so this is not a surprise).
Imagine if this stack was portable and usable on more than a single OS. Let’s imagine one second if the communities from FreeRTOS or Zephyr (that are way larger now than the RIOT one) could also use it. This stack would have certainly gained more external contributions, more features (regions) and wouldn’t be maintained by a one or two people (just think of the bus factor). Maybe this stack could also be promoted by the LoRa Alliance.
Regarding the semtech-loramac, yes I did not notice many updates in RIOT stack maybe its because the upstream is maintained by Semtech hence there is very little we can do within RIOT, I guess. My "more or less dead " comment was because of non-maintained features like this LoRaWAN FUOTA . I have noticed the same with some ST packages as well. So far most of OS stacks based on Semtech works for basic lorawan communication , anything more and things get frustrating
Semtech stack in RIOT works well for sure, I have been using it for some time. In fact, I use it as a reference while making changes to gnrc_lorawan stack. Now I believe the gnrc_lorawan stack has progressed much and shortly in the upcoming releases it shall offer features offered by Semtech stack in addition being thread-safe. It would have been nice to have it portable but I don’t have much idea about how feasible it is at this point in time.
I think we can discuss this offline / on a new thread as I don’t want to make the current thread digress from the main theme.
I agree that discussing this a new thread would be better (but not offline as it might be of interest for others).
Is there a moderator around to move the lorawan related posts (1, 2, this one) in a new thread ?
Done. Hope the title is alright. Since I am not following this discussion too closelcy I wasn’t sure. BTW you can notify all moderators by mentioning @moderators . Otherwise, your request might get lost.
That’s a bit a short guess. Updating the package would allow to do that because more recent versions include the missing features for broadcasting and other stuff I don’t remember.
Do you know that Zephyr is using it ? And also Micropython.
By default LoRaWAN is a mac stack, so yes you can do basic communication and that’s what users want.
What is anything more ? IPv6 ? That might be doable by pluging that Mac stack into netif (I PRed that in the past but never finished).
This sounds good. Just a comment: Semtech stack is indeed not thread-safe but the integration in RIOT isolate it in it’s own thread, so the integration in RIOT is real-time.
What do you mean with portable ? Isn’t the integration into RIOT not portable (given the fact that you have an SX127x radio). I think people are using it on several ARM based boards as well as ESP32.
Or maybe you are talking of the portability limitation of gnrc_lorawan. That’s for sure a big problem. But it could be solved by moving it in its own repo and integrate as a package into RIOT, as I said before. Just don’t release it with LGPL (if you want to get some users).
Anyway, any help in maintaining the loramac-node package or updating it would be greatly appreciated. It’s not very funny to maintain alone such a thing.
By default LoRaWAN is a mac stack, so yes you can do basic communication and that’s what users want.
IMO this really depends on the use case. For research and education
that’s definitely not enough. For more complex use cases (e.g async
sending/receiving, very low power mode, highly constrained devices), I
think it’s also not ideal.
Therefore we decided to go with GNRC LoRaWAN in order to tackle
these problems.
Or maybe you are talking of the portability limitation of gnrc_lorawan. That’s for sure a big problem. But it could be solved by moving it in its own repo and integrate as a package into RIOT, as I said before. Just don’t release it with LGPL (if you want to get some users).
I think @akshaim is talking about the fact it’s not a pkg.
IMO although it would be nice to have a wider community maintained pkg,
I don’t see where’s the “big problem” you describe here. In fact, it’s not the
first in-house stack we have, right?
Anyway, any help in maintaining the loramac-node package or updating it would be greatly appreciated. It’s not very funny to maintain alone such a thing.
I can try to allocate more time for maintaining the loramac-node pkg. It
would be also appreciated if more people could help maintainining our
“in-house” LoRaWAN implementation, considering is one of the 2 official
in RIOT.
I think the current port in RIOT can do that as well.
I’m not talking about a big problem. I said “bad idea”. That also applies to other in-house stack. Who else can use GNRC other than RIOT ? This is a quite limited audience unfortunately.
I think the current port in RIOT can do that as well.
Probably, but you will need extra threads or synchronize carefully the
send and recv functions. My point was, this is just to show a use
case where I think GNRC LoRaWAN would fit better.
I’m using it for education and it’s enough TBH.
Have you ever tried modifying the Semtech MAC to e.g try new MAC
policies? Or force certain situations? I’m pretty sure the “reference
implementation” was not designed with that in mind.
To me it feels this is turning into a Semtech LoRaMAC vs GNRC
LoRaWAN, which I don’t understand and don’t see how it relates to the
fact it’s not a pkg.
As said, there are different use cases and motivations behind
it and don’t see a problem of having 2 LoRaWAN implementations (we have
3 IP implementations and still there’s a good use case for each one).
I’m not talking about a big problem. I said “bad idea”.
This is what I understood from:
That’s for sure a big problem.
That also applies to other in-house stack. Who else can use GNRC other than RIOT ? This is a quite limited audience unfortunately.
Having everything as a pkg doesn’t come for free IMO. Specially in a
core component of an OS. It’s not easy to
design interfaces for all systems in order to make a pkg actually
usable. There are several cross layer optimizations that are very hard
to do if it’s a pkg and testing becomes much more complex.
I guess there are reasons why is not uncommon that almost every OS has
it’s own network stack .
Also, I think it was agreed within the community to go for LGPL. If this
represents an issue for our realistic users, then I don’t see the point of
having all this maintainance burdance if potentially it wouldn’t
increase in practice the number of users.
I think @akshaim is talking about the fact it’s not a pkg. IMO although it would be nice to have a wider community maintained pkg, I don’t see where’s the “big problem” you describe here. In fact, it’s not the first in-house stack we have, right?
I agree that it it works well with FIT-IoT lab. Switching to GNRC_LoRaWAN may not make real sense at least for now as Semtech PKG will work for almost all the cases when TTN is being used.
But when it comes to Chirpstack/ ones own NS things get complicated. Implementing additional feature set on the Semtech stack is something many have attempted and later moved on. The startups I have associated with ended up using a standalone radio module that does all communication related to LoRaWAN.
IMHO both can coexist. Semtech pkg works no matter what as it’s not really that tight on timings and errors hence ideal for remote test beds, first time users, industry etc. GNRC LoRaWAN is strict in timings and error rates, which makes it hard to do high data rates like DR5 ( AFAIK this will fixed soon) but at the same time allows one to customize ( even add new FOpts/ MAC features) hence a good fit for academia.
To me this was not a point of discussion. Both have been coexisting
for quite some time and we shouldn’t need to decide for one or the
other. As said above, this should be picked by the user.
Semtech pkg works no matter what as it’s not really that tight on timings and errors hence ideal for remote test beds, first time users, industry etc. GNRC LoRaWAN is strict in timings and error rates, which makes it hard to do high data rates like DR5 ( AFAIK this will fixed soon) but at the same time allows one to customize ( even add new FOpts/ MAC features) hence a good fit for academia.
Note this is not a problem of the stack but rather of the timer backend
and configuration (some boards had the internal RC timers as default).
In fact, there’s already a PR that adds ztimer,
which solves this issue.
. Otherwise, your request might get lost.