AFE7920: Wrong atkwinlength/decaywinlength

Hi Christian,

Can you please share your Python configuration so I can take a look? Feel free to share it via private message or email.

Honestly, I have never measured the timing as they relate to the window length, so I would recommend to trust your measurements.

One question I have is how are you measuring the attack/decay times? Are you sending some signal that would trigger the AGC and measuring the time it takes for the DSA to take effect? One thing to consider is that the winlength parameters are specifying the number of samples that the detector is looking at at any given time. If in these winlength samples, there are more than numHitsAbs samples above the threshold, the AGC will trigger. Then, we would need enough of the offending signal to be in the detector window for the AGC to trigger. This will take some time as new samples are moved into the window and new samples are moved out of the window. I drew some diagrams below to illustrate this:

In the below example, when the offending signal just starts, there are not enough high samples in the window to trigger the AGC:

After a little bit, there are enough high samples in the window to trigger AGC, and the attenuation will be increased:

So the response time of the AGC will generally be higher than the window length as enough samples outside of the AGC threshold need to move in to the detector window. Beyond this, there will also be some amount of time for the AGC controller to apply the new DSA value, further increasing the response time relative to the window length.

One experiment you can try is to reduce the atkNumHitsAbs and decayNumHitsAbs to see if you can reduce the response time.

Giving a brief explanation of how the numHits and winlength parameters are related to response time:

• Long window (atkwinlength, decaywinlength) and high num hits (atkNumHitsAbs, decayNumHitsAbs) means that you need to consistently see samples outside the AGC threshold to trigger the AGC response. This means you have better noise resistance but response time will be slower. Longer window and more number of hits generally means that the AGC will react to something like the average RX power.
• Short window and small num hits means that you need to see very few samples outside the AGC threshold to trigger the AGC response. This gives faster response time, but will mean that your AGC is more trigger happy and will be more reactive to noise. Smaller window and fewer number of hits moves the behavior more towards a peak detector, where AGC will react to the peak RX power.

Really the window length and number of hits are designed to allow the user to specify noise resistance at the cost of the response time. The window length does not define the response time to be the same, but I would expect that the response time is larger than the window length.

Hope this helps, please let me know if you have any further questions.

Thanks!

Aman

Hi Aman

Thanks for the explanation.

It's clear for me that the time is a little bit longer. But this offset should be constant regardless of the length of the window. But it's always 50% too high.

And yes, I use a generator to make a power jump and look at the power levels at the output in loopback mode. There you see the steps.

But it's not necessary to do any measurement. Just do a configuration and look at the register values I described. They are 50% wrong. Setting them to the correct value leads to the correct timing. The macro agcDigDetTimeConstantConfig is buggy.

And by the way, it's not possible to send you messages and I don't have your e-mail.