The Helium Gateway application is a service designed to run on Linux-based LoRaWAN gateways.
It's intended to run alongside a typical LoRa packet forwarder and to connect via Semtech's Gateway Messaging Protocol (GWMP, using JSON v1 or v2).
In turn, the Helium Gateway application does two things:
- Periodically sends and witnesses Proof of Coverage beacons, which are reported to the Proof of Coverage ingest oracles
- connects and routes packets to the Helium Packet Router
+-----------+
+-----------+ +------------+ | Ingest |
| | | |<--- gRPC ---->| Service |
| packet |<--- Semtech GWMP ---->| Helium | +-----------+
| forwarder | over UDP | Gateway | +-----------+
| | | |<--- gRPC ---->| Helium |
+-----------+ +------------+ | Router |
+-----------+
NOTE: A DIY Helium Gateway based hotspot is eligible for data rewards only. Proof of coverage rewards are only possible for approved maker hotspots.
The project builds binary compressed tar
release files which are named
after the crypto module used and the CPU architecture they were built for. For example, helium-gateway-1.0.0-aarch64-unknown-linux-gnu.tar.gz contains the
helium_gateway executable with ecc608 support and its setttings.toml
configuration file.
For versions using the ecc608, the crypto module name is not included in the
file name. For TPM variants it is included, for example,
helium-gateway-1.0.0-x86_64-tpm-debian-gnu.tar.gz
Releases are tagged using semantic versioning with a
major.minor.patch form. An alpha/beta release tag may also be issued for early
feature/bug development and testing. Makers are not required to pick up
alpha/beta releases.
This application requires a Linux-based environment for the following reasons:
tokio: thegateway-rsapplication, written in Rust, depends on Tokio for its runtime. Tokio binds to Linux interfaces such asepollandkqeueue. It is technically possible to port Tokio to another OS or RTOS (this has been done for Windows), but it would be no simple undertaking.
If your supported LoRa gateway did not come with helium-gateway pre-installed, manual installation requires you to:
-
Configure the packet forwarder on the gateway to forward to the helium-gateway application. This varies per gateway but the goal is to set the packet forwarder to forward to the (default) configured helium-gateway on
127.0.0.1at udp port1680 -
Set up ssh acccess to the gateway. Depending on the gateway that may require going through a web interface, while others already have ssh configured.
-
scpa downloaded and uncompressed release package for the supported platform to the gateway. e.g.scp helium_gateway settings.toml <gateway>:/tmp/
-
sshinto the device and copy the application and configuaration into a suitable location using a command like:mkdir /etc/helium_gateway mv /tmp/settings.toml /etc/helium_gateway/ mv /tmp/helium_gateway /usr/bin/
-
Configure the logging method to use by updating the
settings.tomlfile's[log]section with the logging method to use based on your system. Supported values arestdioorsyslog. Note you may need to configure thesyslogservice on your device to accept the logs. -
Configure the region if required. The default region of the gateway is set to
UNKNOWN, and fetched based on the asserted location of the gateway. Setting the region to a known region or caching the last fetched region and using theGW_REGIONenvironment variable on startup will allow the gateway to use the correct region for uplinks immediately, while the region parameters are retrieved.The supported region values are listed in the region protobuf definition.
NOTE: Due to TX power regulations, the gateway location needs to be asserted on the blockchain to be able to send downlinks.
-
Start the service by either starting it manually or hooking it into the
init.d,systemd, or equivalent system services for your platform. Consult your platform/linux on how best to do this.The startup command for the application is as follows. Note you will need to adjust the path to
helium_gatewayor the path to the settings file to use for the-coption./usr/bin/helium_gateway -c /etc/helium_gateway/settings.toml server
If this command succeeds the logs on the gateway will show the service starting and the local packet forwarder client connecting to the gateway service.
The following targets are being built. Adding a new target involves creating a pull request against this repository with the right cpu target tuple.
- Review the open issues to see if it's already in progress. If not, file an issue. Note that new targets are developed and supported by Helium makers and Community members.
- Join the
#gateway-developmentchannel on Helium Discord and work the the community to add target support.
Note that platforms will be tested much faster if you join the development process!
| Target | Products |
|---|---|
| mipsel-unknown-linux-musl | ✅ CalDigit Light Hotspot |
| ✅ ClodPi Light Hotspot ClodPi | |
| ✅ RAK833 EVB Kit | |
| ✅ RAK7258 (WisGate Edge Lite) | |
| ❔ RAK7249 (WisGate Edge Max) | |
| ✅ RAK7240 (WisGate Edge Prime) | |
| ✅ Smart Harvest Instruments Light Gateway | |
| mips-unknown-linux-musl | ✅ Dragino LPS8 |
| ❔ Dragino DLOS8 | |
| aarch64-unknown-linux-gnu | ✅ Cotx gateways cotx |
| ✅ Raspberry Pi 3 or 4 running Raspian / Raspberry Pi OS 64 bit or another 64 bit Debian-based Linux distro | |
| arm-unknown-linux-gnueabihf | ✅ Raspberry Pi 0 or 1 running Raspian / Raspberry Pi OS or another Debian-based Linux distro |
| armv5te-unknown-linux-musleabi | ✅ CloudGate |
| ✅ Multitech Conduit MTCDT (mLinux) | |
| armv7-unknown-linux-musleabihf | ✅ Kerlink Wirnet iFemtoCell Evolution |
| armv7-unknown-linux-gnueabihf | ✅ ResIOT X gateways resiot |
| ✅ Raspberry Pi 2, 3, or 4 running Raspian / Raspberry Pi OS or another Debian-based Linux distro | |
| ✅ Kona Micro IoT Gateway | |
| ✅ Kona Enterprise IoT Gateway | |
| ✅ RisingHF RHF2S027 Light Hotspot | |
| x86_64-unknown-linux-gnu | ✅ Debian x86_64 (ecc608) |
| ✅ LongAP | |
| x86_64-tpm-debian-gnu | ✅ Debian x86_64 (tpm) |
| ✅ FreedomFi gateway |
Use one of the existing releases if you can, or build your own by hand using the instructions below.
If you want to support a new target, please consider submitting a PR to get the target as part of the supported matrix of gateway platforms!
-
Install
rustcurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
-
Install cargo
cross. Thecrosscommand allows for cross-compiling to hardware targets using a docker image.cargo install cross
-
Build the application binary using the target triplet/profile from the supported targets. Note that debug builds may be to large to run on some targets.
cross build --profile <target> --release build
The resulting application binary is located in
target/<target>/release/helium_gatewayNOTE The target triplet and profile may not be the same. For example, the
x86_64-tpm-debian-gnuprofile uses thex86_64-unknown-linux-gnutarget
The Helium Gateway application can be configured to suit your hardware/software
environment in a variety of ways - either from the command line or customizations to the settings.toml file or with environment variables. The
following sections describe this functionality in more detail as well as more
general information on how to use the application.
The Helium Gateway application is configured using a TOML settings file. The
released settings file can be found in the
settings.toml
file in this repo. Edit this file with specifics for your target platform and
store it either at the default expected
location/etc/helium_gateway/settings.tomlor at a custom location of your
choosing. If you store the file in a non-default location you will need to pass
the-cflag to thehelium_gateway application as shown below in the general
usage section.
If your gateway is enabled with an ECC608 crypto chip which is set up correctly, you can configure helium_gateway to use the crypto chip for secure key storage and crypto operations.
To use in your settings.toml override the keypair setting to reflect the use
of the ECC and specify the bus address and slot to use. For example:
keypair = "ecc://i2c-1:96?slot=0&network=mainnet"
will have helium_gateway use the ECC at the /dev/i2c-1 device driver location,
use bus address 96 (which is hex 0x60), and slot 0 for its crypto
operations. While marking the resulting key as a mainnet key. Bus address, slot
and network are all optional parameters and default to the above values (only
device driver location is required such as ecc://i2c-1).
Note that the file-based keypair will no longer be used once the ECC is configured for use.
See the gateway-mfr-rs repo for instructions on configuring, locking, and testing an ECC chip.
It is expected that most gateways will use the same key slot for the onboarding key and the keypair, however, this key is also configurable in the same way as the keypair:
onboarding = "ecc://i2c-1:96?slot=0"
The original helium miners use an onboarding key on slot 15:
onboarding = "ecc://i2c-1:96?slot=15"
Instead of editing parameters in the
settings.toml
file as described above, you can also use environment variables. The environment
variable name will be the same name as the entries in the settings file in
uppercase and prefixed with "GW_". For example, following on from the above
example where we change the region using region = "EU868" in the settings
file, setting an environment variable of GW_REGION="EU868" will override the
region setting. If the settings are in one of the lower sections such as the
[log] section then you need to also include that in the environment variable
name such as GW_LOG_LEVEL.
The settings are loaded first from the settings.toml file, and then from
environment variables and any duplicates are overridden in the order. Therefore,
please note that if you have a setting in both locations, the environment
variable will override the settings in the other two locations.
Using the Helium Gateway application is pretty simple, and the vast majority of
the information you will need to use it can be gleaned by using the --help
flag which provides the following output:
Helium Light Gateway
USAGE:
helium_gateway [FLAGS] [OPTIONS] <SUBCOMMAND>
FLAGS:
--daemon Daemonize the application
-h, --help Prints help information
-V, --version Prints version information
OPTIONS:
-c <config> Configuration file to use [default: /etc/helium_gateway/settings.toml]
SUBCOMMANDS:
add Construct an add gateway transaction for this gateway
help Prints this message or the help of the given subcommand(s)
info Info command. Retrieve all or a subset of information from the running service
key Commands on gateway keys
server Run the gateway service
As you can see, apart from the help command, there are four core subcommands
that you can pass: add, key, server. The descriptions of what these
subcommands do is shown in brief in the above help output, and are explained in
more detail in the sections below.
The only option available is the config option using the -c flag. This tells
the application where your configuration file is located and can be used as
follows whilst passing any of the other commands such as server or add
(default is /etc/helium_gateway/settings.toml):
./helium_gateway -c /location/of/config/file server
Lastly you can check the version, read the help information, or daemonize the
application using the --version, --help and --daemon flags respectively.
As shown in the help output below, this subcommand is used to construct an add gateway transaction which can subsequently be used with the Helium Wallet application to onboard the gateway to the blockchain. More information on this process can be found on the docs article for Data Only Hotspots.
Construct an add gateway transaction for this gateway
USAGE:
helium_gateway add [OPTIONS] --owner <owner> --payer <payer>
FLAGS:
-h, --help Prints help information
-V, --version Prints version information
OPTIONS:
--mode <mode> The staking mode for adding the light gateway [default: dataonly]
--owner <owner> The target owner account of this gateway
--payer <payer> The account that will pay account for this addition
So for example, to construct a data-only add gateway transaction you would enter the following command at the terminal:
./helium_gateway add --owner WALLET_ADDRESS --payer WALLET_ADDRESS
You need to substitute WALLET_ADDRESS for the wallet address you will use for
the owner of the hotspot and the payer of the transaction fees
respectively...but please note that the --payer address must be the same as
the one you will use to submit the transaction to the blockchain, or the
transaction will fail.
The output of this command is a JSON object which looks like the following:
{
"address": "11TL62V8NYvSTXmV5CZCjaucskvNR1Fdar1Pg4Hzmzk5tk2JBac",
"fee": 65000,
"mode": "dataonly",
"owner": "14GWyFj9FjLHzoN3aX7Tq7PL6fEg4dfWPY8CrK8b9S5ZrcKDz6S",
"payer": "14GWyFj9FjLHzoN3aX7Tq7PL6fEg4dfWPY8CrK8b9S5ZrcKDz6S",
"staking fee": 1000000,
"txn": "CrkBCiEBrlImpYLbJ0z0hw5b4g9isRyPrgbXs9X+RrJ4pJJc9MkSIQA7yIy7F+9oPYCTmDz+v782GMJ4AC+jM+VfjvUgAHflWSJGMEQCIGfugfLkXv23vJcfwPYjLlMyzYhKp+Rg8B2YKwnsDHaUAiASkdxUO4fdS33D7vyid8Tulizo9SLEL1lduyvda9YVRCohAa5SJqWC2ydM9IcOW+IPYrEcj64G17PV/kayeKSSXPTJOMCEPUDo+wM="
}You can also pass a --mode flag followed by the hotspot type (dataonly | light | full) as shown below:
./helium_gateway add --owner WALLET_ADDRESS --payer WALLET_ADDRESS --mode light
The output of this command will be mostly the same as if you used the default
dataonly however you will see that the mode has changed to "mode": "light",
and the staking fee amount has changed to "staking fee": 4000000.
The txn field from the JSON object needs to be used as the input to the wallet
command helium-wallet hotspot add when you subsequently want to add it to the
blockchain. For example, using the above JSON object as an example, you would
use the following command:
helium-wallet hotspots add CrkBCiEBrlImpYLbJ0z0hw5b4g9isRyPrgbXs9X+RrJ4pJJc9MkSIQA7yIy7F+9oPYCTmDz+v782GMJ4AC+jM+VfjvUgAHflWSJGMEQCIGfugfLkXv23vJcfwPYjLlMyzYhKp+Rg8B2YKwnsDHaUAiASkdxUO4fdS33D7vyid8Tulizo9SLEL1lduyvda9YVRCohAa5SJqWC2ydM9IcOW+IPYrEcj64G17PV/kayeKSSXPTJOMCEPUDo+wM=
This subcommand can be used to get the address and animal name of the gateway from the keys file as shown in the help output below. Note that the helium_gateway server has to be running for this command to work.
Commands on gateway keys
USAGE:
helium_gateway key <SUBCOMMAND>
FLAGS:
-h, --help Prints help information
-V, --version Prints version information
SUBCOMMANDS:
help Prints this message or the help of the given subcommand(s)
info Commands on gateway keys
Using this is as simple as passing the following command in a terminal from
wherever you installed the helium_gateway application:
./helium_gateway key info
The output of this is a JSON object containing the address and animal name of the hotspot as shown below:
{
"address": "11TL62V8NYvSTXmV5CZCjaucskvNR1Fdar1Pg4Hzmzk5tk2JBac",
"name": "wide-neon-kestrel"
}The gateway server subcommand is used to start the gateway service on your device.
Run the gateway service
USAGE:
helium_gateway server
FLAGS:
-h, --help Prints help information
-V, --version Prints version information
Running it is as simple as:
./helium_gateway server
However as discussed above you can also pass the -c option to tell the service that you are using a different location for your config files:
./helium_gateway -c /location/of/config/file server
There is a wealth of further information on maker hotspot software on the Helium Docs site including information about the gRPC API that allows you to interact with the gateway via the maker app and other services over gRPC rather than via the command line options described above.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent