LoRa gateway

Buzzverse gateway is an advanced LoRa base station designed for long-range wireless communication using LoRa modulation. It supports multiple LoRa modems, enabling simultaneous handling of multiple communication channels. Tailored for IoT applications, it facilitates secure and efficient data exchange between devices and external services through encryption and MQTT protocol. With its modular architecture and flexibility, it's an ideal solution for research projects, environmental monitoring, smart cities, and more.

Features

• Multi-LoRa Modem Support: Ability to use different LoRa modems.
• Bi-directional LoRa Communication: Supports both receiving and transmitting data using LoRa modulation.
• Data Encryption: Ensures the security of transmitted information.
• External Services Integration: Ability to communicate with external services using the MQTT protocol and others.
• HTTP API: Allows easy integration with external applications through a REST API.
• Embedded Devices Compatibility: Optimized for devices such as BeagleBone, Raspberry Pi, and dedicated hardware solutions.
• Modern C++20: Utilizes advanced features of C++20 for better performance and code readability.

Usage

Build and run the standalone target - for Beaglebone

Building the software for Beaglebone require pointing of the toolchain cmake file. Also binnary that is created for other platform will statically link glibc to avoid compatibility problems.

Use the following command to build the executable for the Beaglebone.

cmake -S standalone -B build-beaglebone -DCMAKE_TOOLCHAIN_FILE=../cmake/toolchain-beaglebone.cmake
cmake --build build-beaglebone

To copy the binary to the Beaglebone, please use the scp command:

scp build-beaglebone/lora_gateway debian@192.168.7.2:/home/debian

Build and run the standalone target - for host

Use the following command to build and run the executable target.

cmake -S standalone -B build/standalone
cmake --build build/standalone
./build/standalone/gateway --help

Build and run test suite

Use the following commands from the project's root directory to run the test suite.

cmake -S test -B build/test
cmake --build build/test
CTEST_OUTPUT_ON_FAILURE=1 cmake --build build/test --target test

# or simply call the executable: 
./build/test/lora_gateway

To collect code coverage information, run CMake with the -DENABLE_TEST_COVERAGE=1 option.

Run clang-format

Use the following commands from the project's root directory to check and fix C++ and CMake source style. This requires clang-format, cmake-format and pyyaml to be installed on the current system.

cmake -S test -B build/test

# view changes
cmake --build build/test --target format

# apply changes
cmake --build build/test --target fix-format

See Format.cmake for details. These dependencies can be easily installed using pip.

pip install clang-format==14.0.6 cmake_format==0.6.11 pyyaml

Build the documentation

To manually build documentation, call the following command.

cmake -S documentation -B build/doc
cmake --build build/doc --target GenerateDocs
# view the docs
open build/doc/doxygen/html/index.html

To build the documentation locally, you will need Doxygen, jinja2 and Pygments installed on your system.

Build everything at once

The project also includes an all directory that allows building all targets at the same time. This is useful during development, as it exposes all subprojects to your IDE and avoids redundant builds of the library.

cmake -S all -B build
cmake --build build

# run tests
./build/test/GatewayTests
# format code
cmake --build build --target fix-format
# run standalone
./build/standalone/Gateway --help
# build docs
cmake --build build --target GenerateDocs

Additional tools

The test and standalone subprojects include the tools.cmake file which is used to import additional tools on-demand through CMake configuration arguments. The following are currently supported.

Sanitizers

Sanitizers can be enabled by configuring CMake with -DUSE_SANITIZER=<Address | Memory | MemoryWithOrigins | Undefined | Thread | Leak | 'Address;Undefined'>.

Static Analyzers

Static Analyzers can be enabled by setting -DUSE_STATIC_ANALYZER=<clang-tidy | iwyu | cppcheck>, or a combination of those in quotation marks, separated by semicolons. By default, analyzers will automatically find configuration files such as .clang-format. Additional arguments can be passed to the analyzers by setting the CLANG_TIDY_ARGS, IWYU_ARGS or CPPCHECK_ARGS variables.

Ccache

Ccache can be enabled by configuring with -DUSE_CCACHE=<ON | OFF>.

FAQ

Can I build the standalone and tests at the same time? / How can I tell my IDE about all subprojects?

To keep the template modular, all subprojects derived from the library have been separated into their own CMake modules. This approach makes it trivial for third-party projects to re-use the projects library code. To allow IDEs to see the full scope of the project, the template includes the all directory that will create a single build for all subprojects. Use this as the main directory for best IDE support.

I see you are using GLOB to add source files in CMakeLists.txt. Isn't that evil?

Glob is considered bad because any changes to the source file structure might not be automatically caught by CMake's builders and you will need to manually invoke CMake on changes. We are using the GLOB solution for its simplicity.

I want create additional targets that depend on my library. Should I modify the main CMakeLists to include them?

Avoid including derived projects from the libraries CMakeLists (even though it is a common sight in the C++ world), as this effectively inverts the dependency tree and makes the build system hard to reason about. Instead, create a new directory or project with a CMakeLists that adds the library as a dependency (e.g. like the standalone directory). Depending type it might make sense move these components into a separate repositories and reference a specific commit or version of the library. This has the advantage that individual libraries and components can be improved and updated independently.

You recommend to add external dependencies using CPM.cmake. Will this force users of my library to use CPM.cmake as well?

CPM.cmake should be invisible to library users as it's a self-contained CMake Script. If problems do arise, users can always opt-out by defining the CMake or env variable CPM_USE_LOCAL_PACKAGES, which will override all calls to CPMAddPackage with the according find_package call. This should also enable users to use the project with their favorite external C++ dependency manager, such as vcpkg or Conan.

Can I configure and build my project offline?

No internet connection is required for building the project, however when using CPM missing dependencies are downloaded at configure time. To avoid redundant downloads, it's highly recommended to set a CPM.cmake cache directory, e.g.: export CPM_SOURCE_CACHE=$HOME/.cache/CPM. This will enable shallow clones and allow offline configurations dependencies are already available in the cache.

Related projects

• ModernCppStarter by TheLartians: This template was used to create the current project. Give them a star ;)