No, our Sentrius RG1xx gateway leverages the RG1xx-M2 Concentrator Card, built with Semtech's SX1301 and SX1257 radios (x2). To fully support TDOA, however, the hardware would need to incorporate the SX1303 chip − or a newer, more advanced solution. TDOA (Time Difference of Arrival) is a method in LoRaWAN used to estimate a device's location by measuring the slight time differences in its signal reaching multiple gateways, using ChirpStack and/or the Semtech LoRa Cloud, for example.

Simply put, each LoRaWAN gateway picks up the signal at slightly different times, and these time differences are used to calculate the device's position. For this to work, a LoRa end-device and multiple gateways with synchronized clocks are required. TDOA is especially useful in places where GPS does not work well, such as indoors, in urban environments with tall buildings, or areas with limited GPS signal.

By eliminating the need for GPS hardware on the device, this geolocation technique lowers overall power consumption while enabling efficient, long-range tracking. However, accuracy depends on the precise synchronization of the gateways' clocks and can be affected by multiple environmental factors like signal interference. It's a common choice for asset tracking, logistics, and smart city projects.

There are a lot of messages related to LoRa, Wi-Fi, remote management and etc in debug window. Depending on the area of interest, you can filter messages with a string to display messages you want see only.  

For example, if you are interested in looking at different types of LoRaWAN messages, filter with "msgtype" or your packet type to see if join request has been sent and uplink/downlink messages are sent/received as expected. In the below example, jreq is join request, dnmsg is downlink message and updf is uplink message.

• RG1xx2A32B0 lora user.notice May 17 11:06:59 2024-05-17 11:06:56.001 [AIO:XDEB] [3|WS] > {"msgtype":"jreq","MHdr":0,"JoinEUI":"F9-C6-0E-CE-A3-AD-C6-BD","DevEUI":"00-25-CA-0A-00-01-59-FA","DevNonce":31818,"MIC":-1175426342,"RefTime":1715944018.869189,"DR":4,"Freq":904600000,"upinfo":{"rctx":0,"xtime":281477270906114,"gpstime":0,"fts":-1,"rssi":-42,"snr":10.75,"rxtime":1715944016.001405}} 

• 
  

• RG1xx2A32B0 lora user.notice May 17 11:06:52 2024-05-17 11:06:49.255 [AIO:XDEB] [3|WS] < {"msgtype":"dnmsg","DevEui":"00-00-00-00-00-00-00-00","regionid":1000,"dnmode":"updn","dC":0,"diid":17102,"pdu":"6065835201a0030060b9465b","priority":1,"RxDelay":1,"RX1DR":13,"RX1Freq":927500000,"xtime":281477263724260,"rctx":0,"MuxTime":1715944012.126807} 

• 
  

• RG1xx2A32B0 lora user.notice May 17 11:06:52 2024-05-17 11:06:48.811 [AIO:XDEB] [3|WS] > {"msgtype":"updf","MHdr":128,"DevAddr":22184805,"FCtrl":130,"FCnt":3,"FOpts":"0307","FPort":1,"FRMPayload":"8646EF419D90BB76CBA6C4","MIC":-1912354618,"RefTime":1715944011.682198,"DR":3,"Freq":905300000,"upinfo":{"rctx":0,"xtime":281477263724260,"gpstime":0,"fts":-1,"rssi":-11,"snr":7.5,"rxtime":1715944008.811094}} 

No, it was supported one time in old version but that feature has been taken out in later version. 

Let's take these messages as an example.

SGSN='12085978.mmecE4.mmegiFF09.mme.epc.mnc410.mcc310.3gppnetwork.org' 

 SGSN='120631.mmec5f.mmegi8004.mme.epc.mnc260.mcc310.3gppnetwork.org', 

The physical network providers are identified by their MNC and MCC codes. The MCC is the mobile country code. In this case it’s in the US so all physical networks in the US have an MCC of 310 . In the logs when the network deletes the PDP context and hands over the cellular connection to another tower with a different provider. You can see the MNC value switch between 260 and 410 which corresponds to ATT and T-Mobile. In each case because the PDP context was also deleted by the network the handover also caused the modem to re-attach which you can see from the network log that it did. Handovers in good signal strength areas usually make sense if a device is moving. 

RM1xx-M.2 is a peripheral hardware, and all the software should be running in your host (as like BT stack is running on host) and the integration process should be dependent on what packet forwarder you want to use. Refer to integration guide from a network server of your choice for more details regarding this. 

You would also need the underlying libloragw library (basically the HAL layer) which is available in https://github.com/Lora-net/lora_gateway.

No, RG1xx-LTE requires CAT 1 SIM card.

The value shown for LTE in RG1xx-LTE UI corresponds to dBm in the following table: 

While it is generally safe to have the RM126x module and the gateway in close proximity during LoRaWAN communication, it is advisable to maintain a few meters of distance between any LoRaWAN end devices and the gateway. This helps ensure optimal performance and avoids potential issues related to signal interference.

Unfortunately, this is currently not supported and physical access to the unit(s) would be required. You cannot factory reset a RG1xx gateway through the web UI or by using the TR-069 protocol remotely. See here for general instructions and information on this process.

All Ezurio LoRa products should be referred as LoRaWAN as they all supports its protocol. LoRaWAN protocol make use of LoRa Chirp Spectrum Modulation within a license-free sub-gigahertz frequency band that allow to transmit regularly small packets up to 15km. 

It’s important to consider that 15km can only be achieved within absolute best conditions, some of which would be an outdoor “line of sight” transmission, interference free environment, ideal humidity/temperature, highest Spreading Factor, ect… Such range magnitude cannot represent any “real world” distance transmission and shouldn’t be expected by default.

Let's break down the LoRaWAN classes for a clearer understanding:

Class A: Energy-efficient, with uplink transmissions followed by sporadic downlink listening for incoming messages, suitable for low-power devices.

Class B: Features scheduled receive windows in addition to Class A behavior, offering a balance between energy efficiency and predictable downlink communication times.

Class C: Maintains an open receive window, allowing near-continuous downlink reception for immediate responses, but consumes more power compared to Class A and B.

For more in-depth information on LoRaWAN classes, you can refer to:

https://www.thethingsnetwork.org/docs/lorawan/classes/

Now, let's talk about RG1xx's LoRaWAN support:

• The RG1xx fully supports LoRaWAN v1.0.2.
•  The LoRaWAN v1.0.3 introduces full support for unicast and multicast class B devices. The sections regarding class A and class C remain unchanged from LoRaWAN v1.0.2, except for the addition of a new MAC command called "DeviceTimeRequest," which is used to synchronize a device's real-time clock. If your devices operate in class A or class C, there is no need to upgrade to LoRaWAN v1.0.3. However, if you plan to use class B, it is recommended to utilize LoRaWAN v1.0.3.

Considering this information, it's important to note that our RG1xx supports LoRaWAN v1.0.3 for Class A and C, but it does not support Class B due to the absence of a GPS onboard module in the gateway.

No, RG1xx connectes to ACS and checks in see if it has any waiting directives. If not, it disconnects. 

You can load a specific version of firmware by using the following URL with replacement of <ga_version> with the actual GA release version. The GA version can be found in release notes.  

https://connectivity-firmware.s3.amazonaws.com/rg1xx-lora-gateway/firmware/<ga_version>/fw.txt

For example, GA6.2 is desired firmware to be downgraded to, the URL should be the following: 

https://connectivity-firmware.s3.amazonaws.com/rg1xx-lora-gateway/firmware/GA6.2/fw.txt

RG1xx uses ntpd (Network Time Protocol Daemon) to synchronize the clock by exchanging messages with external time server. 

If you are using the remote management through Laird account of AVSystem, the default check-in time is 300 seconds. This can be changed under Settings > Remote Management Service in the RG1xx web UI. 

As per RG191 User Guide/Datasheet the absolute maximum supply voltage for the RG1XX is recommended to be 12V. While some components may be able to tolerate higher voltages, the entire system is designed to operate optimally at 12V. Deviating a little from this value is possible, but it is essential to be cautious about power dissipation and other potential implications which may damage the components of the gateway. Hence using higher supply voltage is not recommended and it will also void the warranty.

A factory reset on the RG1xx gateway can be used to reset all settings to their default values − at any time. This process restores the original "factory" condition of your RG1xx gateway. It is recommended for troubleshooting purposes or for users who no longer have access to the web UI. Please note that a factory reset is irreversible, therefore there is no way to recover your previous configuration. It is also required to reconfigure your RG1xx gateway once the factory reset has been completed. If possible, we advise developers and system integrators to back up their existing settings before continuing.

Please follow the instructions in our latest Sentrius RG1xx / RG191+LTE User Guide under section 9.8 (Factory Reset). If this approach does not work for you, try the following:

First remove the power supply from your RG1xx gateway completely for at least 10 seconds. Press and hold down the User Button. Do not release the User Button. Now restore the power supply while the User Button is still pressed. Wait until all LEDs start flashing. Release the User Button and observe the LEDs while the RG1xx gateway is performing the factory reset in the background. This usually does not take longer than 3 minutes and your RG1xx gateway might restart automatically afterwards. Do not remove the power supply while the LEDs are flashing. This means that the factory reset is still in progress.

Unfortunately, there is currently no built-in driver or software support to utilize any Bluetooth Classic / Bluetooth Low Energy (BLE) features. For this reason, the Bluetooth radio is completely disabled and cannot be used from a user perspective. Please note that from a pure hardware point of view the RG1xx gateway is leveraging our WB50NBT wireless bridge module which is featuring the CSR8811 chipset from Qualcomm (formerly Cambridge Silicon Radio or CSR), so technically proper support for Bluetooth could be implemented at a later stage in the future. However, at this time there no plans to offer a RG1xx gateway with Bluetooth support from our side.

No. Our RG1xx gateways ship with a region lock; each region is using a different power table due to different regulatory reasons and requirements which we must comply with. We do not allow nor support to modify the region settings, so you must purchase the appropriate model for the desired region of operation. If you bought the wrong model for your region, we advise you to get in touch with your seller or distributor and ask for a RMA (Return Merchandise Authorization).

Based on the part number we set the region settings during manufacturing for each RG1xx gateway individually. The only exception here is for the Australian variant where you can toggle between the AU915 and AU923 regions in the web UI. Please find a complete list of all available part numbers with the corresponding regions in our latest Sentrius RG1xx / RG191+LTE User Guide under section 2.3 (Ordering Information).

LoRaWAN version: MAC V1.0.2
Regional Parameters version: PHY V1.0.2 REV B

The access keys used in TTN v2 are not used anymore in TTN v3 the API key is used instead. Follow the below steps to create an API Key for an application from The Things Stack Console.

1. Navigate to your application.
2. Select the API Keys section on the left menu and click the + Add API Key button.
3. Fill in the Name and select the Rights of your API key.
4. Click on the Create API Key button in order to create the API key. This will open the API key information screen.

Note: Please make sure to save your API key at this point because it will no longer be retrievable after you leave the page.

IP stands for Ingress Protection. Its a standard we use to check the sealability of a product once it is installed.

It is composed as IP## , where first digit is for dust/solid objects and the 2nd digit, is for liquids.
Here is the meaning for each numerical code:

No, an RS1xx AS923 sensor will not work with an AU915 gateway because it cannot receive the downlink packets due to differing bandwidth and frequency plans used and therefore will drop off the network.

End-devices do not actually make a connection with a gateway. End-devices broadcast to all gateways within range and the gateway forward packets to a network server if it can hear them. So, a gateway does not have a hard number for supporting devices and it is rather dependent on how much bandwidth a gateway can support. For example, factors such as payload size, interval of each data transmission or data rate being used can affect how much air time is consumed and therefore the gateway processes. Also environment factors should be considered.   

It's normally best to experiment with real devices in actual sites in order to figure out how many devices can transmit data without much data loss, using desired configuration/setup.

If your network servers is installed in Linux machine,
iptables --list shows what ports are allowed. Make sure all the intended ports are included here.

The below is an example of output on a machine that had Chirpstack installed.

root@ip-172-31-17-202:/home/ubuntu/Variants# iptables --list

Chain INPUT (policy DROP)

target prot opt source destination

ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere tcp dpt:1883
ACCEPT tcp -- anywhere anywhere tcp dpt:1884
ACCEPT tcp -- anywhere anywhere tcp dpt:8083
ACCEPT tcp -- anywhere anywhere tcp dpt:8883
ACCEPT udp -- anywhere anywhere udp dpt:1700
ACCEPT tcp -- anywhere anywhere tcp dpt:3001
ACCEPT tcp -- anywhere anywhere tcp dpt:8886
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere


Chain FORWARD (policy ACCEPT)

target prot opt source destination

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

ACCEPT all -- anywhere anywhere

If you have normal RG1xx (non LTE version) and add Ethernet to Cellular bridging capability, you can access to RG1xx UI via port forwarding but with the following requirement

• need to forward whatever external port to internal port 443 to reach the gateway on that bridging device.
• Cellular provider allows incoming connections on that port.

Yes, as long as they are operating on different networks such that AS923 sensors talk to the AS923 gateway and vice versa for AU915 devices. 

Once the RM1xx is put into deep sleep, it can wake up by detecting an external GPIO signal. GpioSetFunc can be used to configure which pin to use in order to wake up from deep sleep.

From the definition of GPIOSETFUNC (nSigNum, nFunction, nSubFunc), when the GPIO pin is configured to DIGITAL_IN (nFunction = DIGITAL_IN), nSubFunc parameter's bit 4 and 5 control when it wakes up the radio.

Bits 4, 5

0x10 When in deep sleep mode, awake when this pin is LOW
0x20 When in deep sleep mode, awake when this pin is HIGH
Else No effect in deep sleep mode

For example, the following line of code sets GPIO pin# 28 to trigger waking up RM1xx from deep sleep when it goes from HIGH to LOW. rc = GpioSetFunc(28,0x01,0x23)

Refer to GpioSetFunc defined in RM1xx BLE Central smartBASIC Extensions Guide v1.1 for more details.

There are a number of low cost hobbiest gateways on the market based on devices such as the Raspberry Pi, paired with a Semtech SX1272/SX1276, normally used in a LoRaWAN node. These low cost gateways often are single channel devices, operating on a single spreading factor. A single channel gateway can miss many of the LoRaWAN messages broadcast. The Laird RG1xx is an 8 channel gateway based on the industry standard Semtech SX1301/SX1257 chipset providing a scaleable solution able to receive on multiple channels/spreading factors at the same time.

LoRaWAN 1.02 spec requires the end-devices to broadcast JoinReq message on Freq 923.2-923.4 Mhz.  The max output power is 14dBm. The end devices can only use SF10BW125 to join the network, which is DR2.

M2 card reset pin is active high and you need to hold the line high for 100ns min after power supply has stabilized

SPI on RG1xx M2 is slave mode only

The Sentrius M2 Card's SPI logic level is at 3.3V.
 

This is an output from a GPS module on the RG1xx. The 1PPS is a standard output from GPS modules. Currently GPS is not supported on the RG1xx.

PIN 71 is an input to the RG191 and is the reset  for the SX1301.

Pin 41 is used to identify the type of M.2 card.

The Connector for the RG1xx Concentrator Card on the Sentrius RG1xx is a standard PCIE M.2 Key connector.
There are various suppliers for these connectors but the Sentrius Gateway uses a Kyocera, Part# 24 6411 067 401 894 E.

Generic ECAD Models can be downloaded from Mouser