LoRaWAN over AT commands driver implementation #59300
Replies: 2 comments 1 reply
-
Hi Loic, You can use the UART AT parser in driver/modem to make your Lora driver. A Lora driver API is provided AFAIK, but I don't know about Lorawan (based on loramac-node) so surely related to Semtech ICs. Edit: if your module brings his own Lorawan stack, the second option seems better from my point of view.
|
Beta Was this translation helpful? Give feedback.
-
I am in a similar boat. I'm writing an nRF52840 firmware application using NCS 2.6.0 for a Bluetooth LE USB dongle application that supports concurrent LE connections. I too am looking for a full featured AT library (not just parser) for Zephyr. I'd rather not re-invent the wheel and thought to myself, "this has to exist and I can't be the first one looking for something like this for BLE dongles." Any advice is greatly appreciated! |
Beta Was this translation helpful? Give feedback.
-
Hello,
I am migrating an existing code running on the previous Nordic's nRF5 SDK, switching to the nRFConnect SDK x Zephyr, to benefits from its great RTOS features and open-source community. I will be more than happy to start contributing to Zephyr.
In my current project on the nRF5 SDK, I am using a Murata Type ABZ module, that is running an open source AT command server.
I've already written some kind of generic driver for sending and receiving at-commands.
I've also written an additional layer, using my AT generic drive, for the Type ABZ firmware, so that I can easily control the LoRa module's functionalities easily. This includes joining, sending packets, receiving packets, etc.
I would like to integrate this on my Zephyr-migrated project.
However, I don't know exactly what's the right way to do it. I am a bit lost in the architecture of Zephyr, especially how I can integrate my above mentioned work, by adjusting it to Zephyr.
Regarding LoRa and LoRaWAN
A few things I've understood so far (maybe I am wrong) :
However, it seems that these are built in such a way that there is no abstraction between the implementation of, let's say, a join request on OTAA and its implementation. In my case, the join request called from the app should be translated in an AT command such as
AT+JOIN
. In the Zephyr's LoRaWAN library, the packets are built, then sent to a LoRa PHY.Therefore, my main issue with these above-mentioned assumptions is that I have no way to integrate my AT-command-driven module using the existing exposed API for LoRaWAN. Obviously that would be cool when possible, because applications could use LoRaWAN API regardless of the underlying system (whether it's an actual SX-something module on the board or an AT-command module over UART).
Regarding AT commands
There is something called the AT command parser in the nRFConnect SDK. However, I also don't find it really useful as it's only parsing AT commands. However, it's also practical when the AT library can create/build AT commands, format them, and provide timing-checks for timeouts, error parsing, events parsing, etc.
My library I wrote does the above in not-so-clean-but-working way.
I don't want to spend a lot of time on refactoring it, but it could be a start to implement something into Zephyr, as I feel this might be really useful when integrating AT-command-driven modules.
The actual question
Here are some ideas I have now (and thus, steps I might do), ordered by complexity (I may be wrong, don't hesitate to correct me) :
Now, as I am almost certain I may have missed something, can you guide me to the correct way to achieve my goals in the best way ?
Thanks a lot for your time. No need for long answers, just pointers !
Beta Was this translation helpful? Give feedback.
All reactions