It looks like that by changing the 1 to 0 on the channel mask ALL the 8 500kHz channels - which appear on 1.6Mhz boundaries - became enabled. Effectively the same as changing the 1 to FF.
(500 kHz channels 64 - 71 are at:
903, 904.6, 906.2, 907.8, 909.4, 911.0, 912.6, 914.2
which matches what you’re seeing)
So I’m really not sure how to disable these higher channels. But I’m surprised if your gateway isn’t listening on one of those 500 kHz channels too, is there some configuration? I’m not sure how Microchip gateways work.
Also are you running the latest Laird firmware? You can check your version with
To my knowledge, there is no way to change the channel configuration of the Microchip gateway. If there is, it is not documented anywhere that I could find. The gateway is factory configured for channels 0 to 7. Here is an excerpt from the evaluation user guide:
The RN2903 915 MHz module has its full range of channels (0-63) enabled by default. The Microchip Gateway Radio board is only capable of eight channels of operation. By default it will use the lower eight channels; as a result, the RN2903 end-device channels must be configured for use (Figure 6-1). This can quickly and easily be done through the Utility by selecting the Module from the Device List, then selecting the MAC Channels tab; seen in Figure 6-2.
This seems to suggest the Microchip gateway might not enable the 500 kHz channel.
Well it’s a bit bizarre to me that you can’t configure the frequencies on the gateway or enable the 500 kHz channels as required by the LoRaWAN standard, but it does appear to be the case for that Microchip one.
I’ve asked some people more experienced with US setups if they have any ideas on how to disable those particular channels, will get back to you if I find anything.
Thank you for your help. I am attempting to get an account set up on the Microchip forum so I can ask the question about why they do not follow the standard and if there is a way to enable to 500 kHz channel. It’s an odd registration process … you fill out the form and they tell you they will get back to you in “a while”. It has been several hours now …
I have newer engineering firmware from Laird which should join both on 125khz and 500kHz channels and should solve your problem. The current firmware does require 500kHz channels for joins.
Let me know if you’re interested in this firmware. If you direct message me your e-mail address - click on my username here and choose Message - I can send it to you.
If you prefer you can also contact Laird support and request engineering firmware 101.5.0.7 for the RM191
The relevant release notes are:
"'Also, the module only transmitted the JoinRequest on one of the 500 kHz channels. Because these channels have less range than some of the possible 125 kHz channel configurations, transmitting on 500 kHz channels could affect performance; the module could have been out of range of the nearest gateway.
This is fixed in the new version of the stack. The stack now switches between random 125 kHz and 500 kHz channels as defined in the LoRaWAN spec.
If pin7 (SIO 28) is high, the Lora tx does not work. Happens on any of my RM1xx modules and seems to not be specific to that GPIO pin either. Did I mess something up?
Haven’t tried the peripheral firmware yet because of the flashing method (don’t have a jtag programmer) . What I meant is that any pin that can be turned into a dig in yields the same problem… I have tried GpioBindEvent with the same result.
I hope I’m not going crazy because for the past couple of weeks I have been experiencing this issue + trying workarounds. Its got more to do with setting up a gpio pin as a digital in. Ignore the gpiobindevent for now, its part of a follow up problem. What I mean by the LoRa tx thing is that all messages fail to send, whether it’s a join request or sending actual data. I have some code ill attach when I get home that you can replicate the issue with. Using a custom board, not very complicated, I know the LoRa module disallowes tx when the voltage is above threshold, which is not the case either. Laird confirmed the bug, but I don’t trust they checked thoroughly because you have to convince them your problem is going to lose them cash so that they can prioritise accordingly.
Excuse the code, a lot hacked out to get the key points across. The input circuit is a switch with external pull up resistor. On the new circuit board revision, I used the internal pull up with no change…
In this output below generated by running the code, its clear that every time MOV is a logic high, LoRa transmit fails.
It’s surprising because my applications use digital ins for many things, both as regular input pins and for stuff like buttons with pull-ups and I never noticed any interference with LoRa.
I could perhaps imagine a fluctuating pin triggering several events during the lora send or join causing problems. I’ve seen some weird things happening if you change values during transmission (until you get a TXDONE)
Had a quick glance. Are you perhaps not trying to queue too many messages with LORAMACTxData?
The safe approach is to prevent any any more calls LORAMACTxData() until the previous queued packet was sent (when you get a EVLORAMACTXDONE), if you try to queue more they fail.
Thanks for taking a look. Luckily I haven’t had the issue of too many messages queued up, but thanks for the heads up. In the actual program, everything is very carefully timed. In fact, I halt all interrupts and turn the GPS off just to ensure the radio gets priority in terms of power. Once the tx is done, everything is reactivated.
The input to that pin is a chattering movement sensor. When the device was stationary everything worked, provided the sensor was closed circuit. When mobile I started noticing some gaps in scheduled transmissions, and then it hit me - if the sensor happened to be closed at the time of tx, it successfully transmitted. To confirm, I replaced it with a switch that I could control and came to the conclusion…
Yeah, it is weird. But, I have been working with the RM186 for about 9 months and I have seen some strange things indeed.
I spent the last year with developing for Laird’s BL652 but with the more “native” nRF SDK toolchain.
As this module is based on one of these, I wonder why it is not possible to run a custom firmware… I mean, there have to be mappings for the LoRa stack
