Hi Morse Micro team,
I’ve been playing around with the combo in the title using the ESP-IDF component. I’ve been aiming to get the sleep consumption down close to where the MM6108’s snooze power consumption is in the datasheet (42uA). That said, it mostly hangs around the 570uA (ESP32 light sleep, chip shut down, RESET_N held, other pins floating).
Testing the xiao board by itself, it sits at around 300uA on average during light sleep.
Is ~270uA the lowest expected power consumption for this module/board? Any other pro tips for getting the Quectel FGH100M-H lower power?
Hi Brendando,
From firsthand experience, and going off seeed’s schematic, resistors r10 and r17 which are meant to bridge wake and busy respectively aren’t populated out of the box
Without a bridge or a 0 ohm across their respective pads there’s no way for the MM6108 to actually sleep
Thanks Michael.
Forgot to mention that I did bridge R10 and R17, so that is passed through. But in any case, the lowest power state I could get it in involves asserting the RESET_N pin which I believe is what the deinit function does for the SDK anyway.
Excellent,
RESET_N assertion is holding the mm6108 in reset instead of actually sleeping, with it you’ll see overall worse power performance because when it’s released the mm6108 will need to re initialize and then renegotiate connection with the AP, which takes a good handful of seconds of transmitting. That said holding RESET_N for sleep looks to consume around 40 uA while its held, so if with the RESET_N assertion you see the Quectel module pulling substantially more than that, something else is amiss.
So with actual powersave, the MM-IoT-SDK will be using DTIM as the default, so that is tuned on your AP. Make sure the AP has it enabled, and then increase the DTIM interval to match your use case. The interval is a byte representing the number of beacons to snooze for, where the AP will hold traffic for the device until it wakes up, so you’ll be trading response time for power savings.
Another trap on the AP side is the types of network traffic routed to the HaLow interface, eg if you plug a laptop into the LAN port of a HaLowLink, the laptop’s multicast traffic will be routed to the HaLow interface, resulting in your device spending extra cycles servicing broadcasts when it wakes up leading to substantially degraded power performance.
Side note, I’ve also put true instead of y for the PS_ENABLE config option which I’ll need to fix, so please make sure that’s actually enabled 
Thanks for those notes, much appreciated. Not the first to put true in a Kconfig and you won’t be the last!
I think I’ve just accepted the fact that we’re not going to get anywhere near double digit microamp sleep due to Seeed’s layout (5V is needed for the RF frontend, but powering the 5V rail means that the battery charging circuitry on the XIAO board is active the entire time). Not to say that we won’t use an MM chip, but it’ll have to be less COTS than I was hoping.
1 Like
For anyone playing at home, I’ve reduced current consumption of the module by 110uA by desoldering R9 (10k pullup on a usually low line). It’s another 110uA away from the datasheet value so I assume there’s another pullup/pulldown that needs desoldering.
1 Like