The response time of the sensor depends on multiple factors:
1. Scan time of the sensors - Depends on resolution and modulator clock frequency. Reducing these parameters helps in reducing the response time. But make sure that you have a SNR of at least 5:1 for reliable operation.
2. Debounce parameter - Number of consecutive scan samples for which the touch should be present for it to become valid. This value is set according to the noise conditions in the system. The default value is 3. Decreasing this leads to reduced scan time.
3. Manual tuning - Allows you to have strict control over for the scan time since you can set the minimum N and Mod clock with minimum SNR requirements (> 5:1)
4. Usage of Firmware filters in advanced tab will cause the processing time of ProcessAllWidgets to increase. Try using minimum filters to reduce response time.
There is no standard execution time for these API's. It purely depends on your configuration and design. If you wish to measure the execution time for these API's you need to use a PSoC TCPWM timer or an oscilloscope.
For example, execution time of ScanAllWidgets depends on the scan time of sensors, no of sensors and if any entry or exit callbacks defined.
Execution time of ProcessAllWidgets depends on the firmware filters, debounce parameter etc.
Also note that the scan time of the sensor is the sum of the hardware scan time and the sensor initialization time during each scan.
Thanks for the information.
But the thing is, we are getting proper signal values only we keep higher bit resolution like 13 bit.
Due to which scan time is not upto mark.
Any solution for this?
1. Is the mod clock set to the highest possible value as supported by your device? PSoC 4200 supports max 24 MHz mod clock.
2. Try increasing the operating frequency of the device (PSoC 4200 supports upto 48 MHz clock), this will decrease the processing time and hence decrease the response time.
3. If you want to have reduced N and still have a reliable signal, you can use thin overlays with high dielectric constant. This helps you in giving good SNR ( > 5 :1) for lower N.
4. Are the firmware filters disabled?
5. Are you using Manual tuning for software parameters such as threshold? SmartSense takes more processing time.
6. Prefer using single widget with many sensors, rather than using many widgets (to reduce sensor-initialization time). Please ensure that the sensors are similar, so that the tuning parameters are similar for all the sensors within a widget.
For example, in your design instead of using 10 widgets for 10 buttons, use a single widget and add 10 sensor elements to it. If the buttons are similar, then you can use the same tuning parameters for all the sensors and this will reduce the sensor initialization time further.
7. If you are using low power modes, you can have reduced wake up time to see better response.
8. Also please check if there is some other part of your firmware that is delaying the sensor scans. It is better to have CapSense with a higher priority in your design.
Further, can you please let us know your CapSense configuration? We could try at our end to reduce the scan time further for your case.
You could save the configuration in xml file and send the same. (Click save configuration on the top of the CapSense configurator window).
Please let us know the current response time you are observing and the response time you would like to have in your design.
Thanks for the details. few queries as per your suggestion.
1. How to configure the operating frequency of the device to 48MHz?
2. Is the below is hardware designing? Is it possible to configure it now? If yes then any instructions to set it.
If you want to have reduced N and still have a reliable signal, you can use thin overlays with high dielectric constant. This helps you in giving good SNR ( > 5 :1) for lower N.
1. Yes. Mod clock is set to 24MHz.
2. Yes. Firmware filters are disabled.
3. Yes. Using manual tuning.
4. Will use single widget with many sensors as per your suggestion.
5. CapSense it set as highest priority. But any info on why we have to set widgets priority in configuration?
Waiting for your reply.
1. Go to Clocks tab in the WorkSpace Explorer. Click on Edit Clock on the top. In the High frequency clocks tab, select the IMO frequency to be 48 MHz.
2. Changing the overlay is a hardware change. You can refer to Overlay selection section in CapSense design guide for more information
3. CapSense it set as highest priority. But any info on why we have to set widgets priority in configuration?
-> Can you please elaborate your question?
As per your below suggestion, we have checked the performance by using single widget with many sensors for all buttons. But the thing is, all these sensors are not behaving exactly the same as that of the slider.
Each sensor is behaving differently for the same tuning parameters. Wondering what would go wrong here?
You can use this option only if the dimensions of these buttons are similar (same parasitic capacitance). You can use compensation IDAC and turn on auto calibration to account for the differences in the Cp of the different buttons. The component will calculate comp IDAC for each sensors in a widget so as to get 85 % of max raw counts for all the sensor in a widget.
It is expected that the buttons will behave differently for the same tuning parameters owing to difference in Cp.