Apologies if I’m missing a post elsewhere that explains this, but…
I’m using a 3172 in an an application that runs on battery. The sleep mode is fantastic, with power consumption down in the 5-6uA range when the device is asleep. However, I have a low-power sensor tied to the 3172 that requires the use of UART1 - only to send/receive configuration parameters, not for normal operation - and the issue I have is that the module being controlled automatically sends out a few bytes of information every 2 seconds. I can’t stop it from doing this. The effect is that, even though I don’t CARE about this data, it’s waking the device up every 2 seconds when it should remain asleep. Seems like an interrupt tied to UART1’s RX pin is responsible.
I’m in the RUI3 Arduino environment, so not sure how to get at the necessary hardware registers (or if there’s a function I can call) to shut down UART1 (or disable the interrupts) until its needed. Otherwise, things are going swimmingly with this device.
Btw, I tried pulling down UART1_RX and I see as tiny increase on current (around 100uA). But this will not wakeup the the device and will be gone after I remove the pin to ground. So for your uart data every 2 seconds, this is something you need to consider. Unlikely though it has significant effect in your use case.
Ha! I don’t know how I missed this. I was hung up on an api, as I recognized that “api.system.lpm.set(x)” had been added (but wasn’t in the version of the system documentation I had on hand). I tried this to no avail, but completely missed that there was an AT command to set the LPM level. It would be great if an analogous api for setting the level was introduced in some future version of the firmware.
Anyway, this worked - and for giggles I went back and applied it to another device I have running a different battery application. The PPK2 shows that, indeed, a further couple of uA were shaved off the sleep power consumption!
Having to pre-configure this setting through an AT command during deployment is a non-issue. Will just add it to the list of config items we already have standard in the RAK Serial Tool (we’re in there setting APPEUI, APPKEY, MASK, etc., anyway).
Good to know it is working now @philf . Btw, I am not sure if we still have to expose STOPMODE configuration via API since these settings are pretty much permanent on the device once deployed. Like your case, can be part of the preconfiguration process of the device/module.
