Capsense not running as fast as expected

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
mavac_3892121
Level 1
Level 1
First like given

My design has 25 CSD capsense electrodes. I just want to capture the raw counts at as high of speed as possible. I'm doing no processing. Using a 48MHz modulator clock and 9 bit resolution the Capsense configuration panel shows a scan time of 11us per electrode and 267us "Total scan time" for the 25 electrodes.

Capture.JPG

When I run my code however, capsense takes much longer to execute. The code looks like this:

    for (i=0; i<100; i++)

    {       

        CapSense_ScanAllWidgets();

        while(CapSense_IsBusy()) {;}

    }

After the for loop I read out the time it took over a serial link UART. I tried scanning individual electrodes using several other methods in the API including :

            CapSense_SetupWidget(widgetId);            

            while(CapSense_IsBusy()) {;}

            CapSense_Scan();

            while(CapSense_IsBusy()) {;}

and

            CapSense_CSDSetupWidgetExt(widgetId,0u);            

            while(CapSense_IsBusy()) {;} //waits until not busy

            CapSense_CSDScanExt();

            while(CapSense_IsBusy()) {;} //waits until not busy

and

            CapSense_CSDSetupWidget(widgetId);            

            while(CapSense_IsBusy()) {;} //waits until not busy

            CapSense_CSDScan();

            while(CapSense_IsBusy()) {;} //waits until not busy

All 4 methods took about 60 times longer than the 267us I expected.

Digging deeper, I measured the time to scan each electrode and noticed that button 17 takes about 14000us to scan by itself. There is nothing different about button 17 on the software side. I'm using the CY8CKIT-145-40XX PSoC® 4000S Prototyping Kit and the pin I'm using for button 17 has a capacitor on it so I'd expect a high count, but pin 19 also has a similar cap and it isn't exhibiting the same behavior. The remaining 24 electrodes each take about 66us to scan. Still 5 times longer than the 11us I was expecting from the configuration panel.

1. Is there a problem with my code preventing it from running at the stated speed in the configuration panel?

2. Why is pad 17 taking so much longer than the others?

0 Likes
1 Solution
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi,

The scan time mentioned in the capsense component customizer is the typical time it takes to scan the sensor based on the formula (2^n-1)/ Mod_Clk. But in reality, the actual scan time is the sum of sensor scan time, duration of initialization prior a scan, duration of firmware execution and other components in your firmware such as ISR, which is not predictable. The 66 uS that you get for each sensor is as expected.

Instead of using 25 different widgets, is it okay for you to have a single widget with 25 sensing elements? This will reduce the initialization time considerably and eventually the actual scanning time.

Please let me know if you're looking for faster response. Is it possible for you to let us know your application requirements so that we can suggest you alternate ideas?

Also one more point regarding your application code :

    for (i=0; i<100; i++)

{       

        CapSense_CSDSetupWidgetExt(17u,0u);

        while(CapSense_IsBusy()) {;}

CapSense_CSDScanExt(); 

        while(CapSense_IsBusy()) {;}

    }

SetupWidget function doesn't initiate a scan. So it is not required to check if the capsense sensor scanning is busy.

Regarding sensor 17, as said above scan time doesn't depend on the Cp of the sensors. Can you swap the sensor connection between the pins, say sensor 1 and sensor 17 and see if you still see the same results? Also, probe your sensor 17 and check for the charging and discharging waveform. Check the time period of the charge - discharge cycle.

Regards,

Bragadeesh

Regards,
Bragadeesh

View solution in original post

0 Likes
7 Replies
BragadeeshV
Moderator
Moderator
Moderator
First question asked 1000 replies posted 750 replies posted

Hi,

The scan time mentioned in the capsense component customizer is the typical time it takes to scan the sensor based on the formula (2^n-1)/ Mod_Clk. But in reality, the actual scan time is the sum of sensor scan time, duration of initialization prior a scan, duration of firmware execution and other components in your firmware such as ISR, which is not predictable. The 66 uS that you get for each sensor is as expected.

Instead of using 25 different widgets, is it okay for you to have a single widget with 25 sensing elements? This will reduce the initialization time considerably and eventually the actual scanning time.

Please let me know if you're looking for faster response. Is it possible for you to let us know your application requirements so that we can suggest you alternate ideas?

Also one more point regarding your application code :

    for (i=0; i<100; i++)

{       

        CapSense_CSDSetupWidgetExt(17u,0u);

        while(CapSense_IsBusy()) {;}

CapSense_CSDScanExt(); 

        while(CapSense_IsBusy()) {;}

    }

SetupWidget function doesn't initiate a scan. So it is not required to check if the capsense sensor scanning is busy.

Regarding sensor 17, as said above scan time doesn't depend on the Cp of the sensors. Can you swap the sensor connection between the pins, say sensor 1 and sensor 17 and see if you still see the same results? Also, probe your sensor 17 and check for the charging and discharging waveform. Check the time period of the charge - discharge cycle.

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

Hi Bragadeesh,

Thank you for the very helpful reply!

For the issue with sensor 17. The issue appears to be related to the port P4[3] that I was using for that sensor. When I switch sensor 17 to P4[0], it runs at the same speed as the other sensors. I'm not sure why that is however. I disconnected my daughter board from P4[3] and the read still took the same time. There is a CintB capacitor on P4[3], but the CintA capacitor on P4[2] doesn't seem to cause the same problem and I'm not using CSX. Could it be an ESD failure? I'll dig in with the scope later and observe the waveforms.

For the max speed of the scans: I removed the CapSense_IsBusy() calls between the setup and scan. No change in speed from that. I also changed the capsense setup so that all 25 electrodes are within a single widget instead of having 25 different widgets. There was an increase in speed so now it takes approximately 34us to scan a sensor using any of the three methods where only one setup is required per widget:

CapSense_ScanAllWidgets();

while(CapSense_IsBusy()) {;}

CapSense_SetupWidget(0u);

CapSense_Scan();

while(CapSense_IsBusy()) {;}

CapSense_CSDSetupWidget(0u);            

CapSense_CSDScan();

while(CapSense_IsBusy()) {;}

Using the Ext method which requires a new setup call for each sensor still took 66us:

for (int x=0; x<25; x++)

{

   CapSense_CSDSetupWidgetExt(0u,snsId);            

   CapSense_CSDScanExt();

   while(CapSense_IsBusy()) {;} //waits until not busy

}  

Can you think of any other ways to speed it up? Our application is a touch interface that doesn't fit well into the default configurations of sliders, or XY grids so we plan to write our own algorithm for processing the data.  We want time to scan to be as low as possible so we can get a very responsive system for the user with low latency between the user input and our system creating the desired response. Our target is less than 1ms per scan of 25 sensors. We don't have overlay material/thickness and required sensitivity dialed in yet so it's possible we will need 10, 11, or 12 bit resolution. I tried higher resolutions and noticed that the actual time starts to approach the listed time in the setup window. I get 45us for 10b, 66us for 11b, and 109us for 12b. (The window says 85us for 12b.) Basically the setup phase takes about 24us and needs to be added to the sensor scan time listed.

0 Likes

Hi,

These are the only possible ways you can reduce scan time:

1. Keep the mod clock to the highest possible frequency

2. Decrease the resolution as much as possible. To do this you will need a high Cf, so that your signal is more and you can achieve the desired SNR (> 5:1) with less resolution itself. For this you can have thinner overlays with high dielectric constant.

Your scan time per sensor is 34uS and hence for 25 sensors you take ~850uS which is still less than 1 ms. Isn't this time sufficient for your application?

I removed the CapSense_IsBusy() calls between the setup and scan. No change in speed from that.

-> This  is expected. We wanted to tell you that it is an unnecessary step in the code and it might consume few execution cycles.

Also, you need to write the processing firmware efficiently for faster response time.

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

Hi mvandepas,

The CapSense configuration window mentions the hardware scan time. As Bragadeesh mentioned, the actual scan time that you are measuring is = sensor scan time + sensor init time + software processing time.

At 9 bit i.e. the least resolution, the sensor init time and the software processing time seems to be a limiting factor.

What CPU clock are you using? You can try increasing the same to reduce processing time.

If you are not using any low power mode, and switching between different scan types in your firmware, we may be able to help you decreasing the sensor init time. Are you using any of these?

Btw, I think P4[2] and P4[3] should have given similar results, most likely some timeout is happening inside the component; strangely it is only for one of these for you. Can you actually measure the caps on your board, and also hopefully there's no short of any sorts.

Thanks,

Priya

0 Likes

Thank you Bragadeesh and Priya,

Yes I am understanding now that "actual" scan time is not the same as what is described as sensor scan time in the documentation. Our application requires very low latency and high accuracy scanning of 25 electrodes though a thick overlay so we developed a latency budget to account for all the areas in our system that contributed to latency not just capsense. It would be useful to add a statement in the capsense documentation saying that typical applications have init times of ~24us per sensor. Then we would have included it in our budget from the beginning. Could you include the sensor init time in the internal calculation on the configuration panel? The documentation doesn't mention it at all and the example used in the documentation would probably see it's "actual" scan time double from the extra ~24us init time.

pastedImage_1.png

In my case the CPU is running at it's max speed of 48MHz and no low power modes and I'm not doing any processing whatsoever. I'm not even calling CapSense_Process functions. Just scanning and reading out the raw data so it seems things are running as fast as possible. In engineering it's always possible to take latency budget or margin from somewhere else so I think we will be OK, but it's better to not have surprises.

Priya, You are correct about P4[2] and P4[3]. I measured these pins on an oscilloscope and you can see that though they had the same capacitor on each, due to varitaion P4[2] was barely able to operate while P4[3] failed. After removing the capacitor, P4[3] operated normally. Thanks for the insight!

P4[2] was barely able to operate:

cypress dev board pin 4.2 capsense.png

P4[3] failed:

cypress dev board pin 4.3 capsense.png

After removing the Cint capacitor, P4[3] operated normally:

cypress dev board pin 4.3 capsense(cint removed).png

0 Likes

Hi,

We have provided this information in the Capsense component datasheet under Scan Order Sub-Tab section (Pg 42 - https://www.cypress.com/file/442046/download ). It is required that the user has to measure the "actual time" it takes to scan the sensor.

Regards,

Bragadeesh

Regards,
Bragadeesh
0 Likes

Hi mvandepas,

Thanks for the input on the scan time in the datasheet. I think it's fair that the document gives some understanding of the actual scan time and probably the component window can show some number considering a rough estimate of the init time or a note of sorts that this is only the "hardware scan time" and doesn't consider the init and processing time.

As Bragadessh mentioned, the component datasheet does talk about the same, but may not be very clear. I'll take this feedback and see if we can make update to datasheet or configuration window.

Also, when you probe a sensor pin, note that probes add extra capacitance and so the waveform looks a little distorted. Your last capture of 4[3] would have looked even better if you had placed the probe and then reset the device (thus having the sensor calibrated by CapSense_Start() after the probe is present) Not that it matters in your questions context, but I reckon this information may be useful to you later.

I understand about your timing budget requirements now. Given the fact that the actual timings are higher than you originally expected (i.e. without having the init time info), is the higher timings something that you can work with?

Thanks,

Priya

0 Likes