Hi, I've read everything here How can I make bcm20732s sleep and wake it up by GPIO interrupt? I can find on sleep and I find that the question I have is still not answered. The closest to an answer I have found is the statement:
"When advertising (ADV) or in connection, the device will not go into deep sleep. However, it will go into other low power modes like sleep and pause based on the connection/ADV interval and other activities.
1. I understand that the application does not get to control the low power state but I would like some guidelines on what configuration will enable the lowest power state possible short of deep sleep. For example, if my fine timer or connection interval is less than 64 milliseconds, would that somehow inhibit low power states? i.e. is there a threshold of time which plays a role in determining sleep level and what is that threshold(s)?
2. I have an interrupt that fires every 50 ms ... but it's from an external device and the BLE firmware has no way of knowing about this (unless it were to keep a log of interrupts, which I doubt), so my interrupt should not affect ability of the BLE firmware to make the decision to sleep. Is this a correct assumption? (certainly the interrupt will terminate any sleeping that might be going on... that is expected, but I also want to be sure that by interrupting any sleep at this frequency I am not introducing some kind of thrashing in the system that will end up costing me more power than I am saving by sleeping for 48 milliseconds between interrupts).
3. Can you give a short list of current draw for the various invisible low power states (which I do not have control of but would still like to know about so I can calculate my expected battery life).
4. For my application, I never want to go into HIDOFF deep sleep... but I do want the battery to last as long as possible. So in my callback function for the low Power Query, I return a non-zero number, like 200000. I understand this is like telling the firmware "When you make your decision about whether to sleep or not, understand that I don't want you to sleep any longer than 200000 microseconds". Is this the correct interpretation? And the 64 dollar question: Does this number that I return from the low power query callback function in any way influence how deeply the not-deep-sleep low power mode will go? For example would I potentially get a lower power state if I return 200000 than if I return 64000? What if I return 50000?
For some context on our App.. we have the fine timer at 200 mSec and the connection interval at slightly less than 200s. We are always in connection when possible and send data samples to the host continuously during the connection. The 200 ms interval is somewhat arbitrary. For example we might consider buffering data samples and sending less often if that meant we could spend more time in some lower power state. This is why I want to understand what the firmware is doing even though I don't have explicit control over it. I think if I have the answers to some or all of the above I can arrive at the optimal design.