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 