Sentrius RM1xx LoRa + BLE Module

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.

Laird RM1xx modules are supplied with smartBASIC and have an integrated LoRaWAN stack.Programming the nRF51 directly would mean the loss of the Laird smartBasic engine, the integrated stack and the RM1xx LoRaWAN certification. Please contact support to discuss this further.

No, the RM1xx can be purchased with either BLE Central role or Peripheral role support but not both. The RM1xx is loaded with either the Nordic S110 peripheral only BLE soft device or the Nordic S120 central only BLE soft device. To support both peripheral and central on the same module we would need to use Nordic's S130 stack, which is not possible when using smart BASIC. Please contact support for more information. 

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. 

LoRaWAN supports two ways for a device connect to the network.

1. OTAA: Over the air activation
2. ABP: Activation by personalization

When using OTAA a join action results in a join request being sent from the RM1xx to the network. The network then checks the Application Identifier (AppEUI) and Application Key (AppKey) provided by the RM1xx. If the APPEUI and APPKey are valid, a join accept message is sent back to the RM1xx which triggers an EVLORAMACJOINED event to be thrown in smart BASIC.

When using ABP there is no handshaking between the RM1xx and the network. As soon as the RM1xx performs a join action it can start sending data. The Application Session Key (AppSKey) and the Network Session Key are set once in both the RM1xx and the network server and must match.

OTAA is the recommended method to join an RM1xx to a LoRaWAN network as it more secure, with the session keys being derived from the APPEUI and APPKey on each connection. Whereas the session keys for ABP remain the same throughout the life of the RM1xx.

What kind of antenna options are available for the RM1xx module and how much do they cost? Will a PCB traced Antenna work? Please reference the certified antenna list in the Datasheet (HIG) for the LoRa/BLE modules.

To get the most range out of the LoRa module it is recommended that an external dipole antenna is used rather than a PCB trace antenna. However, if range is not going to be an issue and none of the approved antennas will work for you application we do offer EMC testing/certification services and could certify any PCB trace antenna you would like through our in-house certifications lab for an additional service fee. As to the cost of the antenna options and/or EMC services, we ask that you contact support or your Regional Sales Representative for that information.

In order to enable the built-in VSP functionality on the DVK-RM1xx, SIO_28 must be tied to VCC. There is a jumper, J6, on the DVK-RM1xx board that brings out SIO_28 but it ties it to GND instead of VCC so some alterations must be made.  Using a red jumper cable, connect J6 pin 1 (SIO_28) to J11 pin 3, VCC_LORA, this enables VSP.  Now, select the nAutorun jumper, J12, depending on which VSP mode is needed: nAutorun (SIO_25) == GND (J12 pins 1-2) puts the module into VSP OTA mode which can be used to download smartBASIC scripts OTA to the module.  nAutorun (SIO_25) == VCC (J12 pins 2-3) puts the module into VSP Bridge mode which can be used as a serial cable replacement to transfer UART data.  Now, reset the DVK-RM1xx or power cycle it and it should begin advertising for a VSP connection. If you do not see the advertisements then remove jumpers J10 (DTR) and J5 (RTS) and reset or power cycle the DVK-RM1xx again.  If you are still having issues getting the board to advertise for a VSP connection, please contact support.

The RM1xx module is currently only sold with Central role BLE firmware, as it was intended to allow the device to scan for peripheral BLE devices, such as BLE sensors, to enable it to collect the data from those devices and pass it via LoRa to the gateway. However, Peripheral firmware is available to be flashed to the module if this is what the application requires. Peripheral BLE cannot scan for devices, it can only send out advertisements, which can request to connect to central role BLE devices. To clarify, the differences between Central and Peripheral are related to establishing a link between the devices.

As we stated previously peripheral can advertise to let central role devices know they are there, only Central can scan or send a connection request to establish the connection. Some refer to the Central as the Master and the Peripheral as the Slave. With BLE a separate unrelated role to Central and Peripheral is that of the GATT Server and GATT Client. The GATT server is the device that contains the data which can be accessed and read by the GATT Client. Please note, there is no connection between the central/peripheral roles and the GATT Server/GATT client roles. While it is common for a Peripheral to be a  GATT Server and a Central to be a GATT Client , it is perfectly possible to have a Peripheral that is only a GATT Client, or a Central that is both a GATT Server and a  GATT Client. The RM1xx configured as a Central, can be both a GATT Client and a GATT Server., and it would have the ability to scan for IOT peripheral devices in the area advertising that they are there. The BLE role has no bearing on the LoRa connection. Either of roles, Central/Peripheral will be able to connect to a LoRaWAN Gateway.

With the above information in mind, if you still feel that the Peripheral firmware will best meet your application needs, than in order to upgrade the firmware on the DVK-RM1xx-SM-02 it would be necessary to purchase a device for flashing the firmware. We would recommend using our QPK-nRF5x programmer , which includes the J-Link ribbon cable , as it should offer the least expensive and easiest way to upgrade between the Central and Peripheral firmware in following the  Upgrading Firmware via JTAG and QPK-nRF5x (Required for Central to Peripheral) - RM1xx Series  Application Note. If however, you would prefer to use a Segger J-Link Probe or Flasher for flashing the Peripheral firmware feel free to contact support for a list of Segger devices which should work with the RM1xx. However, we do not provide additional support for upgrading with these devices outside of the documentation available on our website (Upgrading Firmware via JTAG (REQUIRED for Central to Peripheral) - RM1xx Series). Additional support for these probes/flashers would need to come directly from Segger.

The shelf life statements are essentially to prevent mishandling of the product and not storing it properly. If the modules are still sealed in the package, stored at the proper temperature and have not been exposed to moisture they should be fine. However, when working with modules beyond their shelf life you MUST bake the modules before populating the them to your board. Failure to bake the modules could result in the yield rate dropping down lower than expectation due to popcorn or de-lamination on the modules. It is recommended that you follow IPC/JEDEC J-STD-033 which is the general standard for the handling, packing, shipping and use of moisture/reflow sensitive surface mount devices.

Our main concern is around the castellation/pads which solder the module to the board. It is imperative those pads do not get tarnished, as this would cause soldering issues. Humidity can affect solderability as well, as if there is any excess moisture in the solder on the module, during reflow of the module to the board, steam balls can essentially explode the solder and sometimes result in an open circuit (or possibly a short circuit).

As long as all of the moisture handling and temperature guidelines are being followed you will likely have no issues. It is further recommended that when you do the build with modules that have exceeded their shelf life that you start with a handful to perform a test run and do a final test to make sure all is working as expected. As long as there are no issues with the initial test run we would expect that you will not experience any problems.