Sentrius RG1xx + RS1xx IoT Starter Kit

Unfortunately, this is not possible and intentionally unsupported due to the security risk of losing access to the RS1xx Sensor in the field. This restriction applies to all changes involving packet formats / types, channels, frequencies, data rates, operating modes — both confirmed and unconfirmed— as well as DevEUI, JoinEUI (formerly AppEUI), AppKey, and the backlog feature. These settings are designed to be configured exclusively through the Bluetooth Low Energy (BLE) interface using our Sentrius RS1xx Sensor mobile app, available at https://www.ezurio.com/using-sentrius-rs1xx-sensor-app, for iOS and Android smartphones. This approach is designed and will help ensure a secure and consistent device setup process during the initial commissioning and deployment stages.

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. 

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.

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.

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.

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. 

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).

With the 1-Wire Digital Thermometer Probe, a connection problem at power up is indicated by both LEDs on the front panel being
constantly on. This is a visual indicator to the user that there is a communication issue between the sensor and the probe.

Please check the connector/plug of the external temperature probe for proper connection as well as its cable for mechanical damage.

The latency of the RS1xx Sentrius LoRa sensor with external magnet open/close sensor is limited by the following reasons:

1) The RS1xx uses two internal dwell times to detect a door open and close. These can be set in the Sentrius smartphone app to a minimum of 5 seconds (which is also the default setting). So any state change faster than 5 seconds will be suppressed and a change or the open/close sensor state won't be transmitted faster than 5 seconds.

2) Independent of the dwell time the RS186 (EU868 region) faces a minimum LoRa uplink interval due to regulatory 1% duty cycle limitations of the 868MHz frequency band. At the maximum data rate (SF7BW125) the airtime is roughly 60msec, which then adds a dead time of 99x60msec=5.94sec. So from this we get a minimum cycle time of roughly 6 seconds. At the minimum data rate (SF12BW125) the airtime is roughly 1480msec plus a dead time of 99x1480msec=2.4min giving a minimum cycle time of roughly 2.5min.

So the latency of a door open/close state detection plus transmission for the RS186 would be 6 seconds at best case (maximum LoRa data rate SF7BW125) and 2.5min at worst case (minimum LoRa data rate SF12BW125).

The latency of the RS191 is not limited by duty cycle restrictions and hence end up at 5 seconds latency purely due to dwell time.

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:

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. 

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.

While the standard RS1xx (455-0001 for North America) can support down to -40°C and RS1xx external sensor (455-0070 for North America) can support down to -55 °C, typical AA batteries do not perform well at below -25 °C. Industrial grade of AA batteries may support lower temperature but they are significantly more expensive that off the shelf standard AA batteries.