De-activate debugging capabilities will reduce power consumption.Set in .cydwr debug to "GPIO"
I forgot to mention, but I already applied Debug Select to GPIO. Moreover, in the example provided with application note, It is set to GPIO.
any other idea?
As Dana suggested, please check the mentioned low power projects. Are you measuring the instantaneous current during Deep-Sleep or the average current? Can you share your project?
I believe this power consumption measurement is being done in BLE connection. In that case, do you see a connection parameter update request to your connecting device? If yes, what is the connection interval set? I believe for the low power number, you need a connection interval of 1 second.
What device are you using to connect to you BLE pioneer kit? For different devices (iOS, Android or CySmart PC tool), the default connection interval is different.
Thanks for all your advises!
I went through the examples, tried them, tried also to adapt them to my project but I finished with a headache trying to find why my project was non more responding correctly. That is the risk when you apply things you do not fine understand, like the timer modification. But in between I acquired a better knowledge of some of all this power modes and bluetooth LE things, that I started discovering last week...
So I restarted this morning from my same example of HTS, and check everything one by one until now that I have something with a really better power consumption.
I'll preserve you from all the details but what was mainly the cause of high consumption was :
- the Cy Dongle connexion parameters, was set to a very low connexion interval of 10ms. Whatever the preferred connexion setting you set in your peripheral preferred connexion parameter, the server applies his own connexion setting.
- of course I also enlarged the adv settings interval, set GPIO instead of Serial Wire Debug, made very short use of LED,
- then I have also set IMO to 3Mhz, WCO precision to +/-10ppm, and stopped the ILO,
What I did not apply is startup optimisation as in http://www.cypress.com/?rid=110954 because the example for non connectable object is partly the reason of my headache, because I was lost in the way to restore correctly everything for a BLE connexion in my HTS application. Moreover I think this startup situation is not long and frequent enough to go so far in optimisation in my case. I also did not play with IMO stopping and enabling in software due to my bad first experience. Maybe later?
To finish I had to spend a little more power in transmission (+3dBm) because the range was really not enough at 0dBm. Is Cypress going to develop a BLE class 1 device? Do someone know what improvement will give the SMA version of PsoC4 BLE(CY8CKIT-141 : http://www.cypress.com/?rid=109293 ) .
Monopole antenna typically good for 3 db.
It is great to know that you got the power consumption to a better number. Some points I would like to suggest here:
1) As you already noted, the connection interval settings you do in BLE component do not have any influence. This is because, as per the BLE spec, the connection parameters are set by the GAP Central device (the BLE dongle) during connection request and setup. Only after the connection is set, the GAP Peripheral (you kit) can send the a "request" for connection parameter update, with new values of connection interval, slave latency and supervision timeout. For this, you can use the "CyBle_L2capLeConnectionParamUpdateRequest()" API to send the new set of parameters whenever you receive the 'CYBLE_EVT_GAP_DEVICE_CONNECTED' event.
2) If you are running the CPU from IMO, I would suggest to keep the IMO frequency more than 3 MHz. For normal application, 3MHz CPU operation is good. But for application where system has multiple sources of interrupts and processing, you would want to process those items sooner than later and not loose events. We feel that 16 MHz is a balanced vlaue of IMO for better power as well as processing.
Thanks for your advises. I have also seen in the power estimator provided with AN92584 that the power consumption is optimum at 12Mhz IMO, and is a little higher at 16 but also at reduced speed! It seems to confirm that 16 or 12Mhz is the right speed to operate correctly.
While I was playing with the power estimator, I have seen that slave latency has a major effect on reducing power consumption. I did not make any trial yet with this parameter, but I'll probably do some, once I have made the job on the GAP server side, which would probably be my next week job!
I have seen also the feature of updating connexion parameters. As I will provide a product with both the peripheral device and the server, I'll try to avoid this and to set directly the desired parameters into the server. Nevertheless, I wanted to mention this point because it is quite not intuitive for a newbie as I'm to figure it will behave this way.