I upgraded a RAK3172 with RUI3 4.0.6. This module was working fine at 915 MHz. Now with 4.0.6 it won’t change frequency to 915 MHz. I keep on getting AT_PARAM_ERROR. Working in P2P mode. In WAN mode I tried changing to BAND 5, and got an error. There appears to be a bug in 4.0.6. I’ve seen this on another module intermittently. But this particular module consistently gives an error. What is going here? The frequency shows 470 MHz. Why would it do that when it had been working fine at 915 MHz in the older RUI3
If the GPIO PB12 (pad 27 on the stamp module is pulled low, the firmware decides the module is a EU433 or CN470 module.
But that is not new since V4.0.6 the RAK3172 hardware is having this since release and RUI3 is using this pin to detect what frequencies are compatible with the module since its first release.
Hi Bernd,
Thank you very much for the swift reply.
I really appreciate that.
As you describe pin 27, PB12, is used to tell the module what frequency range to use, high or low.
I never was concerned about the status of this pin as I always used it in default mode, high frequency. Because pin 27 is pulled high,
Thus this pin is always left floating in our designs.
This module worked fine with the older RUI firmware.
But RUI3 4.0.6 there is a difference.
When the pin is left floating the module defaults to low frequency.
And gives an AT_PARAM_ERROR, when trying to set 915MHz
After tying pin 27 to VDD the module now operates correctly.
And the error is gone when setting it to 915 MHz.
Thus one can only conclude that firmware 4.0.6 is having difficulty reading pin 27, even though there is a 10K pullup resistor.
There is definitely a difference on how 4.0.6 deals with the High / Low frequency band on pin 27.
On another module occasionally AT_PARAM_ERROR when setting to 915MHz, although most of the time there was no error.
Suggesting the way 4.0.6 reads pin 27 is prone to misreadings
I even tried doing a reset to no avail.
Hi Frank,
The pin is never floating. There are resistors inside the RAK3172:
So far I have no response from customers about the problem you experience. Is it possible to send us one of the devices for more internal testing.
For the random “AT_PARAM_ERROR” we have some feedback from other customers and our team is already looking into it.
Hi Bernd,
I meant on our PCB pin 27 is left floating, I made that clear in the message.
Yes, I realize the pin is internally pulled up inside the module.
Another issue with using an I/O pin for setting the range with an internal pullup is power consumption.
If I needed to set the range to low, then that will burn 330uA, which kills the sleep current.
Why not just set the range based on the programmed frequency?
If you’ve noticed an intermittent problem with the frequency getting AT_PRARAM_ERROR, then my case is just a pronounced version of that situation.
I reported this problem to Carl on Sept. 11.
Thank you
After the boot sequence the pin is de-initialized and the pull-up/pull-down is not consuming current.
Hi Bernd,
I flashed 17 RAK3172 to RUI3 4.0.6.
2 needed pin 27 pullup to VDD to get rid of the AT_PARAM_ERROR .
One unit was intermittent, albeit most of the time no error was reported.
The remaining units no problems noted.
Thank you
Frank
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.