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.)
Summary
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 
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 
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 https://fccid.io/document.php?id=2982391, 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.
Cheers,
Guillaume
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.
2 Likes
Which libraries? Donāt want to make the same mistake.
Thanks,
Stuart
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*"
or
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)
Regards
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
rc=GpioSetFunc(6,2,1)
rc=GpioSetFunc(4,2,1)
rc=GpioSetFunc(5,2,0)
GpioWrite(6,1)
GpioWrite(4,1)
GpioWrite(5,0)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
I believe I have CE version using āRM191_CE_AU_102.6.1.0-r1_ENGINEERINGā This goes back several years.
Also I am not using BLE so did not see any need to change from CE to PE when I flashed a firmware upgrade.
I systematically worked through setting the port to input rc = GpioSetFunc(28,1,X) varying X from 0 to 4. I think I can see pull-up and pull-down with this.
When configuring an output, eg
rc=GpioSetFunc(4,2,1)
rc=GpioSetFunc(5,2,0)
The last variable can be a zero or a one. I assume this is to configure the two drive levels ie Std-Drive = 0.5mA or High-Drive = 5mA.