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?
I guess you should review what settings you have on your gateway. Two in particular come to mind: the sync word and of course the channel map.
Did you pick channels 0-7 to match your known configuration?
Channels 0-7 match these frequencies:
channel 0: 902300000 hz min_dr 0 max_dr 3
channel 1: 902500000 hz min_dr 0 max_dr 3
channel 2: 902700000 hz min_dr 0 max_dr 3
channel 3: 902900000 hz min_dr 0 max_dr 3
channel 4: 903100000 hz min_dr 0 max_dr 3
channel 5: 903300000 hz min_dr 0 max_dr 3
channel 6: 903500000 hz min_dr 0 max_dr 3
channel 7: 903700000 hz min_dr 0 max_dr 3
I think these are actually unusual in US installs (for example TTN doesn’t use them)
Thanks for getting back to me.
Yes, the gateway is configured for channels 0 through 7. I set the gateway configuration using the Microchip java app. When I look at the data received from the Microchip motes, I can see that they are received on channels 0 through 7. So I think the gateway is properly configured for channels 0 through 7. Thus, I configured the channel mask on the Laird motes for channels 0 through 7.
I have the sync word set to 0x34. I understand this to be the setting for a “public” network. I tried setting it to 0x12 which I understand is the setting for a “private” network but that made no difference, the Laird motes still did not join and there was no indication in the logs that the gateway ever saw them. I do not understand what this setting does actually. There does not appear to be a setting on the mote for the sync word, only the gateway?
I need to clarify my last message. Actually, the factory configuration for the Microchip gateway is to use channels 0 to 7. I do not know how or if that can be changed. It is the Microchip motes that I configured to use channels 0 to 7 when talking to the gateway. I found a Microchip support article online that said to configure the motes for channels 0 to 7. So that is what I did and they talk.
I found another reference to the gateway channel limitation of the Microchip gateway in the “LoRa Technology Evaluation Suite User’s Guide” on page 61 that states “This will configure the RN Module to only issue LoRaWAN transmission on channels 0-7, which are the only channels supported by the Network Evaluation Kit Gateway.”
Ok I think that settles the channel problem.
Just checking but have you tried resetting the Laird mote after changing the configuration? Either physical reset or atz should do it
Also what is this Laird mote? Is it a commercial product?
How is the module powered?
Yes. I have power cycled them and used the “atz” command to reset them.
Yes, the RM191. Here is the link: https://www.lairdtech.com/products/rm1xx-lora-modules
Apologies, I was referring them as a “mote” … I am using the Developer Kit (DVK-RM191-SM) which incorporates the RM191 module. Power is currently through the USB port.
Can you do a sudo tcpdump -AUq port 1700 on your LoRa server (assuming your running the gateway bridge there too)
That should show you exactly what traffic is coming in from the gateway, before any processing.
You should get readable text (JSON) showing frequency, device addresses etc.
Thanks for the feedback. I did try that earlier and the only thing I see are the status packets and the Microchip motes.
I turned on the debug by calling the LoramacSetDebug() function in the sample application. I got the following additional output:
lora join
freq 903000kHz sf 8
OK
Attempting to join the LoRa network
Tx Done
dr 13 symb 16
No Sync pulse
dr 8 symb 8
freq 903000kHz sf 8
No Sync pulse
Tx Done
dr 13 symb 16
No Sync pulse
dr 8 symb 8
freq 903000kHz sf 8
No Sync pulse
Tx Done
dr 13 symb 16
No Sync pulse
dr 8 symb 8
freq 903000kHz sf 8
No Sync pulse
Tx Done
dr 13 symb 16
No Sync pulse
dr 8 symb 8
freq 903000kHz sf 8
No Sync pulse
Tx Done
Check the frequencies listed by @jmarcelino above and you will see there is no match so it is not surprising the gateway does not receive the OTAA request.