Sigma 300 (ADAU145x) Slew Volume Rates

     Slew volume controls can filter noisy control inputs and minimize clicks.  Often the desired slew rate can be found by experiment.  However, in some applications it would help to know the actual slew rate a given setting yields.  For example, the ADAU1701's slew rates are described at https://ez.analog.com/message/156092#156092

    The -1452's slew volume controls are different (and more versatile) than those of older SogmaDSPs,  There's separate rise and fall settings, each with several curves to choose from.  The "RC" curve setting shown here provides slewing similar to that of the older slew volume blocks, thus the slew rates can be measured the same way (see the post cited above).  Although this RC curve is exponential in nature (it follows the RC characteristic that includes the term e^(-t/RC), the -1452 slew block also offers a separate exponential choice. Testing the -1452's RC slewing this way results in the table below.  Slew times are given as a time constant as well as the dB/s rate often specified for SigmaDSP dynamics processors.

The Sigma 300's Exponential slewing operates in ways both similar to, and different from, the RC slewing.  The post at Sigma 300 (ADAU145x) Exponential Slewing describes the differences.



    Linear slew settings yield these 10 -- 90 % rise and fall times.  If you prefer 0 -- 100 % times, multiply these times by 1.25..

  • Next chapter: constant dB

    As expected this basically multiplies the value by some constant each frame until it reaches the endpoint, specifically by 1+δ when rising or 1-δ when falling. (Note that this implies it falls a bit faster than it rises for any given parameter value.) The values of δ for slope parameter values 0...63 are easiest to express in binary:

     0  0.00011
    1  0.000101
    2  0.0001001
    3  0.0001
    4  0.000011
    5  0.0000101
    6  0.00001001
    7  0.00001
    ..
    60  0.00000000000000000011
    61  0.000000000000000000101
    62  0.0000000000000000001001
    63  0.0000000000000000001

    Based on limited testing it appears the exact update is:

    x = x + max( floor( δ * x ), 1 )  when rising

    x = x - floor( δ * x ) - 1  when falling (this is wrong, see later post)

    until the target value is reached of course.

  • After further testing I found my description of constant-dB slew was not yet quite accurate in all cases. I've tried to capture the fine details into a small piece of python code that simulates the slew peripheral. I've also added support for negative numbers, and mostly-correct support for RC slew. Since I don't really care about RC slew much I think I'm going to consider the slew peripheral "sufficiently clarified" for now ;-)  Of course I'd still be happy to receive and apply patches that close the gap between my simulator and the real thing.

    I've put the script here on github.

  • Dear Bob,

    Is there any formula to derive time in milliseconds from the slew rate ? There does not seem to be any fixed pattern or differences between consecutive slew rates and their corresponding time in ms

    Also how is amplitude reduced or increased (by a factor of what) for say each setting of the slew rate value

    Regards'

    Hermione

    •  Analog Employees 
    on Feb 23, 2021 6:56 PM in reply to Hermione

    Hello All,

    I think it is time to post the details of the hardware slew engine in the Sigma300/350 processors. 

    This is what I have for information.

    Dave T

    PDF 

  • Time to slew depends on slew rate and how much distance it has to go (on linear scale or in dB depending on slew mode).

    The meaning of the various slew rate setings wasalready elucidated in this discussion thread, culminating with my last reply in 2018 that has a link to a python script that accurately emulates the slewing behaviour of the ADAU145x, which can therefore also be used as an unambiguious form of documentation / specification.  I fixed the remaining issue last year (it now simulates the chip bug that occurs when using RC slewmode when the distance from current value to target value does not fit in a signed 32-bit integer) and with that update it is now perfectly emulates the hardware as far as I can tell.