Iāve been programming these via SWD recently (flashing from central to peripheral). Iāve used a NRF dev kit with jlink firmware, but a segger should also work. Working with a bare RM186, you need to wire pin22 (nreset) to SWDIO, pin23 (nc) to SWCLK, pin 24 (gnd) to gnd, and pin 12 (vcc) to VTref. Segger is programming via SWD. This assumes that you are powering the RM186 via a 3.3V supply as the Segger does not provide it. I then verify connection to the device using NRF Studio, youāll be able to see the firmware layout on the RM186 if you connected fine, after that, I flashed using the firmware tool supplied by laird rather than using NRF studio.
Thank you for the information. I was trying JTAG pinout on j-link. Now I changed the pinout and connected all fine, but still not able to connect/identify the RM186. Could you explain me how you are doing it with the software?
I use nRFgo Studio to verify the connection - as you see Iām using the a nordic NRF52 dev kit as my programmer and this is connected to the RM186 via SWD (P20 header connector). The NRF52 is setup with a jlink segger firmware. The photo shows the nRF51822 (the mcu on the RM186) listed and the layout of its firmware (bootloader, application and softdevice). I use this to make sure Iāve wired up my programmer correctly and that windows is able to see the device.
Next I followed the instructions included with the RM186 110.6.1.0 PE firmware - basically fire up an admin command prompt, navigate to the directory where the firmware is, and then ā__LoadCombinedRM1xx_PE.bat 186_EUā.
Thank you so much for the help you providing. Unfortunatly Iām not being able to detect the RM186 yet, but Iām still trying to figure out why and meking sure the pinout is well connected.
For all the people struggling with flashing the firmware, you can flash it with OpenOCD and a cheap STLink (around 13ā¬) via SWD, but the procedure is somehow dangerous so until I write a complete tutorial with some extra safety operations tested (i.e until I flash another module), I prefer to give it by PM to people that I know they know what theyāre doing.
Also, if you are tired to flash with UWTerminalX for compiling, I wrote a command line tool in python, well itās not that elegant (a lot of hardcoded values) , but if it can help somebody itās here:
I hope this thread is still alive
Two questions:
- did someone find out how the Semtech is wired to the nRF51 inside the RM1xx? Asking because knowing that would make it possible to use c++
- Class C can be set via cmd, but it seems to me that it doesnāt make any difference: RX is only triggered after TX
Edit: Uh, Iāve noticed that TTN still doesnāt support Class C. So 2nd question is answered.
Thought Iād show off my RM191 GPS board I made.
I just finished the firmware, and Iāve been driving all around testing itās range. I canāt believe how far thing thing can go. I really enjoy smartBASIC, and was able to pick it up pretty fast. I love this little Laird module.
nice ! and wiith gps too ā¦
Here is my Laird RM191 Solar monitor 3xI2C power monitors 1xAltimeter 1XAcceleromiter
Hi all, this forum has been super helpful in my own development so thank you all.
Iāve got a problem running my smartBASIC applications whereby the device connects to the network and sends packets without issue while within range of the gateway but when I leave the range of the gateway and return it does not get back on the network.
I am using OTAA keys because I may have devices change networks, and my application contemplates the device leaving the network through the use of a global ājoinedā variable that is manipulated in handlers. If the global is set low by handlers, it attempts to connect using OTAA on a timer and if the global is set hi it will transmit status on the same timer. I have a LED that flashes twice if connected and once if disconnected every 15 seconds based on the ājoinedā variable state that does what is expected so I know the device is recognizing leaving the network it just doesnāt seem to want to talk to the gateway when it returns.
Have any of you run into this before??
Is anyone successfully running a RM191 on Australian AU915. Starting with an example application from Laird, my RM191 transmits out of band (can see with SDR) but once it joins it reliably continues to send packets on the correct AU915 channels. Using the configuration at+cfgex 1009 ā0002000000000000ff00ā for AU915 and running version 102.6.1.0 (result of at i 3) Iām confused as once it joins the frequencies are correct. I have assumed if the channel configuration is wrong, after joining it would continue to use a combination of correct and incorrect channels.
On OTAA join the network provides the channel information to the node. The original channel information is overwritten with the information received.
Ahhh, thatās very interesting. The node must therefore be set for US915 not AU915, even though Iāve installed what I think is the AU version. Thanks @kersing
Solved, Thanks @kersing, found there is a configuration bit that determines if the RM191 follows the channel plan OR broadcasts on all 64 channels. Thanks again for a wonderful piece of information.
Hi @tarrinr, would you be able to post a schematic of the board you made? Could you tell me the specs for the power supply you designed?
Aurora.PDF (364.3 KB)
Hereās the schematic. The regulator is a DC/DC LM3671.
Let me know if you have any questions.
Everythingās for sale for the right priceā¦
The boards arenāt available for purchase, this was my senior project. However if you want one, Iām sure we could work something out.
Iām not sure about sleep current. Both the GPS and the RM191 can be put into sleep mode, which Iāve never tried before. If youāre serious about finding out, I can look into it this weekend.
If you donāt mind checking out the sleep current, I would appreciate to know.
Thank you,
Steve