Sentrius RM1xx LoRa + BLE Module

Yes, Lora is a modulation technique using chirp spread spectrum whereas LoRaWAN is a network topology define by the Lora Alliance. While all LoRaWAN uses LoRa, not all LoRa is LoRaWAN.

A LoRaWAN system is comprised of end devices, gateways and network servers and a broadcast from a LoRaWAN end device must be forwarded by a LoRaWAN gateway to a LoRaWAN network server for authentication.

But it is possible to have point to point LoRa devices that use a proprietary protocol that are not interoperable with LoRaWAN.

Laird RS186 and RS191 are LoRaWAN end devices and can only send data through a LoRaWAN gateway to a LoRaWAN network server.

Some of the internal SmartBASIC events are being shared between certain peripherals and hence limitations apply for certain combinations. On the RM186 the SmartBASIC implementation uses the same mechanism internally to trigger both LoRa TX and GPIO assign events.

Simplest workaround would be using GpioBindEvent() instead of GpioAssignEvent(). However, this comes with a slightly higher power consumption.

Another workaround would be clearing the GPIO assign event before triggering a LoRa TX event and vice versa. To ensure this, the following sequence would be needed:

• In your GpioAssignEvent() callback function disable the assign event with GpioUnassignEvent() and start a short one-shot timer (e.g. some 10msecs).
• In the callback of that timer trigger the LoRa TX.
• On completion of the LoRa TX (either successfully or failed or both, depends on your application) re-enable the GPIO assign event in e.g. one (or more) of the following callbacks: EVLORAMACSEQUENCECOMPLETE or EVLORAMACTXCOMPLETE or EVLORAMACRXCOMPLETE (maybe others could be used too, would depend on your application)

The smartBASIC language provides functions for setting a specific set of channels to be used for BLE advertising/scanning or a BLE connection.

• BleChannelMap(chanMap$) enables or disables data channel usage when in a connection.
• BleAdvSetCreate(nSetId, nAdvProperties, nPriSecPhy, nFilterPolicy, peerAddr$, chanMask$) can set BLE advert channels.
• BleScanStartEx(scanTimeoutMs, nPriPhyScan, chanMask$, nFilterHandle) can set channels used for BLE scanning.

The channel map/mask has to be entered as a 5 byte long string for each of the functions and due to the little-endian architecture of the underlying ARM core its composition can be confusing. The below example will show the actual assignment of channel within that string. Furthermore the meaning of a set bit differs among the above functions.

• BleChannelMap() -> a set bit means channel is enabled!
• BleAdvSetCreate() and BleScanStartEx() -> a set bit means channel is disabled!

Now let's “visualize” the channel mapping into the five byte string:

channel number:

00000000|11111100|22221111|33222222|xxx33333
76543210|54321098|32109876|10987654|xxx65432
\byte 0/ \byte 1/ \byte 2/ \byte 3/ \byte 4/

So for enabling e.g., channels 9+10 only you would set the yellow bits:

00000000|11111100|22221111|33222222|xxx33333
76543210|54321098|32109876|10987654|xxx65432
\byte 0/ \byte 1/ \byte 2/ \byte 3/ \byte 4/
 0x00     0x06     0x00     0x00     0x00

giving “0006000000” as string.

For disabling channel only 35, i.e. active channels are 0-34 and 36, it would be:

00000000|11111100|22221111|33222222|xxx33333
76543210|54321098|32109876|10987654|xxx65432
\byte 0/ \byte 1/ \byte 2/ \byte 3/ \byte 4/
  0xFF     0xFF     0xFF     0xFF     0x17

giving “FFFFFFFF17” as string.

Further detail is given in the smartBASIC Extension Guides in the documentation section of the product page for each BLE module at Bluetooth Module Portfolio.

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.

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.

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. 

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.

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.

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.

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.