Anyone tried Laird RM1XX modules ? part 2

Laird Connectivity released dedicated hardware to program the modules. Compared to original jlink (commercial licenses) a cheap solution.

Check QPK-NRF5x-01, Digikey and Mouser stock the module.

Thanks, kinda trying to avoid dedicated hardware. Especially if the chip is programmable using SWD. So the Atmel ICE is a no go?

I’m not saying it can’t be done, however I have at least 5 swd/jtag programmers and none of them are compatible with the chipset of the other vendor.
I have successfully used both the Laird and Jlink hardware. The Laird hardware provides by far the best experience.

I tried other programmers but wasn’t successful.
Any programmer able to program nRF chipsets should work, should…

If you use another programmer you will need to save some magic values, read the documentation for the Laird kit on how to preserve the license. (Somewhere in the chapter on ‘recovery’ mode iirc.)


This text will be hidden

We’ve totally forgotten about the Laird and we’ve gone with the Murata cmwx chipset and a SamD21G18 chipset for programming basically mimicking the Arduino makr1300 with some design changers sensors etc it’s working well … we found that Laird didn’t support some libraries that we needed and it set us back 6 months in development

Tell me about it, was also shocked to see that it doesn’t support floats :frowning: But there has been a workaround for many of these problems.

Still some things I like about it, like the consumption. But still have to test if I will get the same after consumption after changing to peripheral. I only enable BT for the setup, so shouldn’t be a big deal.

Their programmer does make things pretty simple, which is the only reason I would consider it. I have contacted support, so hopefully I get some good news. Otherwise I get one more niche programmer for the pile :slight_smile:

Hi guys,
I gave up with smartbasic long ago but I still find this module interesting from a HW point of view, so I’d like to code an alternative firmware in C/C++, that would be eventually open sourced ( at least a large part of it).
I’d need to find out the connections between the NRF51822 and the SX1272, so if someone has already unshielded it to test and measure it’d be of interest to me to know the results :-).
Also, on the picture provided here, we can see on the bottom an IC with 8 pins. I think it’s a memory, but not sure, and I cannot read the reference on the picture. If someones knows what is this IC, I’m interested.

I finally succeded to get almost all pins from this RM186 (except P0.18, P0.19, P0.28).
If anybody is interested in following the project, or give help, I opened a gitlab repo so to avoid spoiling the topic.


Which libraries? Don’t want to make the same mistake.



Basically they didn’t have librarías for any of our I2C devices or RS485 libraries… its too new so we went with a better config with lots of programming space … the SAMD21G18 has 148k

Hello all! I am new to this site so please forgive my adding to the end of this post well after the most recent reply.

I have an RM191 development board that I am attempting to interface with an RTL-SDR Dongle using GNU-Radio. Without testing the communication, I believe that the GNU-Radio side of things as the program appears to be listening to the SDR Dongle. I keep running into what is hopefully a simple issue where my RM191 does not want to reconfigure any of its keys. Every combination of:

at+cfgex 10## "*Key*"
at+cfgex 10##?

returns either: E00D - unknown subroutine, 1001 - CFG unkown key, or 7312 - LoRaMAC Invalid Key, where the ## is any number from 00 to 12 (i.e. 1000 to 1012). I have tried various keys that were copied and pasted directly from both this site above where the keys worked for other users, as well as from the User Manual examples. In addition, I have tried to use the LORASetOption with the definition in the RM1xx-defs.h header, as well as the key from the aforementioned documents. I am running out of ideas and wasn’t sure if anyone else had any of these problems before?

Software info:
UwTerminalX - Embarrassingly enough I cannot find the version I’m using, but I downloaded it a couple of months ago and to my knowledge there have not been any firmware updates (aka I haven’t updated the software)

System OS - Mac OSX 10.10.5

Hey smart people! Quite interested to hear from all of you how the RM1xx is coping in your projects etc. Has anyone used this module as battery powered pulse counter (connected to a flowmeter)? Regardless, I’d really love to hear about your experiences with the RM1xx.

Hi! I bought this up in the Part 1 of the RM1xx forum page already. I’m sorry for the bad news, but there is probably nothing wrong with your code. The issue is the GPIOASSIGNEVENT() and GPIOBINDEVENT() calls. I have spent close to a year on and off trying to get this functionality to work while maintaining LoRa radio stability. After contacting support and spending time on Skype with technical staff at Laird, the conclusion was that this will not be solved. Either because they are unwilling or because the bug is just not practically fixable.

This makes some of the most practical applications using the RM1xx module impossible. Interrupt triggers are a must. I was hoping a bit of pressure from developers here could maybe make them reconsider, or at lease give us the truth about the RM1xx capability and update their datasheets.

Either way I was extremely disappointed especially because this was a promising little chip. Laird did a bit of false advertising, and quite frankly I’m probably going to be dumping any of their LoRa related hardware just to avoid headaches and long frustrating nights.

We’ve given up on GPIOASSIGNEVENT etc and are polling the digital inputs on a timer. It’s not ideal but seems to work.
We’re only using the RM1xx module as a communications device. All the heavy lifting is done on an STM32 processor talking to the RM1xx over SPI. The two digitals we do use are simply signals to the Laird to grab some data and sent it.

This all feels reminiscent of writing in BASIC in the 80’s - you’re attracted by how easy it is to get something up and running quickly, then soon run out of steam on a serious application…

I wish Laird would give us seasoned developers another route in to use the product - after all we’re doing all our other stuff at low level in C, and ultimately have to get to grips with the hardware we’re writing for.

Seems like if you wanted to you could port one of the open LoRaWAN stacks to run on the module. The nRF51822 is well document; also documented is a security hole that can be used to read out any memory location, including SFR’s. So even if you don’t have the internal connections of the processor to the radio, you can read out the I/O function configuration and thus figure out where the SPI is, etc.

That’s not to say it’s worthwhile - probably buying another module instead would make sense for any new design. But if you had built a lot of hardware around these and were feeling “stuck” there is a path you could take.

I am using a RM191 module with I2C sensors and between Events the module draws around 5mA. I’ve traced this extra current back to the sensors and external I2C pull-up resistors.

If I remove the sensors and leave the external I2C pull-up resistors the higher current remains and its only when I remove the I2C pull-up resistors the current drops to normal between Events

To explain my circuit. I switch the 3.3V to the sensors and the external pull-up resistors via a High Side switch and this is controlled by a GPIO output pin. I power up the sensors and I2C pull-up resistors just before reading the sensors. I do wait for the sensors to stabilise before taking a reading.

I also enable the I2C port just before using rc = I2COpen(100000, 0, I2CHandle)
I close the I2C port when I power down the sensors rc = I2CClose(I2CHandle)

To stop what looks like leakage current I have tried switching the two I/O pins 29 and 30 to output high, output low and no difference
I also tried switching the two pins to input with a weak pull-up resistor
rc = gpiosetfunc(29, 1, 2)
rc = gpiosetfunc(30, 1, 2)

Does anyone know how to configure a GPIO pin as input with Pull-Up, Pull-Down, or No resistor. I can’t see it in the documentation and only find example code for a weak pull-up as above.

Is there a recommended circuit, code and configuration to achieve low power when the connected I2C sensors are not in use?

(PS, I also tried contacting Laird Support but the email address I used two years ago is no longer active)

Tony Smith

Below is code I use for the rm186 to initialize, the module has vSP enabled and set to enable loading code when no auto run is present. (So the appropriate pull up and pull down on auto run pin etc)

// Set ports for optimal power usage
rc = GpioSetFunc(28,1,4)
rc = GpioSetFunc(17,1,1)
rc = GpioSetFunc(0,1,1)
rc = GpioSetFunc(3,1,1)

// Set port powering Ultrasonic ranger (normal power mode, initial output high)
// Because port is driven by P-channel mosfet 0 equals on and 1 equals off
// Ditto for radar module port

The program uses uart with an ultrasonic distance sensor and I2C with lis3mdl. Current draw of our hardware averaged at 82 micro amps when sleeping.

Thanks @kersing, just about to jump into this tonight.

The program uses uart with an ultrasonic distance sensor and I2C with lis3mdl. Current draw of our hardware averaged at 82 micro amps when sleeping.

The current draw is impressive, I can’t get below 400uA when the RM191 is between Events. I run a 10 minute timer using ONEVENT EVTMR1 CALL HandlerNextTx
I can’t sleep as I have no external timer to perform an external hardware interrupt. When I built the PCBs I wrongly assumed I could perform a Timer Interrupt from sleep.

Also, what is the lis3mdl? Name escapes me and Google was no help.

That suggests that your attempt to disable them with a high side switch is not a working implementation of that idea.

What voltage do you measure on each side of each pullup resistor during what was hoped to be your low power configuration?

With sleep I mean it’s not executing code and in an wait for next event state.

Looking at your power use, I would check you are not pulling up/down any of the pins used by the controller in some way, for instance those used by the vSP.

Which firmware are you using? CE or PE?

1 Like