It’s exactly what I’m doing now. Your previous mention made me remember that I followed Frank Beck’s instructions, an his backplane has LEDs. Right now I’m installing the software using Gonzalo’s instructions.
And it works with the same hardware!!!
Only problem is the CRC fail, and no sync pulse
No sync pulse isn’t a problem, just means there was no response on a particular Rx window.
CRC errors also happen all the time.
What matters is if the data arrives at TTN or not.
No, it does not. One message had the correct CRC, but I cannot find any trace of it on the console. The gateway is still not connected, I was going to investigate that.
But if the CRC is correct for just one of 20 messages I sent from the same room, how is it going to work on the field?
With regards to CRC errors, make sure not to place the devices too close together. At least 2m distance is required to make sure you are not introducing issues because of too strong signals.
Ignore that for now as there is a known issue regarding this. Just check for data in the application part of the console. Be aware the console only shows data for a device/gateway when open at the right page the moment the data is received. It does not store data to look at later on.
1 Like
Ok, thanks. The node and the gateway are in the same room at 290 cm from each other, and are in line of sight, but probably there ia a heavy multipath problem.
Following to your instructions, it works!
{
"time": "2017-04-15T13:14:43.52064348Z",
"frequency": 867.1,
"modulation": "LORA",
"data_rate": "SF12BW125",
"coding_rate": "4/5",
"gateways": [
{
"gtw_id": "eui-b827ebfffe8ab7c1",
"timestamp": 3478503676,
"time": "2017-04-15T13:14:44.344049Z",
"channel": 3,
"rssi": -19,
"snr": 9.8,
"latitude": 44.41485,
"longitude": 8.93776,
"altitude": 88
}
]
}Actually it’s not a multipath problem. If I stand between the two antennas the packet passes, if I don’t, the CRC fails
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?