Noise adapation on electrode

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Noise adapation on electrode

556 Views
afcec
Contributor I

Hi, 

I have a project successfully running with a MKE17Z. I have several electrodes configured for two TSI modules. Some of them are working together as sliders while others are simple buttons grouped in a keypad.

Under "normal" conditions everything works just fine, but in some specific circumstances I am experiencing an issue on a button used to increase a timer value ('+' button). Each button press increases the timer value in 1 unit and if the button is kept pressed, the timer increases faster up to a certain level.

When the user presses this button many times continuously (Imagine the user wants to go from 0 to 45 minutes), the noise increases quite fast and therefore the deadband is updated accordingly. This evolution of the noise is rising the deadband really close to the signal so the button press is suddenly not detected.

The point is that once we reach this situation, and even if the user stops pressing this button, the noise decreases very very slowly and the button press is not detected for a long time.

My questions are:

1. Why are these continuous button presses rising the noise level when all of them are above the deadband by quite a wide margin?

2. Why the noise level rises quite fast while it then falls slowly?

3. Is there any specific parameter I can adjust to avoid/improve this situation?

The current configuration for this electrode is:

truct nt_keydetector_usafa nt_keydetector_usafa_El_11 = {
.signal_filter.coef1 = 2,
.base_avrg.n2_order = 12,
.non_activity_avrg.n2_order = 15,
.entry_event_cnt = 7,
.deadband_cnt = 2,
.signal_to_noise_ratio = 3,
.min_noise_limit = 250,
.dc_track_enabled = 1,
.dc_track_cnt = 200,
};

The screenshot attached shows this situation. You can see the noise rising with the button presses and suddenly the margin of the signal over the deadband is not enough.

0 Kudos
2 Replies

531 Views
afcec
Contributor I

Application note AN12709 has a specific section with the following comment:

If we change the “base_avrg” filter order from 10 to 8, the noise level adaptation will be 4x faster than before, so that it can update
the deadband threshold much faster and react to the increased noise. Note that the noise level recovers automatically, when the
noise signal is gone. The noise level recovery speed is hardcoded to be 16x faster than the noise accumulation, which is suitable
for most cases, but it can be accelerated in the SW if desired.

I do not quite understand this sentence highlighted in bold. Noise level recovery speed is hardccoded? Isn´t this recovery speed controlled with base_avrg filter? How can I modify this behavior in SW?

0 Kudos

404 Views
RaRo
NXP TechSupport
NXP TechSupport

Hello @afcec,

We apologize for the delay to answer you.

Could you please try modifying the following values as AN12709 NXP Touch Development Guide recommends managing noise? Look at Section. 8.4 Key detector uSAFA tuning (.signal_to_noise_ratio) and Section 8.4.1 Noise level adaptation (.base_avrg).

Isn´t this recovery speed controlled with base_avrg filter?

Yes, actually that section recommends modifying the base_avrg filter.

Is there any specific parameter I can adjust to avoid/improve this situation?

For your software development, have you used any example from the SDK to help you? If so, have you tried to call the TSI_EnableNoiseCancellation in case you are using self-cap mode. Also, there are other application notes that could be helpful take a look at:

Why are these continuous button presses rising the noise level when all of them are above the deadband by quite a wide margin?

Why the noise level rises quite fast while it then falls slowly?

This could be cause for a couple of reasons. For example, AN3863, Designing Touch Sensing Electrodes - Application Notes mentions: "Larger electrodes easily detect the presence and absence of a finger. However, in some cases, they can be more sensitive to electrical noise or undesirable surrounding objects."

Best regards, Raul.

0 Kudos