1 Reply Latest reply on Mar 12, 2018 7:22 AM by e.pratt_1639216

    Bluetooth mouse, time taken from hibernate interrupt to mouse movement. with appropriate scanning and advertising intervals



      I am designing a very low power Bluetooth mouse (possibly as small as 10mah battery) and am trying to find out the typical time taken I might expect between a wakeup from hibernate or stop mode to initiating mouse movement, is there much difference between a wakeup from either mode.

      If anyone has links to studies on this vs advertising intervals and power that would be great!

      Also what happens between when the peripheral fails to respond within the given latency but before Connection supervision timeout? As in, is there any advantage to increasing the Connection supervision timeout beyond the amount of time it takes for the slave latency to naturally expire? I'm not sure what really happens in this period.


      Also as a word of advice to cypress, there should be more information on these parameters being new to Bluetooth it took me a while to find these parameters as it was obvious they existed but I did not know initially what to search for as it can be hard to find answers without an initial keyword, aka. latency which is a somewhat misleading name in itself.


      Also can the peripheral suggest scanning intervals for the host?


      Best regards,


        • 1. Re: Bluetooth mouse, time taken from hibernate interrupt to mouse movement. with appropriate scanning and advertising intervals

          I believe the hibernate and stop mode wakeup times are roughly the same. There is a slight difference in behavior and current draw while they are "reset/off" in the two modes, but once the chip goes to startup they behave pretty much the same.


          Lower advertising intervals and deep-sleep will get you the most power saving while still having the device's BLE chip running. Using hibernate or Stop will save exponentially more power, but both of those require an external button press/IO toggle to start the chip going again.

          Unless you want the increased power saving of the hibernate/stop modes over the deep-sleep modes in exchange for having to push a button to manually reset the device, then deep-sleep is the most common mode for saving power while still running the device (with deep-sleep you can still get years of power off of a coin-cell with proper application). Here is the app note on power modes and saving battery life: AN92584 - Designing for Low Power and Estimating Battery Life for BLE Applications


          The latency and Connection Supervision are described in the BLE component datasheet, but Slave Latency understanding - Bluetooth® low energy Forum - Bluetooth® low energy - TI E2E Community and Connection parameters - Introduction to mbed BLE  explain why you would modify/use the slave latency, and the connection supervision timeout is essentially an overall connection timeout for the devices not having communication for x ms of time.


          If either the slave latency of the supervision timeout fail, then the connection will end. There would be no effective difference in behavior for one ending versus the other ending. But, the central device doesn't have to end the connection after the supervision timeout (slave latency either I think), but can instead use it as a notification of the remote device being missing/unresponsive.


          If you don't need a feature/functionality, you don't have to use it


          Googling "BLE" followed by the keyword search terms generally yield good results, as most of the BLE features/functions are extremely standardized across the industry. Right-clicking the BLE component and opening the datasheet/api documentation will also give you a large library of information on BLE operation (I recommend using the search functions to find specifics you are looking for)


          The peripheral can only suggest connection settings, as the central is the device in charge of the connection overall, thus it can veto/ignore/use any settings that the peripheral suggests at it's own free will.


          PS: I do agree that the documentation is had to read/find what you need to know in order to learn BLE, but if you already know BLE, learning how the Cypress chip is different from other chips is relatively simple. I recommend BLE tutorials/videos/getting started first, as the documentation is aimed at knowledgeable developers more so than new developers.