Anyone tried Laird RM1XX modules ? part 2


(Jose Marcelino) #63

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)


(Sslupsky) #64

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?


(Sslupsky) #65

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.


(Sslupsky) #66

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."


(Jose Marcelino) #67

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


(Jose Marcelino) #68

Also what is this Laird mote? Is it a commercial product?
How is the module powered?


(Sslupsky) #69

Yes. I have power cycled them and used the "atz" command to reset them.


(Sslupsky) #70

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.


(Jose Marcelino) #71

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.


(Sslupsky) #72

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


(Jac Kersing) #73

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.


(Jose Marcelino) #74

Yep it seems the Laird module is using channel 64, the 500kHz channel but your Microchip gateway isn't listening on it.

Try setting your channelmask to

at+cfgex 1009 "000000000000000000ff"

This should remove channel 64.


(Sslupsky) #75

I like the way you are thinking! I tried that yesterday ... no luck :frowning:


(Sslupsky) #76

I see what you mean ... the Laird module says it is using 903000 but the channel is supposed to be on 903100. That has got to be a firmware issue with the Laird module?


(Jose Marcelino) #77

Really? wow.
Did you do atz afterwards? Sometimes I forget and get really confused by the results.
Can you try with LoramacSetDebug() and that new mask again and post the results?


(Sslupsky) #78

I will give it another shot with the debug turned on. I am pretty sure I did the atz. @kersing pointed out that the frequency was not in the list ... and looking closely, I can see the center frequency is off by 100 kHz. I think this may be a firmware issue where the module is using an invalid frequency. Either that or their debug message is wrong. I suspect the actual frequency is wrong though and that is why it is not be recognized by the gateway.


(Jose Marcelino) #79

903000 is channel 64 and it is valid for sub-band 1, however you need to disable it to match your microchip configuration.

The RM191 has 64 available 125kHz upstream channels (channels 0-63) starting at 902.3MHz and incrementing linearly in 200kHz steps up to 914.9MHz. There are also 8 500kHz upstream channels (channels 64-71) starting at 903MHz and incrementing linearly in 1.6MHz steps up to 914.2MHz.

Sub-band 1 consists of channels 0-7 and channel 64

(from the Laird "RM1xx LoRa smartBASIC Extensions" manual)

I believe at+cfgex 1009 "000000000000000000ff" (followed by atz) instead of 000100000000000000ff would disable channel 64, but it's possible it doesn't. LoramacSetDebug will confirm this.


(Sslupsky) #80

ahhh, ok. I see your point. So yeah, maybe its trying to use the 500 kHz channel ...

(sorry for the delay ... TTN forum restricts the number of posts I can make)


(Sslupsky) #81

Good catch! With the debug turned on, I can see that the channel frequency now corresponds to the 125 kHz channels. I can also clearly see that it is using channels that are not within sub band 1. Here is the output:

at+cfgex 1009 "000000000000000000ff"

00
at+cfgex 1009 ?

27 000000000000000000FF
00
atz

00
cmd

OK

lora join

freq 907800kHz sf 8
OK

Attempting to join the LoRa network
Tx Done
dr 13 symb 16
No Sync pulse
dr 8 symb 8
freq 904600kHz sf 8
No Sync pulse
Tx Done
dr 13 symb 16
No Sync pulse
dr 8 symb 8
freq 914200kHz sf 8
No Sync pulse
Tx Done
dr 13 symb 16
No Sync pulse
dr 8 symb 8
freq 909400kHz sf 8
No Sync pulse
Tx Done
dr 13 symb 16
No Sync pulse
dr 8 symb 8
freq 906200kHz sf 8
No Sync pulse
Tx Done


(Sslupsky) #82

Actually, looking a bit more closely, the frequencies are still wrong. Notice that the frequencies used are all on even 100 kHz boundaries (200, 400, 600, 800) instead of odd 100 kHz boundaries (100, 300, 500, 700, 900). So, the channel is still not the correct frequency.