Anyone tried Laird RM1XX modules ? part 2


(Jose Marcelino) #42

What antennas are you using for both?


(Guido Gam) #43

Their ones. :smile: :
IMST sells a 20 cm antenna, Laird DK comes with a 14 cm one, probably a dipole


(Bobzega) #44

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


(Jose Marcelino) #45

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: https://www.thethingsnetwork.org/forum/t/anyone-tried-laird-rm1xx-modules-part-2/6227/9?u=jmarcelino

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


(Bobzega) #46

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.


(Jose Marcelino) #47

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.


(Bobzega) #48

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.


(Jose Marcelino) #49

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.


#50

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 :expressionless: Damn user manual.


(Jose Marcelino) #51

From what they told me 4 months ago the fix should be coming in the next firmware, but th date for that is unknown.


#52

Thanks... bit annoyed.


(Lorenzo Campana) #53

Hi, does anybody know a "off the shelf" box built with the RM1XX module?


#54

pcb - https://www.pcbway.com/project/share/LoRa_BLE_sensor_node.html


#55

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.


(Erikvanderarend) #56

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.


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.


(Erikvanderarend) #57

Did other people test the full version?


(Bobzega) #59

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


(Erikvanderarend) #60

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.


#61

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


(Sslupsky) #62

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?