Phantom POT change triggers

[bobsellon]

I'm trying to implement a mute for a POT controlled echo to mask the pitch shifted audio while the delay changes but I seem to be getting intermittent, late, changes from the POT triggering the mute at undesireable times.

This is my POT-change-detection code:

Code: Select all

rdax  POT, 1
wrax  temp,1
rdax  lastPotValue, -1
skp   zro, processDelay
; else change detected
clr
rdax  temp,1
wrax  lastPotValue,0
; then trigger the mute
sof	0, 0.99	 	; Reset value for the holdoffCount.
wrax	holdoffCount, 1.0	 

The holdoff gets decremented each time the code runs with the following:

Code: Select all

rdax	holdoffCount, 1.0
sof	0.9997, 0           ; sets the rough holdoff window (approx 300ms) 
wrax	holdoffCount, 1.0  ; Save the scaled version.
sof	1.0, -0.1		; Offset the value move the holdoffCount 
;  threshold around. -0.1 yeilds 190ms with 0.9997. 
skp	neg, unMute

I've been using one of the outputs to monitor values (wrax dacr,1) with a storage scope but I'm not seeing any change in value from the POT when the false trigger occurs but my theory is that there is a subtle ripple coming from the POT (harmonic of the POT filter?).

If I expand the mute time long enough the phantom mute trigger is masked but we're trying to keep it as short as possible.

Any suggestions/comments?
Thanks
Bob

[frank]

My guess is that the problem lies here:

Code: Select all

rdax  POT, 1
wrax  temp,1
rdax  lastPotValue, -1
skp   zro, processDelay 

All ADCs have some noise and we did our best to eliminate it in the POT inputs but if the POT is really close on a value change then just the LSB changing can cause the routine to see a POT change but you won't see an LSB change on the scope, too small.

Create a guardband and check the POT changes by at least that amount before calling it a change. So do the POT0 - LastPotVal then see if the difference is greater than a certain limit, sort of like:

if ((abs(POT-LastPotVal) - 0.125) > 0) then do change

Here the POT must have changed by at least 0.125 before we will do the change routine.

[bobsellon]

I tried a few variations on this but the threshold has to be rather high to block the phantom data-echo and a blob of pitch shifted audio gets through before the gate kicks in. I'm still messing with the response of the POT for changing the delay vs the gate threshold but I'm thinking that I might need to add a high pass filter (set for a pretty low frequency) for the gate detection. I've already tried a low pass filter but since the problem only happens every so often so, perhaps, the noise is at a low frequency.

[frank]

Hmmm, odd. Send me the code (you can email it to the support address) and I'll take a look at it and see if I can reproduce the error. Also check the power rails, if the power glitches that can throw off the reference used by the ADC. Also send the schematic, just want to see how the POT inputs are handled external to the chip.

[bobsellon]

Just sent that off. We're seeing the problem on our actual product but I'm able to reproduce it with the development board.

Note that the left output is being used to monitor the pot-change value (added a test wire off the chip before the bypass cap).

I was thinking the same thing with the power and ground and even added a .1uf cap to the wiper of the pot but it didn't make any difference. Could still be an issue depending on the layout of the ground trace relative to REFN pin. Perhaps it needs to be to be kept isolated so that things like LEDs and other current-users won't interfer.

I thought it was also possible that the current load of the audio output drivers might be leaking into the ref inputs but the problem persists even at very low audio levels so probably not.