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.
If in doubt about any of the commands I check the BL600 documentation as that seems to be where the firmware is based on. And sometimes the example code and reading the include files reveal ‘secrets’ they forget to mention in the documentation.
1 Like
You have to be joking. There is a wealth of information in the BL600 SmartBasic documentation. Why did they remove some of the detail when they created the SM1xx docs?
Thanks
1 Like
I am measuring 0v on both sides of the I2C pull-up resistors and this applies to both SCL and SDA. I connected the pull-up resistors to spare I/O pins 16 and 17 (SPI MISO and MOSI) and powered them from these pins.
I get exactly the same result every time. The module goes to low power after a join and after the first use of the I2C the power drain jumps to 5mA between events.
I now assume the processor is failing to return to low power mode. After reading the I2C sensors, sending the data etc i can see the modules current varying before settling down to 5mA. This suggests to me the processor is not sleeping between events.
I’ve tried a number of different sequences in closing the I2C port and powering down the pull-ups to SDA and SCL. Have checked the UART does not have something in the buffer.
I have switched all the serial pins to input with weak pull-down resistors and no change.
This is doing my head in.
You closed the serial port after the last print? Print automatically reopens it.
Yes, done that. I also comment out all the print statements in the final code so it does not open the uart. I also close it when the code first boots. I also confirm this by connecting a terminal to check no print statements remain.
In your node how do you achieve low power with the I2C sensors? Does each sensor have a sleep mode where you sleep each sensor after it is read? Do you close the I2C port as well?
The sensor automatically returns to sleep mode after a measurement. I2C is closed after taking a reading.
1 Like
Thanks, I will reconfigure my code and eliminate the power down system. In the test I will also only use the sensors that I can sleep or that have low power consumption.
Problem Solved: I had one I2C sensor that had become disconnected and did not respond to I2C write and reads. It happened to be a outdoor light sensor and would expect to read zero while testing the node indoors.
As a result the I2C Close command did not work and the Laird module would draw around 5mA while sleeping between Timer Events.
After all of this I can confirm the power down of the sensor 3.3V using a High Side switch to turn off the sensors and also to power down the I2C pull-up resistors works fine.
3 Likes