baseline deviations

Hi

My captouch project needs tuning. Since CTW( still ) does not work with a uartconnection I am tuning it manually with help of the debugger.

The touch pcb is mounted behind 4mm perspex and 1mm air gap, so i don't have a great signal.

When watching  the baselines I noticed that  some lines shows a deviation of sometimes 3000 counts  when a key was touched, even baselines of other keys went up and down.  When this happenes   some keys stop working.

By accident I worked with the default thresholdvalues of about 1000 :  The deviation of baselines was  300-400 counts, all keys kept working fine.

If i change the TH to my wanted value of 2000 my problem was back, shown here:

0 - 60: TH = 1000   from 60 on TH = 2000

I don't expect the influence of TH values to the baselines.

I played whith settings like filter constants without succes.

 

I work with SSP1.4 (same problem with 1.3) and R7S12447 and 5 simple keys

3465.P10241-5-SW-59a@200718102102.zip

I included my stripped project.

Dig

  • Hi Dig,

    Have you already solved this issue? Also, the link to the attached project is broken too.

    JB
    RenesasRulz Forum Moderator

    https://renesasrulz.com/
    https://academy.renesas.com/
    https://en-us.knowledgebase.renesas.com/

  • In reply to JB:

    Hi JB
    No, it is not solved the way it should have been. I updated the zip.
    By the way: I would be very happy with a working CTW with uart-connection. I have no USB on my board.
    Dig
  • In reply to Dig Kleppe:

    UART works you can check the AE-CAP1 stuff for more details all you have to do is swap out the comms framework from USB to UART and ensure that the rate is 38.4k after it enumerates and 5mm spacing shouldn't be too bad.

    However I am confused as to the problem you're having however, could you more clearly state your issue?

    Thresholds do not influence the drift/baseline value, but you will get false touches to happen if your thresholds are set very low (2-400 counts is pretty low) and your PCB geometry is tight.
  • In reply to Chr15t0ph3r:

    Also, in looking through your ctsu configuration thread your configuration seems alright in that you want it setup for a 4MHz drive. Your thresholds should be roughly 1-3k at that frequency, depending.

    However, your SDPA frequency might be off. I think your CTSU clock should be 0x02 since your PCLKB is set to 24MHz.

  • In reply to Chr15t0ph3r:

    For the uart tuning CTW problem i will start another thread.
    "Thresholds do not influence the drift/baseline value"-> I see it happening with TH of 1500 and above. this is my problem.
    Dig
  • In reply to Chr15t0ph3r:

    I will try this.
    Thanks.
  • In reply to Chr15t0ph3r:

    Changing CTSU clk has no effect.
    I could not find it in the synregy configuration , i changed it in the config struct.
  • In reply to Dig Kleppe:

    I decided to set the thresholds to zero and determine my own thresholds in software.
    I noticed an other problem: My board is mounted behind perspex . If the prespex is removed the baseline is quickly adjusted ( from 11000 to 10000 ). That is OK . If the perspex is put back the baseline is never adjusted back.
    Keys are on now.
    I have set Perform auto-tune and drift compensation only when all channels are untouched to False but this does not help.
    What can i do about this ?
    Dig
  • In reply to Dig Kleppe:

    >I could not find it in the synergy configuration , i changed it in the config struct.
    Yes, you will have to do this for pretty much any CTSU setting.

    As for perspex, that's just acrylic- right? That shouldn't be an issue, the speed at which it adjusts the blue line is based on the drift compensation. If it never adjusts back, I would assume the digital counts you're getting (the red line) don't fall back far enough to drift another direction.

    Auto-tune I believe in that version of the driver periodically adjusts the current offsets to keep the CTSU in a linear region. While drift compensation being enabled should be fine with that setting, to be honest- I'm not sure if that matters at all (I think there's only one drift compensation algorithm, but I'm not sure).

    Can you confirm a noticeable offset or gather some data for us to look at with the overlay on and off?

    What I suspect is happening is that you have startup drift compensation configured, and when you mess with the overlay the fact you have no thresholds sends it into touch, and then you stop drifting.

    Can you please send data of what your operation looks like when touching and not touching it, with the overlay on?