[sdiy] Generating a large number of CV outputs

David Kantowitz dkantowitz at gmail.com
Mon Dec 11 18:38:59 CET 2023 

Richie,
Thanks for explaining more clearly.  Seems my visualization skills are
better than my writing skills.

I saw mention of the "bit reversed PWM", but couldn't find the email
describing it.
Can you sketch the idea? I'll try making a chart of that too.
-David K.

On Mon, Dec 11, 2023 at 2:10 AM <rburnett at richieburnett.co.uk> wrote:

> For each constant that you repeatedly add to the NCO you get a unique
> bit-pattern generated.  And the amount of 1's in one period of that bit
> pattern is proportional to the constant that you add into the NCO.  The
> funky pattern is a graphical representation of this...
>
> Notice how the plot is lighter at the bottom and darker towards the top.
>   That is because the density of 1's and 0's changes as you move up the
> plot and the constant being added into the NCO is larger.  White pixels
> look like they represent 0's and black pixels represent 1's.  The bottom
> row is white right across, so that is a run of 256 zeros.  The top row
> is black right across, so that's a run of 256 ones.  And all of the rows
> in between have varying numbers of 0's and 1's roughly evenly
> distributed across the row.
>
> Now if you look at the equivalent picture for PWM you'll see that all of
> the 0's (white pixels) and 1's (black pixels) are grouped together in
> each row.  That is because PWM goes high for the programmed pulse width
> then returns low for the remainder of the period.
>
> Now I'm wondering what my "bit reversed PWM" would look like on one of
> these plots...?
>
> -Richie,
>
>
> On 2023-12-11 09:54, cheater cheater via Synth-diy wrote:
> >> He's plotted the output from the algorithm as black and white pixels
> >> (the x axis) for each "DAC output value" (the y-axis).
> >
> > ugh, still struggling. i don't know what that means. :S
> >
> > On Mon, Dec 11, 2023 at 10:29 AM Tom Wiltshire <tom at electricdruid.net>
> > wrote:
> >>
> >> He's plotted the output from the algorithm as black and white pixels
> >> (the x axis) for each "DAC output value" (the y-axis).
> >>
> >> The difference between the "carry-bit NCO" approach (or whatever we
> >> want to call it) and the PWM output (the final diagram, half black,
> >> half white) is clear to see.
> >>
> >> The important thing is the way that the black and white pixels are far
> >> more mixed up- e.g. the noise is of much higher frequency, and
> >> therefore much easier to filter out.
> >>
> >>
> >> On 11 Dec 2023, at 08:59, cheater cheater via Synth-diy
> >> <synth-diy at synth-diy.org> wrote:
> >>
> >> Thanks, sorry, I still don't understand this:
> >>
> >> > Each horizontal row of the chart is the waveform generated for the
> constant input on the y-axis.
> >>
> >> what do you mean by that?
> >>
> >> BTW, it's probably useful to send these emails to the list.
> >>
> >>
> >> On Mon, Dec 11, 2023 at 3:01 AM David Kantowitz <dkantowitz at gmail.com>
> >> wrote:
> >>>
> >>> "carry-bit NCO" is how I summarized the approach Tom uses: output a
> >>> pulse whenever the counter overflows.
> >>>
> >>> Each horizontal row of the chart is the waveform generated for the
> >>> constant input on the y-axis.
> >>> y=0 -> row of all zeros (white)
> >>> y=256 -> row of all ones (black)
> >>> y=128 -> row of alternating ones and zeros
> >>>
> >>> The interesting parts are really:
> >>>   a) Overflow bit approach is _vastly_ better than PWM.
> >>>   b) Most microcontrollers have a timer/counter peripheral where you
> >>> can implement this in hardware, having almost no s/w cost, and runnig
> >>> around the uC's clock rate (several MHz).
> >>>   c) 1st order sigma delta converters are garbage: need a hefty
> >>> oversampling rate and noise rises like a 45 degree line through the
> >>> passband.
> >>>
> >>>
> >>>
> >>> On Sun, Dec 10, 2023 at 12:43 PM cheater cheater
> >>> <cheater00social at gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Sun, Dec 10, 2023 at 8:36 PM David Kantowitz
> >>>> <dkantowitz at gmail.com> wrote:
> >>>>>
> >>>>> The carry-bit NCO technique is also equivalent to a 1-bit first
> >>>>> order sigma delta DAC.
> >>>>
> >>>>
> >>>> Sorry,what carry-bit NCO technique? The word "carry" isn't mentioned
> >>>> before your email.
> >>>>
> >>>>>
> >>>>> Probably doesn't make it much easier to understand, but it does
> >>>>> make the design conclusions from sigma delta usable.  Ex. noise
> >>>>> shaping curves, required Over Sampling Rates vs ENOB,
> >>>>> reconstruction filtering (see:
> >>>>> https://en.wikipedia.org/wiki/Delta-sigma_modulation).
> >>>>>
> >>>>> To help myself visualize this, I plotted the output bit patterns
> >>>>> for each input level.  Both modulation algorithms (1-bit carry NCO
> >>>>> and SD-1) produced the same chart.
> >>>>>
> >>>>> DC level is y-axis, time is x-axis.
> >>>>
> >>>>
> >>>> I'm having trouble understanding these graphs. What's going on in
> >>>> them? "DC level is y-axis" doesn't seem to make sense in a plot that
> >>>> has multiple y values per one x value. What am I missing here?
> >>>>
> >>>>>
> >>>>> <image.png>
> >>>>> Repeated 4 times to help imagine the oversampling:
> >>>>> <image.png>
> >>>>>
> >>>>> For comparison basic PWM looks like:
> >>>>> <image.png>
> >>>>>
> >>>>> By looking across a horizontal line, you can easily see the
> >>>>> carry-bit approach has a vast reduction in low frequency content
> >>>>> compared to PWM.  That is, the digital signal 'noise' is being
> >>>>> pushed into higher frequencies.  However, there's still plenty of
> >>>>> repeating pattern in the NCO/SD-1
> >>>>>
> >>>>>
> >>>>> On Fri, Dec 8, 2023 at 1:43 PM Tom Wiltshire
> >>>>> <tom at electricdruid.net> wrote:
> >>>>>>
> >>>>>> Honestly, it's not. It's just that damn simple. The version I
> >>>>>> actually wrote was all hardware module set-up specific to the
> >>>>>> device, and basically nothing else, so wouldn't tell you anything.
> >>>>>> Turning it all into software loses a lot of the benefit, so
> >>>>>> doesn't make much sense, except to explain it.
> >>>>>>
> >>>>>> Play with some NCOs a bit, and then get them to make a single
> >>>>>> pulse when they wrap. And then - Bingo! You're there!
> >>>>>>
> >>>>>> If you thought something was missing, what exactly? Ask a more
> >>>>>> specific question and perhaps I can help fill in a blank. I well
> >>>>>> remember how weird this stuff seemed when I first met it, so I
> >>>>>> think I understand the position you're in now.
> >>>>>>
> >>>>>>
> >>>>>> > On 8 Dec 2023, at 21:18, cheater cheater <
> cheater00social at gmail.com> wrote:
> >>>>>> >
> >>>>>> > I don't get it. Most of the algorithm is missing.
> >>>>>> >
> >>>>>> > On Fri, Dec 8, 2023 at 10:07 PM Tom Wiltshire <
> tom at electricdruid.net> wrote:
> >>>>>> >>
> >>>>>> >>
> >>>>>> >>
> >>>>>> >> On 8 Dec 2023, at 20:30, cheater cheater <
> cheater00social at gmail.com> wrote:
> >>>>>> >>
> >>>>>> >> On Fri, Dec 8, 2023 at 5:06 PM Tom Wiltshire <
> tom at electricdruid.net> wrote:
> >>>>>> >>
> >>>>>> >>
> >>>>>> >>
> >>>>>> >>
> >>>>>> >> On 8 Dec 2023, at 14:41, Matthew Skala via Synth-diy <
> synth-diy at synth-diy.org> wrote:
> >>>>>> >>
> >>>>>> >> If PDM means PWM with bit-reversal before the comparison (such
> as Richie
> >>>>>> >> describes), then it does indeed lock you into a lower sampling
> rate, and
> >>>>>> >> that's one reason I skipped describing *that* technique.  But
> PWM with
> >>>>>> >> bit-reversal seems not to be what you mean when you say PDM.
> >>>>>> >>
> >>>>>> >>
> >>>>>> >> That's not what I meant when I said PDM, certainly.
> >>>>>> >>
> >>>>>> >> The way I generated it is using an NCO. The NCO generates a
> single-shot output pulse everytime the phase accumulator wraps.
> >>>>>> >>
> >>>>>> >> Now consider what happens with a simple 8-bit NCO. If our
> frequency increment is 2, for example, we get a single output pulse every
> 128 clocks, or 2 pulses per 256 clocks. Notice that they will be nicely
> spaced apart, not next to each other like PWM. The output frequency would
> be (clock frequency / 128) in this situation.
> >>>>>> >> If the increment is 8, we get a output pulse every 32 clocks, 8
> pulses per 256 clocks, and again, they're nicely spaced out. The output
> frequency is now up to (clock /32) so there's been a big improvement, just
> by getting away from those extreme values a little bit.
> >>>>>> >> As the increment climbs, the accumulator wraps more and more
> often. At freq=128, every other clock is an output and we reach our maximum
> output frequency of (clock/2). As the increment goes above half, we start
> staying high for more than a single pulse, and the waveform effectively
> turns the other way up and we get a mirror image of the effect we've seen
> from 0-128.
> >>>>>> >>
> >>>>>> >> HTH,
> >>>>>> >> Tom
> >>>>>> >>
> >>>>>> >>
> >>>>>> >> I've read this a few times but I'm struggling to understand
> what's
> >>>>>> >> going on. Can someone type out an algorithm or something like
> that?
> >>>>>> >> Would appreciate it a lot. Thanks.
> >>>>>> >>
> >>>>>> >>
> >>>>>> >> Ok, it'd look something like this:
> >>>>>> >>
> >>>>>> >> phase: 16-bit variable (for example)
> >>>>>> >> freq: 16-bit variable (same as phase)
> >>>>>> >>
> >>>>>> >> So we do:
> >>>>>> >>
> >>>>>> >> // Increment phase accumulator
> >>>>>> >> phase = phase + freq
> >>>>>> >>
> >>>>>> >> // Did phase wraparound?
> >>>>>> >> If (phase>65535) { // There are probably better ways to do this
> test, if it's even required.
> >>>>>> >> // Ok, phase wrapped
> >>>>>> >> phase = phase % 65536
> >>>>>> >> // output a pulse a single clock in length
> >>>>>> >> <this is implementation dependent!>
> >>>>>> >> }
> >>>>>> >>
> >>>>>> >> All you need to do is run this code at a fast clock rate and
> you're off. Of course, the better way is if you can hand some of this
> overhead to hardware, and some modern uPs include NCOs as a peripheral and
> can be set up for this "single shot pulse output" mode, which means that
> the while thing boils down to simply updating the "freq" frequency
> increment variable with your current output. It's dead simple.
> >>>>>> >>
> >>>>>> >>
> >>>>>> >> There's a page about NCOs in general on my website:
> >>>>>> >>
> >>>>>> >> https://electricdruid.net/direct-digital-synthesis/
> >>>>>> >>
> >>>>>> >> HTH,
> >>>>>> >> Tom
> >>>>>> >>
> >>>>>> >>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Synth-diy mailing list
> >>>>>> Synth-diy at synth-diy.org
> >>>>>> http://synth-diy.org/mailman/listinfo/synth-diy
> >>>>>> Selling or trading? Use marketplace at synth-diy.org
> >>
> >> ________________________________________________________
> >> This is the Synth-diy mailing list
> >> Submit email to: Synth-diy at synth-diy.org
> >> View archive at: https://synth-diy.org/pipermail/synth-diy/
> >> Check your settings at:
> >> https://synth-diy.org/mailman/listinfo/synth-diy
> >> Selling or trading? Use marketplace at synth-diy.org
> >>
> >>
> >
> > ________________________________________________________
> > This is the Synth-diy mailing list
> > Submit email to: Synth-diy at synth-diy.org
> > View archive at: https://synth-diy.org/pipermail/synth-diy/
> > Check your settings at:
> > https://synth-diy.org/mailman/listinfo/synth-diy
> > Selling or trading? Use marketplace at synth-diy.org
> ________________________________________________________
> This is the Synth-diy mailing list
> Submit email to: Synth-diy at synth-diy.org
> View archive at: https://synth-diy.org/pipermail/synth-diy/
> Check your settings at: https://synth-diy.org/mailman/listinfo/synth-diy
> Selling or trading? Use marketplace at synth-diy.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20231211/2e5143f5/attachment.htm>

More information about the Synth-diy mailing list