4 Replies Latest reply on Nov 15, 2015 4:24 AM by frsac_1312136

    Unusual Approach

      I have an idea for a PSOC BLE peripheral device connecting to a smartphone. The smartphone needs to know the Peripheral is available and working all the time. Some very infrequent (once per month) trigger event happens on the Peripheral and it needs to make the smartphone aware quickly (latency <2s). The app on the PSOC also needs to know when the smartphone has received the event (latency <2s).


      I want maximum to squeeze every last drop of battery life on the peripheral so was considering that having a long term, open GATT connection running between the two devices might not be the best power saving strategy (this is just a hunch btw). Hence I have thought of several scenarios involving complex advertising strategies, something like: 


      1 Peripheral: Broadcast "I'm here" (Advertise Slow, undirected, non connectable).


      2 Smartphone: observes "I'm here", performs some simple internal operation.


      3 Peripheral: Some predetermined event happens to an external sensor and fires a GPIO isr.


      4 Peripheral: StopAdvertising.


      5 Peripheral: Change advertising data reflecting the "triggered" state.


      6 Peripheral: Advertise Fast, connectable "triggered"


      7 Smartphone: detects new advertisement "triggered"


      8 Smartphone: connects to Peripheral


      9 Smartphone: writes a characteristic


      10 Peripheral: detects write operation


      11 Peripheral: performs internal operation


      12 Peripheral: disconnects smartphone


      13 Peripheral: resets


      This looks reasonable and I have already created a smartphone app which is continually scanning for advertisements from the peripheral. Surprisingly this constant filtered scanning has shown little impact on device battery (Nexus 5, Lollipop) so I am assuming it's been offloaded to the smartphone's BLE subsystem.


      Areas of concern


      Step 6 where I change from non-connectable to connectable advertising. Anyone got an example, seems it should be possible?


      Step 8 I'm not too bothered about security but I suppose if I use a whitelist on the Peripheral then I wont have to implement a rogue client disconnect strategy. But the smartphone will no doubt use a random public address for privacy so I'll need some previous bonding stage to enable the resolving of client addresses for the whitelist. I seem to recall that IRK wont work with whitelist and that my PSOC app needs to do the address resolution itself, am I correct? The upside of this though is that the connection from the bonded smartphone could serve as a suitable "triggered" acknowledgement without the need to update a GATT characteristic.


      Any comments welcome especially on areas of power consumption and my areas of concern.







        • 1. Re: Unusual Approach

          From the power consumption point of view, please refer to the BLE Low Power Application Note. Between the advertisement and connection intervals, we can put BLESS to Deep-Sleep. Please check: AN92584 - Designing for Low Power and Estimating Battery Life for BLE Applications (http://www.cypress.com/documentation/application-notes/an92584-designing-low-power-and-estimating-battery-life-ble)

          • 2. Re: Unusual Approach





            Nice application flow.


            For Step 6, I did not understand your concern. Is the power consumption or finding a way to change non-connectable to connectable?


            If power consumption is your concern, then connectable will consume more power as it will have scan response enabled. Everything else remains same and only depends on the advertising interval and number of channels used for advertising.


            If you want a method to dynamically switch between connectable and non-connectable, then this project may shed some light: https://github.com/cypresssemiconductorco/PSoC-4-BLE/tree/master/100_Projects_in_100_Days/Day007_Peripheral_and_Broadcaster 




            As for privacy, it is true that the smartphone will have random addresses. Atleast iOS will, not sure of Android. Did you give this project a look?



            1 of 1 people found this helpful
            • 3. Re: Unusual Approach

              Thanks very much for the response. 


              After some trial and error I managed to get this flow working reasonably well. Strange thing is that it takes about 4 seconds for the smartphone to connect after receiving the connectable advertisement from the PSoC. I used the dynamic advertising example from the 100 days series.


              Regarding the "connectable/scannable" state in step 6 incurring a high power cost. I envisage this higher-power state will exist for just one period of 10-20 seconds per week so hopefully this will not impact battery performance materially.


              I had a look at the Privacy project and thought I would try to keep things very simple for now and avoid any pairing/bonding (might speed up my slow connection establishment observation highlighted above).


              Next up for this project will be to add in periodic (daily) battery voltage determination. I'll try using the ADC on the 0-5v scale. I think this is normally taken care of using a resistor network but I wonder if I can get away without external components (I don't need accuracy, just some rough indication). When ADC reports voltage from my coin-cell is nearing collapse I'll mod subsequent "I'm here" advertising packets to indicate LOW BAT.





              • 4. Re: Unusual Approach

                Hi Paul,


                depending on the "collapse" voltage you might be able to use VDAC + PGA + SIO pin as comparator.
                those are pretty thursty thus it makes sense to switch them on only for a quick test once a day or so.


                All the Best

                1 of 1 people found this helpful