I just checked out that device, and it looks really promising! I’m curious to see the consumption specs.
I’m having a tough time finding example code on the ST website for the LoRaWAN STM32WL part. I’ve gone through the YouTube training doc which gives me high level stuff. It looks like mbed-os supports that chip as well, so maybe I can find something there.
Huge thanks! The API doesn’t look bad aside from the ridiculous amount of initialization code. I’ll have to learn more about the CubeIDE to see how much of this is generated (and how to generate it).
Not really any “generation” needed, the files are all there they just need to be fed to a compiler and linker.
I was able to throw together an alternate build flow by identifying likely files and include paths and adding them bit by bit to resolve each new build error. That was a test for a client project so they not I own it, but it was a fairly rote and reasonable process of sweat equity.
I was looking through the docs and the forum. I’ll have to watch some of the videos later, but man… this thing looks fantastic. Not entirely sure how the over-the-air DFU will work, but I’m sure the videos cover it.
After a few days of messing around with the STM32 environment and watching the GenericNode videos, I am definitely hopeful for this product. I would love to get my hands on one and tinker with it. I requested a device on their forum… fingers crossed
The past week I’ve been looking at this example for the Lora E5 module which has an STM32WLE5JC in it:
Unfortunately this project isn’t a good example as the modifications was hacked in, and regenerating the code from the .ioc file breaks the project. I believe the RAK example is much cleaner, so I will try that one now. Thanks for sharing @jfmateos
Support for the Arduino ecosystem for the STM32WL would be really useful, so a good first start.
There are some serious issues that need addressing for this to be community friendly:
The ReadMe on GitHub says it is set to send a message every minute to TTN and the source code confirms this.
That would be in breach of the Fair Use Policy by quite a margin.
It also appears to have a copy of the Matt Kooijman LMIC embedded in it, so it is hard wired to use an older deprecated copy of LMIC - which is not BasicMac.
It also appears that there are some aspects of LoRaWAN that need clarifying - you do a Join, store the keys, sleep, wake up and then do an ABP send using the keys from the store and every 300 uplinks you do a rejoin.
At minimum the send rate needs altering in both source & in the ReadMe and as it doesn’t use anything like BasicMac, perhaps update it to include the MCCI LMIC - include so that it pulls in the latest version automatically. And drop the Join/ABP/Re-Join sequence.