"Jitter" on any 'logic' or square/rect waveform, including library

     Hello,

     Since you've tried many quite logical methods with the same result, it appears that the issue is inherent to the pulse waveform itself.  The AD Wiki entries for sources with sudden transitions (square or pulse waves) warn against directly outputting these waveforms due to their excessive harmonics.  They recommend filtering the waveform first.  I'd link to the wiki except that it appears to be down -- all I get is 502 errors.  You could experiment with filtering to see if it helps with the jitter or at least makes it less audible.

Edit:  I got to experiment with a square wave gen on a ADAU1701MINIZ board.  Measuring 20 nS of jitter is beyond my cheap scope, yet I could demonstrate the effect of filtering the square wave before it hits the internal DAC:

The output with no filtering shows how the sharp transitions make the DAC's internal reconstruction filter ring:

The 15 KHz second-order Butterworth filter damps the ringing:

     The high-order filter produced an even worse ring of its own.

     I can't hear the difference between the two waveforms, yet that doesn't mean much at my age.

     Best regards,

     Bob

Hello DavideMancini,

I think what you are running into is kind of a tough thing to get around. In the digital world we only have the sample rate to tell time. A 50/50 duty cycle square wave of X-Hz will be high for X/2 samples and low for X/2 samples. If the frequency divides evenly into the sample rate and has an even result, then it can be perfect. So a 1kHz square wave implemented in a 48kHz fs system should be high for 24 samples and low for 24 samples. So many of the algorithms use a simple method and will approximate and divide out the error so that it "makes up" by adding another sample or dropping a sample every once in a while making for a jitter. The average frequency will be correct but it will jitter. I do not have the time to devise an experiment at the moment and see if there is a way to improve this. Ultimately it is a discrete time system so you cannot get any frequency perfect. Just some special cases. You can try this out by choosing some special rates and see the results. 

Also, if your project is not too big, or you can just copy part of it, then run the DSP at a faster sampling rate and see if the jitter improves proportional to the sample rate?  If you do create a small project to test this please include it in a post to make it quicker for us to experiment as well. 

By the way, I did do a bit-banging method of producing a PWM output by using a serial port on the Sigma300 processor but this will not help you with this issue. This is an interesting problem that I think would be good to figure out some ways to reduce or eliminate it. 

Dave T

Hi Dave, thanks for your reply, I made other tests and came 'around' your conclusion: "that is the way some algorithms works".

In the end I used another approach (which is one of the coolest things that the 1701 stimulates!) and I will drop you guys a note in the next days.

I did other tests and found out that, in the 'sources' arsenal, only the Sine and Triangle doesn't suffer from this effect. Most probably is due to the fact that, unlike the other waveforms (square, pulse and saw) those are 'continuous' and probably this makes the handling more refined and sophisticated than the simple 'comparator on/off that need to happen with all the other waveforms. 

The resolution thing is of course the main culprit.

Anyway, if any of you is interested in what we've come up with the 1701 (production is undergoing!!!!) have a look at this vid, I think that, complexity and capability wise, it's something remarkable for this humble part:

https://youtu.be/M_EhJaUIHYE?si=I07uGudGBDdes1_G

I want to point out that without you and KJBob this would have been much harder to achieve, so THANK YOU very much!

Hi KJBob, first of all thanks for your reply and all of your contributions to this forum, those stimulated me to go on with the project and were a source of continuous inspiration! Check out my reply to Dave's answers for the end of the story (for now!) and the final output of my efforts with the ADAU1701!!!

Hello Dave & Davide,

     Thanks, Dave, for your helpful posts.  Davide, the demo video is great!  It's amazing what complex, fascinating sounds you've achieved. I have a few additional thoughts from my experience with another member's question.  This thread:  https://ez.analog.com/dsp/sigmadsp/f/q-a/574775/tone-generation describes a frequency error -- from the limited resolution not of time, but of the controlling parameter.  It turns out that only periods with their number of samples equal to a power of two have exactly the expected frequency (although any error is very small).  Unlike the jitter problem, this one gets worse with increasing sample rate (because the parameter's value becomes smaller).  The thread concerned the ADAU1466, but I just tried it today with a -1701 to find essentially the same results.

At 187.5 Hz, the Capture Window shows a terminating decimal parameter.  Its period covers 256 samples, a power of two.  If for example you try 1 KHz, the parameter becomes 0.00833333333, which gets truncated -- so the resulting output deviates from 1000 Hz.

     Hardware issues could also cause jitter -- particularly the PLL filter layout.  I scoped pin 35 to check PLL stability.  This requires a probe technique borrowed from switching supply ripple measurement, as shown below:

Here's what my eval board does (2 mV / div. AC coupled). The PLL loop should look this good or better on any hardware where jitter is an issue:

     Best regards,

     Bob

Wow guys,

This is a great thread! Lots of gold to mine here. 

Bob, I had missed your earlier post about the resolution of the control parameter. It must have been when I was overwhelmed with other stuff. Someone recently asked a question about the quality of the sine wave generators in the DSPs. I had also always wondered about this as well so I took some time to make some measurements. I am blessed to have some cool test gear at my fingertips. So I wrote up this post. I also did some research to find out the size of the ROM sin tables and there is also a function for triangles so that is probably the reason for your observations. It makes me wonder if your approach, Davide, of using an ABCD block and a sine wave generator to create a square wave might work better? We can never get around the fact that we are in a discrete time domain but it might help to remove some of the dithering. Here is my recent post:

(+) SigmaDSP Internal Oscillator Quality - Q&A - Audio - EngineerZone (analog.com)

The measurements I made are interesting because some of these frequencies are not easily explained by aliasing. Yet they did move with the fundamental like an alias would. 

Dave T

Hi Dave,

indeed it's a matter of 'definition' of control values and aliasing (to some extent) but also there are some inherent "glitches" that happens around the logic blocks. I tried the experiment of putting in a sinewave and the 20 microsecond jitter is there again. In the end, as I anticipated, I tried to avoid the use of 'digital' or 'logic' blocks. To generate a pseudo PWM I use my derived 'triangular' (transformed from a sine VCO using a LUT) added to a DC level (coming from the modulation input) and saturating everything with a soft clipper with a VERY limited threshold (to mantain rising and falling edges square-like). Increasing and decreasing the DC level generates something like a variable pulse width (within certain limits...). I then re-amp the signal. This eliminates completely the 20uS jitter. Unfortunately, high up the spectrum something still happens and it doesn't sound as aliasing (the sizzling sound changes slowly over time without any intervention and change of params. This happens at signal fundamental frequencies higher than 1.2Khz. I traded, for this higher range, the re.entry of the triangular and up to 6Khz (so VERY high in pitch, almost double of the highest note you can hit on a 'piccolo' flute or a piano) everything's OK again. I repeat, the module have also SINE and TRIANGULAR outputs which are OK!