Post Go back to editing

Timer with ABCD comparator

Dear Team ,

I have a concern regarding the ABCD comparator and timer with stop start and reset control on Sigma Studio GUI 

I am trying to compare two sine waves ,one with some decay and the other with a normal fixed amplitude for the entire length of time.

After I feed these two inputs to an ABCD conparator,I would like the output of the Comparator to send a 1 until and unless the sample value in pin a is less than sample value in pin b but once the reverse happens I would want the timer to be stopped by the 0 output of the Comparator and hence stop counting any further samples once the decay is over . However I am not getting fruitful results .

Can anyone help 

  • I wonder why the forum appears so inactive these days ...

    No reply ...

    Can I get some helpful suggestion or insights on this asap please

  • Would you please say which processor you are using? Also, if you could post a project or screen shot of what you have tried, that would be very helpful. Lastly, I'm assuming that your two signals are in phase. Otherwise, you would need to use some sort of envelope or RMS detector.


  • Dear Ken 

    I am using ADAU1452 

    1. And I'm feeding the comparator pins a and b from a single sine tone generator .The ony difference is that pin a received the input from the tone generator after passing through a SW Volume Control (RC optimized) while pin b receives the input directly from sine tone generator with no module in between 
    2. I understand that the slewed signal samples will be smaller in amplitude than  the original sine -10dB samples and hence I would like the timer to count only these samples which are less or different and feed it to the ReadBack cell
  • Dear Ken ,

    I do not understand what keeps you from responding but I will assume you must be busy but please provide support on this asap.

    I am using a SW Slew Volume Control .

    At default condition if you set the slew rate as 6 or 7 or any value the signal fades in until it reaches your input level ...

    I would want a circuit to count the exact number of this faded samples ....

    From the formula BoB outlined I get a value of a out 25ms when slew rate is set as 8 but from my several trials with different test projects I can never really get the ReadBack cell to read expected values that come from the formula 

    TC= we 10*[2^(n-9)] where n is the slew value 

  • You have opened a couple of posts of posts so I will do my best to answer them both here. Bob (not an ADI employee) was kind enough to send an example project. Did that provide any guidance? As I said, I am not able to comment on your project without more information. There are lots of ways that you may have tried to implement this. Please post the project(s) that you have created so far, and I will try to guide you. 

    It appears that you are interested in tracking the envelopes of signals rather than the instantaneous values. You will need to use an envelope detector to do this effectively. It does not sound like you have implemented this advice. Even with the tones in phase (same oscillator), if you are passing the signal through a volume control with slew, it is entirely possible that the signal with gain is remaining one LSB or more below the direct signal. I would recommend that you add a small constant before the comparison to provide a little hysteresis. Try replacing the slewed volume control with a gain block that you can better control numerically. A gain of 1 in the gain cell should give the exact same signal. 

    Readback cells do not provide instantaneous values of variables. They are literally "read back" from the DSP to the SigmaStudio GUI by polling the SPI (or I2C) port with the USBi. Since this polling is statistical, you are unlikely to catch the exact peak of a sine tone, for example.

    I am assuming that your slew questions are only tangentially related to your sample counting question. Details on the hardware slew may be found in this post and downloaded here. The equations for the hardware slew are more rigorous than for software slew. If you need exact time constants, I suggest you take advantage of the hardware.


  • Dear Ken ,

    I understood your concerns . Let me start by explaining what I want and what is my progress 

    Firstly I am unable to zip up a project here so I'm attaching an image file ..that should do the job just fine( sorry to bother you )

    Coming to the point :    

    I am using the SW Slew Volume Control and by default when the DSP comes out of reset the Volume Control fades in your signal based on the Slew rate setting in the Sigma Studio GUI .

    For convenience let's say I set this slew rate as 8 .

    For a slew rate of 8 from the formula provided by BoB ,I expect a time constant of 25 ms,(in other words my fade in time is 25 (ms )assuming a full slew of 99% ) this time is what I want to calculate using Sigma Studios module such as an ABCD comparator and Readback cell.

    Now what I have done and what will be evident from the image to you is that 

    I have used an inbuilt oscillator and fed it to a volume control and then to an envelope detector 

    From Bob's fantastic idea I am trying to compare the same slewed signal with a 2 ms delayed version of itself and count the number of samples as long as they differ from each other .

    As you suggested I have used a gain block and set it to a linear value of 1 since my sine tone input is 0dB and hence that is the maximum value attained by my signal after fading in .

    I assume that once both the signal reaches 1 the timer stops and the counting is over the ReadBack cell should show u the number of faded samples 

    Am I correct ? Can you suggest what I could be doing wrong 

    P.S- I am not setting any value in the envelope detector since I don't want the decay rate of the detector to interfere with my counting results 



  • Dear Ken 

    Can you please provide support .

    It's quite important at the moment 

  • Hello  and ,

         In an attempt to help with this I entered Hermione's screenshot into SigmaStudio.  The project does provide a readout although the delay idea doesn't provide consistent results over a range of slew settings.  I also tried a more explicit version, simply comparing the level after the Slew Volume with 0.99 x the level before it.  IK would like to attach both projects to help save time for all.  I'll ask Lisa in EZ Support to do this for me, since my ability to attach files has once again quit on me.



    Please see the zip file below:

  • Hello  and ,

         In an attempt to help with this I entered Hermione's screenshot into SigmaStudio.  The project does provide a readout although the delay idea doesn't provide consistent results over a range of slew settings.  I also tried a more explicit version, simply comparing the level after the Slew Volume with 0.99 x the level before it.  IK would like to attach both projects to help save time for all.  I'll ask Lisa in EZ Support to do this for me, since my ability to attach files has once again quit on me.



    Please see the zip file below:

  •      Thanks, Lisa!

         With the projects attached, now I can explain them.  The comparison of the levels before and after the Slew Volume does give a result compatible with the 99% criterion being approx. five time constants.  Perhaps this is all that's required -- if so, then really, Hermione has figured out his own solution.  The projects I have been sending him are rather more complex, because I began to understand (perhaps mistakenly) that the Slew Volume was a proxy for his actual application, still unknown to me.  Thus I had included automatic hold & reset functions for the count as well as other ideas, including the delay one.

         Best regards,


  • Dear Bob,Ken 

    The project with level comparison still does not give me expected result for slew rate set to 2 and set to 4 

    I get values of 0.708ms and 5.33 ms while the expected values are 0.3ms and 1.5 ms respectively .

    Please explain why even this level comparison isn't working ...

    If you can tabulate the values observed versus expected it's much helpful to verify at my end as well 

  •      Hello Hermione & Ken,

         This is the tabulation I found with the level comparison.  The expected time is not exactly 5 time constants (which is a common approximation) but mathematically it's equal to  - ln(1-0.99) = 4.605  Thus I used this value to compute the theoretical or expected times for a 99% rise.

    Now, why are the times returned for the lowest slew settings (like 2 or 4) so far off?  It has to do, not with the Slew Volume Control or the measurement, but rather, the sine wave itself.  For example, with the slew # at 10 and the result reasonably accurate, the Sine oscillator plus the Slew Volume Control yields the rising sine wave shown below  (I added a DAC at the Slew Volume Control's output and scoped it):

         Here we can clearly see the rising envelope (level) of the rising sine wave -- which the Slew Volume Control provides.  It produced a good count.

         When we set the Slew # to 2, the result does not reflect the Slew setting.  Here's the output:

    This time, we don't see the action of the Slew Volume Control at all -- the trace is dominated by the sine wave itself.  Thus at the moment the sine wave reaches its first peak at about 0.33 mS, the Slew hasn't reached its 99% value -- so the thing keeps on counting.  It has to wait for the second peak at 0.7 mS.  This is what the counter measured!  (Note that the Peak Envelope block works with both positive and negative peaks -- it's a full-wave rectifier, or Absolute Value in DSP speak.  If it weren't, the result would have been even worse.)

         If we increase the Sine oscillator to 10 kHz, there's more peaks for the circuit to work with and we measure 17 counts and 0.35 mS -- a better result.  Generally, we cannot expect perfect accuracy in these measurements.  Although the DSP operates digitally, it's modeling analog signals.  An interesting example is Sample Rate Converters (SRCs) -- although they're digital in and digital out, they still have analog specs such as signal-to-noise (SNR).

         Ken's circuit slows the operation down by a factor of 1000 -- 1 S = 1 mS -- so you can see similar results on its Real-Time Displays.  'Playing' with it can be quite instructive.

         Best regards,


  • Dear Bob,

    Appreciate your efforts ! 

    Can you provide the formula you used to calculate the expected and also tell me why this is better than the previous formula .

    Also I'd like to re-iterate here that since the circuit works well for slew rate 1 why should it fail for slew rate 2 there some logical problem with my logic in the schematic ? ...for slew set to 1 results almost match expected whereas this isn't the case of slew rate 2 or 4 in which case can I get the acceptable margin of error or a tolerance range .This would be a conclusion to all our efforts .

    Much thanks !


  •      Hello Hermione,

         The rising slew follows the equation:

    y = 1 - e^ ( -t / T)   where y is the linear gain which begins at zero and rises toward one,  t is elapsed time, and T is the time constant which is a property of the slewing which depends upon the slew number.

    We can solve this backwards and get:

    (t / T) =  - ln (1 - y)   where (t / T) represents the number of time constants we need to wait to achieve the final gain y.  For example, y = 0.99, then:

    (t / T) = - ln (1 - 0.99)   = - ln (0.01)  = 4.605 ....

    The Peak Envelope Block tracks the sine wave as it rises from zero, then holds onto its maximum value -- which will be near 1.0 for a 0 dB sine wave, or about 0.32 tor a -10 dB one.  Once the peak has passed, the sine wave slopes downward while the Peak Envelope Block's output would normally decay slowly down toward zero until the next peak occurs.  Since you've set the decay rate to zero, it never decays but instead remains at the peak value.

    With very small slew numbers, the slew completes while the sine wave is still in its first upward slope.  In this case the output of the Peak Envelope Block is the same as its input, and the count is correct.  With large slew numbers, the slewing is slow, covering many cycles of sine wave -- so the the circuit finds one of these peaks and provides a reasonably close count.  It's when the slewing time to 99% occurs between 0.25 mS (the first peak at 1 kHz) and 0.75 mS (the second peak) that you get poor results.

         There is no error in your logic -- it's just an limitation of this method generally.  If you need only to measure the slewing time of the Slew Volume Control (or similar device) where you have access to the sine wave both before and after it, you can get better results by substituting Absolute Value blocks for the Peak Envelope Blocks.  In fact, you need not use a sine wave at all -- the Slew Volume Control works with DC, so using a DC input gets rid of the hassles with the sine wave altogether.

        For the general case, for example, comparing the levels of two sine sources which may differ in frequency and phase, you really need Peak Envelope Blocks on each -- and live with the resulting errors at certain rates of rise.

         Best regards,