What antennas are you using for both?
Their ones. 
:
IMST sells a 20 cm antenna, Laird DK comes with a 14 cm one, probably a dipole
Yes you can upgrade with any JLink including the JLink Edu so long as you have the JLink CortexM adapter (mini 9-pin connector) board (if upgrading the dev kits, if youâre upgrading modules using the boards shown in the top picture then you donât need the connector board, you can just connect the JLink pins up to the connector board using standard dupont connector cables). If youâre using the RM1xx boards for hobbyist activities then youâre fine using the JLink Edu but if youâre using your boards for commercial use then itâs against Seggerâs license to use the Edu model to upgrade the firmware. Alternatively you could probably use a cheap STM32F103 board (ÂŁ2 or so) and load it with the free black magic probe software and program it using that, see https://github.com/blacksphere/blackmagic/wiki
Thereâs a guide for programming one of the cheap STM32F103 boards with a USB DFU loader using a USB-Serial cable to and then using a python script to load the probe software over to the MCU via USB in DFU mode (the benefit of this is you can change/upgrade the probe software in future using just the USB DFU mode): https://medium.com/@paramaggarwal/converting-an-stm32f103-board-to-a-black-magic-probe-c013cf2cc38c
The nrfjprog tool supplied with the Laird firmware only supports J-Link unfortunately, it wonât work with anything else.
But @aigo84 got it close to working with OpenOCD: Anyone tried Laird RM1XX modules ? part 2
Iâm sure it could be made to work with any SWD debugger, even just a RaspberryPi (slowly, using PySWD) I donât have much time to look into this further at the moment.
Actually Iâm also working on a tool but to compile and program the RM186 from the command line - on Linux and macOS - without UwTerminalX
True, but itâs just an ordinary hex file which mostly any programmer with ARM Cortex support and software should be able to program.
Are you aware such a tool already exists? https://github.com/LairdCP/MultiDeviceLoader It only supports compilation on Windows but it wouldnât be hard to add support to XCompile on Linux using wine.
Itâs not just programming the hex file (and soft device) you also need to store a region of the RM186 memory first - the worm as they call it - and write it back. Thatâs where your Device EUI and maybe other things like license key are so you better make sure you do everything correctly!
I know the MultiDeviceLoader but itâs really flaky, I canât get it work. When trying to fix it I found it very heavy and difficult to compile since it relies on having UwTerminalX sources and a whole lot of Qt libraries - ridiculous for a command line app!
You donât actually need any of that, Iâm already using a Node.JS + shell script version which does it all in about 50 lines of code but I canât distribute it as the NodeJS portion is done by another team member.
Iâm now doing a pure Python version which when finished should be open source.
What issues are you getting with it? It doesnât need any of the UwTerminalX files, itâs just 1 c file, 1 header file and the Qt project, all you need is qt5 base and qt5 serial port, none of the other qt libraries are required.
It was some serial port problem, I canât remember exactly what now. We couldnât get it work on either Linux or OSX.
Fixing it seemed straightforward enough but we needed Qt Creator to compile the project which then brings in several requirements - the Mac or Linux Qt Hosts alone are 1GB downloads!
The whole thing is just excessive for bunching a few text files together, sending ti over to a URL, hexifying the result and issuing some serial commands. I also have much more control over the process if everything is done in Python, this is important for larger deployments.
Has there been any update on that SIO_3 not turning to analog in? My proto board has been manufactured with battery level coming in on that 
Damn user manual.
From what they told me 4 months ago the fix should be coming in the next firmware, but th date for that is unknown.
Thanks⌠bit annoyed.
Hi, does anybody know a âoff the shelfâ box built with the RM1XX module?
To anyone plagued with the SIO3 analog in bug, Laird said they would forward me a temp firmware to sort it out by the 12th of June. Will post it here.
1 Like
Hey guys,
Weâve been testing the full version of the breakout board here at Saxion university and run into some problem with the voltage regulator. The Vin and Vout are switched in the design, so we couldnât use the MCP1703 voltage regulator.
https://github.com/hallard/RM1xx-Breakout/issues/1
We solved it temporarily using an ugly voltage divider that decreases the FTDI 5V input level to 3.3V. In that way we could test and run it using a FTDI cable.
Did other people test the full version?
You can get some FTDI-based cables or boards that have a 3v3 pin instead of a 5v pin. The FTDI board that comes with the Laird BA600 set has such a board that you can just plug in without needing to use a voltage divider
Thanks for the hit. A FTDI board (that includes voltage regulator) would work and the Laird RM1xx-DVK board too.
But most FTDI-based cables have a 5V pin. Some FTDI-based cables use 3.3V for Rx and Tx signals.
Iâve tried the FTDI cable FT232RQ TTL-232R-3V3, but it still has a VCC pin that yields 5V.
And than you canât use the LoRa chip, because itâs protected for >3.5V inputs.
Weâve made a debug cable using this and a veroboard. It works just fine.
http://uk.farnell.com/ftdi/ttl-232r-3v3-we/cable-usb-ttl-3-3v-wire-end/dp/1740365
I am having a problem with the RM191 talking to my Microchip LoRa gateway. Similar to what was mentioned earlier in this thread, when using the âcmdâ sample application, and the âlora joinâ command, I receive the message âAttempting to join the LoRa networkâ followed by âTx Doneâ which is following by repeating âNo Sync Pulseâ messages. I have confirmed the gateway works with two microchip motes and confirmed they join and communicate with the server. It appears to me that the server does not receive the join request because there is no indication in the logs that a join request was ever received for the Laird motes.
I am using OTAA, have set the channel mask (1009), AppEUI (1010), DevEUI (1011) and AppKey (1012). Though, because there is no join request, at the moment I do not think I have an authentication problem. Rather, for some reason the gateway does not see anything from the Laird motes. FYI, the channel mask is 0x000100000000000000ff (channels 0-7) taken from page 14 of the"User Guide - RM1xx smartBASIC Extensions (LoRa Functions)".
(Note, at the moment I am running the open source server from the lora server project.)
Any thoughts?