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
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.
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 @jmarcelinoabove and you will see there is no match so it is not surprising the gateway does not receive the OTAA request.
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?
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?
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.
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.
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
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.
