Hello,
We are upgrading from RUI ver. 3.4.11 to ver 4.0.5 for some of our test modules.
After transmitting data package in P2P mode, api.system.sleep.all() does not work anymore.
Any suggestion?
Thank you
James
Can you share your code?
Some changes from RUI3 V3.4.11 to V4.0.5 (timing is different) makes things like
api.lorawan.psend(xxxx);
api.system.sleep.all();
failing to sleep, because the TX finished interrupt is waking up the MCU. This was (by accident) working on older firmware versions.
It is better to use P2P callbacks to know when the TX cycle is finished before calling sleep or to change your firmware to use an event driven style instead of the loop().
I shared an example for such an event driven code style in my RUI3-LowPower-Example
@beegee, thanks for the suggestion, that makes sense, we wanted to use the Superloop method instead of event method to quickly test some products. We will change the logic accordingly and test it out.
Much appreciated.
James
Hi,
@beegee, we have implemented event method, sleep is working as expected. However, we found another issue when using the RAK3172 module as a receiver only. We noticed that after a while
stop responding to AT commands, but the module still receiving P2P packages fine.
The module is not battery power but have constant DC power because it is acting as a gateway for many other devices.
Here is the sequence that we setup the module to be P2P receiver.
- Issue command → AT+NWM=0
- Issue command-> AT+PRECV=65534, to keep the the module on and keep receiving.
- Issue command-> AT+P2P=915000000:7:0:0:10:14, our desire parameter for RF
You can see the image attached, data are still coming in but module stop responding to any AT commands after a few days. The module needs to be reset or power cycle to be able to respond to AT commands again.
Which UART are you using to communicate with the device?
If you use the UART1 pins, this UART is not working in low power mode (device sleep).
In case you are using UART1, try to disable the deep sleep by setting AT+LPM=0.
@beegee, we are only using UART2, UART1, we are planning to use it for other purposes in the future.
Thanks,
Is there any specific time after the module stops responding to the AT commands?
Can you try to use AT+LPM=0 and see if it changes the behaviour?
Running some tests right now in LoRa P2P in RX mode.
@beegee, the time is not constant, sometimes right away, sometimes 20 minutes and a few hours. We have setup a few more modules to run the test. We will issue the AT+LPM=0 command during the setup to see if the issue continues. Will update ASAP
Thanks
@beegee, so we have just confirmed that about 1.5 hours into our test the module stopped responding to the AT commands, but P2P packages are still coming in fine, this test module also received the command AT+LPM=0 at power up. You can see the screen shot below where P2P packages are still coming in but the module stop responding to the AT commands(in pink).
Trying to reproduce the problem.
After ~1h 20 min, I got no response on an AT command. But I could recover by just sending a CR/LF (just an empty string) and the module responded to that AT command.
Can you test this with your device, like this:
AT+P2P=?\r\n
.. IF NO RESPONSE SEND
\r\n
I’ve tried your suggestion and confirmed that the module reply with “AT_COMMAND_NOT_FOUND”, but when we issue valid AT command again, still no response, please see the screen shots, I’ve tried both with RAK serial tool and Hercules.
From your screenshot, it looks like that after there is no response to AT+P2P=? you send the same command again.
Can you try to send a empty string, just CR and LF instead.
I have my test now running for more than 2 hours. Beside of randomly not answering on the first AT command, it always answers when I send a CR LF only after that.
One more question, do you disconnect/reconnect the terminal while you are testing or is it always connected?
Sorry for the confusion. Here are the steps we tried.
- Send empty string, module replies AT_COMMAND_NOT_FOUND
- Keep sending empty string, module continue to replies AT_COMMAND_NOT_FOUND
- Then send a valid command like AT+P2P=? And a few other, no reply from the module.
Basically to sum it up, our module only replies with “AT_COMMAND_NOT_FOUND” when sending it empty string, but the module does not reply when sending any valid AT commands such as AT+P2P=?and a few other we are interested in.
But this is already an issue for us, we will test with other valid AT commands to see in the next few days.
Hi James,
Thanks for this explanation.
I am still not able to reproduce the problem, I am using the same firmware version than you.
I will push this issue to our R&D team for further investigation.
Little update.
After hours of receiving LoRa P2P packets, I still cannot reproduce your problem. I even switched to the same terminal app you are using:
One question, as we were talking about RUI3 API functions before, are you running the AT command firmware or are you using a custom code made with the RUI3 API when you see that problem?
We are just running the AT command firmware, no custom code at all, we are just using the module as a receiver. We think this is a weird bug, because in your case, you can recover by sending CR/LF when your module stop responding to AT commands. For us, when the module stop responding to AT commands, we cannot recover by sending it CR/LF like you did.
Thanks for pushing it to the dev team. Like I said, the timing for this issue to happens is random at times.
Running it now since 4 hours. Still no problem with the AT commands.
But my test environment might be different, because I am using WisBlock with the RAK3372, which is a RAK3172 on a PCB with a UART-USB chip on it.
I am guessing you are using an external UART-USB adapter. When the module stops to respond, did you try to disconnect the UART-USB adapter and reconnect it?
Yup we did, this is the first thing we wanted to eliminate, we even simply disconnect the one adapter and connect the the module to another UART-USB adapter while keeping the 3172 module power on, the module remain unresponsive to any AT commands.
We used the same UART-USB adapter on other 3172 module for another product with custom code using the STM SDK not RUI, the UART2 operates fine.
Our team also just confirmed that the module we order recently last month also have the same issue, this also ruled out the modules we bought one year ago.
We are going to obtain a few more UART to USB dongle but with a different FTDI chip variant to see if our the dongle we current have is the issue. Will update ASAP.