Forums

delta-sigma again

Started by Unknown November 16, 2019

I'm still playing with delta-sigma A/D conversion in LT Spice. I'll be
using the ADUM7703 isolated 2nd order converter, clocked at 20 MHz,
and we're thinking now about decimation filters in an FPGA.

Win was considering using a d-s encoder and an analog recovery filter.

My filter will be digital, and it will be inside a high-power control
loop. The FPGA will drive a bunch of DACs at 500 KHz each, so if our
d-s filter decimates it should deliver 500K samples per second to
avoid squirrely aliasing hazards. I'd prefer it not decimate at all. I
find the classic sinc3 recovery filter to be intellectually (ok,
emotionally) repulsive.

In the model below, the recovered sine wave is pretty clean near zero
volts and rattier at the peaks. I don't know if that's a real property
of a d-s encoder, or some Spice numerical artifact.

Side story: one of my guys was plotting the frequency redponse of our
class-D amplifier and got a nice curve with some weird, radical
hickeys. Turns out he was signal averaging on a digital scope to
remove the switching noise from the test sine wave, and reading the
scope's computed RMS voltage to plot frequency response. But with some
selected number of averaging samples, you get narrow frequency bands
where the averaging rolls the async switching frequency back into
visibility.



Version 4
SHEET 1 2236 680
WIRE 1408 -208 1360 -208
WIRE 1552 -208 1488 -208
WIRE 1584 -208 1552 -208
WIRE 1648 -208 1584 -208
WIRE 1776 -208 1728 -208
WIRE 1808 -208 1776 -208
WIRE 1840 -208 1808 -208
WIRE 1552 -160 1552 -208
WIRE 1776 -160 1776 -208
WIRE 1552 -48 1552 -96
WIRE 1776 -48 1776 -96
WIRE -32 48 -80 48
WIRE 32 48 -32 48
WIRE 176 48 112 48
WIRE 240 48 176 48
WIRE 368 48 240 48
WIRE 464 48 368 48
WIRE 640 48 560 48
WIRE 704 48 640 48
WIRE 832 48 704 48
WIRE 1088 48 832 48
WIRE 1360 48 1360 -208
WIRE 1360 48 1248 48
WIRE 1408 48 1360 48
WIRE 1552 48 1488 48
WIRE 1616 48 1552 48
WIRE 1776 48 1696 48
WIRE 1824 48 1776 48
WIRE 1856 48 1824 48
WIRE 1968 48 1936 48
WIRE 2016 48 1968 48
WIRE 1024 96 976 96
WIRE 1088 96 1024 96
WIRE -80 112 -80 48
WIRE 112 112 112 48
WIRE 368 112 368 48
WIRE 560 112 560 48
WIRE 832 112 832 48
WIRE 1552 112 1552 48
WIRE 1776 112 1776 48
WIRE 2016 112 2016 48
WIRE 32 128 32 48
WIRE 64 128 32 128
WIRE 240 128 240 48
WIRE 464 128 464 48
WIRE 512 128 464 128
WIRE 704 128 704 48
WIRE 976 128 976 96
WIRE 64 176 32 176
WIRE 512 176 464 176
WIRE 1552 224 1552 176
WIRE 1776 224 1776 176
WIRE 2016 224 2016 176
WIRE -80 240 -80 192
WIRE 112 240 112 192
WIRE 240 240 240 192
WIRE 368 240 368 192
WIRE 560 240 560 192
WIRE 704 240 704 192
WIRE 832 240 832 192
WIRE 976 240 976 208
WIRE 32 336 32 176
WIRE 464 336 464 176
WIRE 464 336 32 336
WIRE 1280 336 464 336
WIRE 1360 336 1360 48
WIRE 1360 336 1280 336
FLAG 112 240 0
FLAG 240 240 0
FLAG 560 240 0
FLAG 704 240 0
FLAG -80 240 0
FLAG 976 240 0
FLAG 368 240 0
FLAG 832 240 0
FLAG -32 48 IN
FLAG 176 48 Z1
FLAG 640 48 Z2
FLAG 1280 336 FLOP
FLAG 1024 96 CLK
FLAG 1776 224 0
FLAG 1824 48 LP1
FLAG 2016 224 0
FLAG 1968 48 LP2
FLAG 1552 224 0
FLAG 1552 -48 0
FLAG 1776 -48 0
FLAG 1808 -208 RC2
FLAG 1584 -208 RC1
SYMBOL g 112 96 R0
WINDOW 0 53 44 Left 2
WINDOW 3 58 85 Left 2
SYMATTR InstName G1
SYMATTR Value 1
SYMBOL g 560 96 R0
WINDOW 0 50 39 Left 2
WINDOW 3 61 71 Left 2
SYMATTR InstName G2
SYMATTR Value 1
SYMBOL cap 224 128 R0
WINDOW 0 52 12 Left 2
WINDOW 3 53 51 Left 2
SYMATTR InstName C1
SYMATTR Value 1�
SYMBOL cap 688 128 R0
WINDOW 0 60 9 Left 2
WINDOW 3 59 48 Left 2
SYMATTR InstName C2
SYMATTR Value 1�
SYMBOL voltage -80 96 R0
WINDOW 0 26 -8 Left 2
WINDOW 3 -16 -99 Left 2
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V1
SYMATTR Value SINE(0 0.95 5K)
SYMBOL Digital\\dflop 1168 0 R0
WINDOW 0 -23 -79 Left 2
WINDOW 3 -209 -35 Left 2
SYMATTR InstName A1
SYMATTR Value Vhigh=1 Vlow=-1  Ref=0 Rout=1u
SYMBOL voltage 976 112 R0
WINDOW 0 56 73 Left 2
WINDOW 3 28 106 Left 2
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName Vclk
SYMATTR Value SINE(0 1 20Meg)
SYMBOL res 352 96 R0
WINDOW 0 53 43 Left 2
WINDOW 3 50 79 Left 2
SYMATTR InstName R1
SYMATTR Value 1G
SYMBOL res 816 96 R0
WINDOW 0 59 38 Left 2
WINDOW 3 56 76 Left 2
SYMATTR InstName R2
SYMATTR Value 1G
SYMBOL res 1504 32 R90
WINDOW 0 72 53 VBottom 2
WINDOW 3 81 52 VTop 2
SYMATTR InstName R3
SYMATTR Value 50
SYMBOL cap 1760 112 R0
WINDOW 0 57 17 Left 2
WINDOW 3 56 48 Left 2
SYMATTR InstName C3
SYMATTR Value 22n
SYMBOL res 1952 32 R90
WINDOW 0 64 54 VBottom 2
WINDOW 3 72 53 VTop 2
SYMATTR InstName R4
SYMATTR Value 1K
SYMBOL cap 2000 112 R0
WINDOW 0 -52 30 Left 2
WINDOW 3 -45 62 Left 2
SYMATTR InstName C4
SYMATTR Value 8n
SYMBOL ind 1600 64 R270
WINDOW 0 -51 62 VTop 2
WINDOW 3 -58 60 VBottom 2
SYMATTR InstName L1
SYMATTR Value 33�
SYMBOL cap 1536 112 R0
WINDOW 0 -62 52 Left 2
WINDOW 3 -70 83 Left 2
SYMATTR InstName C5
SYMATTR Value 4.7n
SYMBOL res 1504 -224 R90
WINDOW 0 76 48 VBottom 2
WINDOW 3 84 50 VTop 2
SYMATTR InstName R5
SYMATTR Value 1K
SYMBOL cap 1536 -160 R0
WINDOW 0 52 13 Left 2
WINDOW 3 46 49 Left 2
SYMATTR InstName C6
SYMATTR Value 1.6n
SYMBOL res 1744 -224 R90
WINDOW 0 69 55 VBottom 2
WINDOW 3 79 56 VTop 2
SYMATTR InstName R6
SYMATTR Value 10K
SYMBOL cap 1760 -160 R0
WINDOW 0 67 10 Left 2
WINDOW 3 56 40 Left 2
SYMATTR InstName C7
SYMATTR Value 160p
TEXT 1064 -168 Left 2 !.tran 0 2m 0 uic
TEXT 528 -200 Left 2 ;2nd Order Delta-Sigma Modulator
TEXT 632 -72 Left 2 ;Nov 16  2019
TEXT 1848 224 Left 2 ;20 KHz
TEXT 1624 224 Left 2 ;200KHz
TEXT 1416 -72 Left 2 ;100 KHz
TEXT 1656 -72 Left 2 ;100 KHz
TEXT 520 -144 Left 2 ;J Larkin  Highland Technology Inc


-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 

On 11/16/19 12:57 PM, jlarkin@highlandsniptechnology.com wrote:
> > > I'm still playing with delta-sigma A/D conversion in LT Spice. I'll be > using the ADUM7703 isolated 2nd order converter, clocked at 20 MHz, > and we're thinking now about decimation filters in an FPGA. > > Win was considering using a d-s encoder and an analog recovery filter. > > My filter will be digital, and it will be inside a high-power control > loop. The FPGA will drive a bunch of DACs at 500 KHz each, so if our > d-s filter decimates it should deliver 500K samples per second to > avoid squirrely aliasing hazards. I'd prefer it not decimate at all. I > find the classic sinc3 recovery filter to be intellectually (ok, > emotionally) repulsive.
Can you clock at say 16 MHz and then use a cascade of five half-band filter/decimators after each stage to get down to 500k? it's pretty efficient because half the taps of each filter have a zero coefficient and the tap requirements decrease as you go up the chain in frequency <https://www.dsprelated.com/showarticle/903.php> This approach worked well for my wideband phase-shifter project a while back to get a near perfect 90 degree phase shift over the 300-4kHz audio band with only like 800 taps on the FIR Hilbert transformer when the signal was digitized at 96kHz, and about 40 more taps for a cascade of 3 half-band decimators to bring the effective sample rate down to 12kHz. Then I upsample and interpolate back to the system sampling rate for the DAC
> In the model below, the recovered sine wave is pretty clean near zero > volts and rattier at the peaks. I don't know if that's a real property > of a d-s encoder, or some Spice numerical artifact. > > Side story: one of my guys was plotting the frequency redponse of our > class-D amplifier and got a nice curve with some weird, radical > hickeys. Turns out he was signal averaging on a digital scope to > remove the switching noise from the test sine wave, and reading the > scope's computed RMS voltage to plot frequency response. But with some > selected number of averaging samples, you get narrow frequency bands > where the averaging rolls the async switching frequency back into > visibility.
On Sun, 17 Nov 2019 07:01:20 -0500, bitrex <user@example.net> wrote:

>On 11/16/19 12:57 PM, jlarkin@highlandsniptechnology.com wrote: >> >> >> I'm still playing with delta-sigma A/D conversion in LT Spice. I'll be >> using the ADUM7703 isolated 2nd order converter, clocked at 20 MHz, >> and we're thinking now about decimation filters in an FPGA. >> >> Win was considering using a d-s encoder and an analog recovery filter. >> >> My filter will be digital, and it will be inside a high-power control >> loop. The FPGA will drive a bunch of DACs at 500 KHz each, so if our >> d-s filter decimates it should deliver 500K samples per second to >> avoid squirrely aliasing hazards. I'd prefer it not decimate at all. I >> find the classic sinc3 recovery filter to be intellectually (ok, >> emotionally) repulsive. > >Can you clock at say 16 MHz and then use a cascade of five half-band >filter/decimators after each stage to get down to 500k? it's pretty >efficient because half the taps of each filter have a zero coefficient >and the tap requirements decrease as you go up the chain in frequency > ><https://www.dsprelated.com/showarticle/903.php> > >This approach worked well for my wideband phase-shifter project a while >back to get a near perfect 90 degree phase shift over the 300-4kHz audio >band with only like 800 taps on the FIR Hilbert transformer when the >signal was digitized at 96kHz, and about 40 more taps for a cascade of 3 >half-band decimators to bring the effective sample rate down to 12kHz. >Then I upsample and interpolate back to the system sampling rate for the DAC >
Why decimate at all? To reduce the width of the data words? I can simulate an R-C lowpass in one line of code, or a similarly simple chunk of FPGA hardware. I'd probably use 32 bit variables, which is easy. I could simulate my dumb RC-RC filter. That would make an IIR filter, which for some reason is not popular in FPGAs. I do want a filter that won't create aliases, namely one that rolls off and stays rolled off. -- John Larkin Highland Technology, Inc lunatic fringe electronics
On Sunday, November 17, 2019 at 10:27:44 AM UTC-5, jla...@highlandsniptechnology.com wrote:
> On Sun, 17 Nov 2019 07:01:20 -0500, bitrex <user@example.net> wrote: > > >On 11/16/19 12:57 PM, jlarkin@highlandsniptechnology.com wrote: > >> > >> > >> I'm still playing with delta-sigma A/D conversion in LT Spice. I'll be > >> using the ADUM7703 isolated 2nd order converter, clocked at 20 MHz, > >> and we're thinking now about decimation filters in an FPGA. > >> > >> Win was considering using a d-s encoder and an analog recovery filter. > >> > >> My filter will be digital, and it will be inside a high-power control > >> loop. The FPGA will drive a bunch of DACs at 500 KHz each, so if our > >> d-s filter decimates it should deliver 500K samples per second to > >> avoid squirrely aliasing hazards. I'd prefer it not decimate at all. I > >> find the classic sinc3 recovery filter to be intellectually (ok, > >> emotionally) repulsive. > > > >Can you clock at say 16 MHz and then use a cascade of five half-band > >filter/decimators after each stage to get down to 500k? it's pretty > >efficient because half the taps of each filter have a zero coefficient > >and the tap requirements decrease as you go up the chain in frequency > > > ><https://www.dsprelated.com/showarticle/903.php> > > > >This approach worked well for my wideband phase-shifter project a while > >back to get a near perfect 90 degree phase shift over the 300-4kHz audio > >band with only like 800 taps on the FIR Hilbert transformer when the > >signal was digitized at 96kHz, and about 40 more taps for a cascade of 3 > >half-band decimators to bring the effective sample rate down to 12kHz. > >Then I upsample and interpolate back to the system sampling rate for the DAC > > > > Why decimate at all? To reduce the width of the data words? > > I can simulate an R-C lowpass in one line of code, or a similarly > simple chunk of FPGA hardware. I'd probably use 32 bit variables, > which is easy. I could simulate my dumb RC-RC filter. That would make > an IIR filter, which for some reason is not popular in FPGAs. > > I do want a filter that won't create aliases, namely one that rolls > off and stays rolled off.
Not sure what you are trying to say about "aliases". Filters don't create aliases. Decimation creates aliases. Some filters have a monotonic stop band, others have stop band ripple. Is the ripple what you are talking about? If you don't want to decimate, don't decimate. That's pretty simple. -- Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209
s&oslash;ndag den 17. november 2019 kl. 16.27.44 UTC+1 skrev jla...@highlandsniptechnology.com:
> On Sun, 17 Nov 2019 07:01:20 -0500, bitrex <user@example.net> wrote: > > >On 11/16/19 12:57 PM, jlarkin@highlandsniptechnology.com wrote: > >> > >> > >> I'm still playing with delta-sigma A/D conversion in LT Spice. I'll be > >> using the ADUM7703 isolated 2nd order converter, clocked at 20 MHz, > >> and we're thinking now about decimation filters in an FPGA. > >> > >> Win was considering using a d-s encoder and an analog recovery filter. > >> > >> My filter will be digital, and it will be inside a high-power control > >> loop. The FPGA will drive a bunch of DACs at 500 KHz each, so if our > >> d-s filter decimates it should deliver 500K samples per second to > >> avoid squirrely aliasing hazards. I'd prefer it not decimate at all. I > >> find the classic sinc3 recovery filter to be intellectually (ok, > >> emotionally) repulsive. > > > >Can you clock at say 16 MHz and then use a cascade of five half-band > >filter/decimators after each stage to get down to 500k? it's pretty > >efficient because half the taps of each filter have a zero coefficient > >and the tap requirements decrease as you go up the chain in frequency > > > ><https://www.dsprelated.com/showarticle/903.php> > > > >This approach worked well for my wideband phase-shifter project a while > >back to get a near perfect 90 degree phase shift over the 300-4kHz audio > >band with only like 800 taps on the FIR Hilbert transformer when the > >signal was digitized at 96kHz, and about 40 more taps for a cascade of 3 > >half-band decimators to bring the effective sample rate down to 12kHz. > >Then I upsample and interpolate back to the system sampling rate for the DAC > > > > Why decimate at all? To reduce the width of the data words? > > I can simulate an R-C lowpass in one line of code, or a similarly > simple chunk of FPGA hardware. I'd probably use 32 bit variables, > which is easy. I could simulate my dumb RC-RC filter. That would make > an IIR filter, which for some reason is not popular in FPGAs. > > I do want a filter that won't create aliases, namely one that rolls > off and stays rolled off.
so use a regular FIR filter
On 11/17/19 10:27 AM, jlarkin@highlandsniptechnology.com wrote:
> On Sun, 17 Nov 2019 07:01:20 -0500, bitrex <user@example.net> wrote: > >> On 11/16/19 12:57 PM, jlarkin@highlandsniptechnology.com wrote: >>> >>> >>> I'm still playing with delta-sigma A/D conversion in LT Spice. I'll be >>> using the ADUM7703 isolated 2nd order converter, clocked at 20 MHz, >>> and we're thinking now about decimation filters in an FPGA. >>> >>> Win was considering using a d-s encoder and an analog recovery filter. >>> >>> My filter will be digital, and it will be inside a high-power control >>> loop. The FPGA will drive a bunch of DACs at 500 KHz each, so if our >>> d-s filter decimates it should deliver 500K samples per second to >>> avoid squirrely aliasing hazards. I'd prefer it not decimate at all. I >>> find the classic sinc3 recovery filter to be intellectually (ok, >>> emotionally) repulsive. >> >> Can you clock at say 16 MHz and then use a cascade of five half-band >> filter/decimators after each stage to get down to 500k? it's pretty >> efficient because half the taps of each filter have a zero coefficient >> and the tap requirements decrease as you go up the chain in frequency >> >> <https://www.dsprelated.com/showarticle/903.php> >> >> This approach worked well for my wideband phase-shifter project a while >> back to get a near perfect 90 degree phase shift over the 300-4kHz audio >> band with only like 800 taps on the FIR Hilbert transformer when the >> signal was digitized at 96kHz, and about 40 more taps for a cascade of 3 >> half-band decimators to bring the effective sample rate down to 12kHz. >> Then I upsample and interpolate back to the system sampling rate for the DAC >> > > Why decimate at all? To reduce the width of the data words? > > I can simulate an R-C lowpass in one line of code, or a similarly > simple chunk of FPGA hardware. I'd probably use 32 bit variables, > which is easy. I could simulate my dumb RC-RC filter. That would make > an IIR filter, which for some reason is not popular in FPGAs. > > I do want a filter that won't create aliases, namely one that rolls > off and stays rolled off. > > >
I'll preface by saying I'm not intimately familiar with how this kind of delta-sigma converter you're making with an external analog block and doing the loop in an FPGA is supposed to operate exactly, but...it sounds like your bandwidth of interest is only to 500k but you're getting 20MHz worth of samples. you decimate because a sharp low-pass with good time-domain response at high sampling rate requires a large number of FPGA gates/compute cycles, but using a half-band filter/decimator block you perform an anti-aliasing and decimation as one unit reducing the effective sample rate, which relaxes the compute cycle requirement of the following stages. In my phase-shifter example a 90 degree phase shifter with both good frequency and phase domain response wasn't possible over the bandwidth of interest at the 96kHz fixed sampling rate whatever off-the-shelf module's converters he got were feeding the DSP with, it would require all the FIR taps than the machine had available and it still was supposed to do other tasks besides phase shift. I guess what I'm trying to say is if you have highly oversampled data already you can do better than running sinc3 over the whole bandwidth signal by cascading stages of low-pass-and-resample filters then re-calculating FIR coefficients on the following stages in the chain, at the effective halved sampling rate. It's then not hard to get a very nice low-pass response in both the time and freq domain without a lot of hyper-optimization, you can kind of ball-park how many taps each succeeding stage will need via a power law like x^1.8 the previous stage, and it works out pretty good 20 minutes in Matlab can get there.
On Sun, 17 Nov 2019 08:01:49 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

>s&#2013266168;ndag den 17. november 2019 kl. 16.27.44 UTC+1 skrev jla...@highlandsniptechnology.com: >> On Sun, 17 Nov 2019 07:01:20 -0500, bitrex <user@example.net> wrote: >> >> >On 11/16/19 12:57 PM, jlarkin@highlandsniptechnology.com wrote: >> >> >> >> >> >> I'm still playing with delta-sigma A/D conversion in LT Spice. I'll be >> >> using the ADUM7703 isolated 2nd order converter, clocked at 20 MHz, >> >> and we're thinking now about decimation filters in an FPGA. >> >> >> >> Win was considering using a d-s encoder and an analog recovery filter. >> >> >> >> My filter will be digital, and it will be inside a high-power control >> >> loop. The FPGA will drive a bunch of DACs at 500 KHz each, so if our >> >> d-s filter decimates it should deliver 500K samples per second to >> >> avoid squirrely aliasing hazards. I'd prefer it not decimate at all. I >> >> find the classic sinc3 recovery filter to be intellectually (ok, >> >> emotionally) repulsive. >> > >> >Can you clock at say 16 MHz and then use a cascade of five half-band >> >filter/decimators after each stage to get down to 500k? it's pretty >> >efficient because half the taps of each filter have a zero coefficient >> >and the tap requirements decrease as you go up the chain in frequency >> > >> ><https://www.dsprelated.com/showarticle/903.php> >> > >> >This approach worked well for my wideband phase-shifter project a while >> >back to get a near perfect 90 degree phase shift over the 300-4kHz audio >> >band with only like 800 taps on the FIR Hilbert transformer when the >> >signal was digitized at 96kHz, and about 40 more taps for a cascade of 3 >> >half-band decimators to bring the effective sample rate down to 12kHz. >> >Then I upsample and interpolate back to the system sampling rate for the DAC >> > >> >> Why decimate at all? To reduce the width of the data words? >> >> I can simulate an R-C lowpass in one line of code, or a similarly >> simple chunk of FPGA hardware. I'd probably use 32 bit variables, >> which is easy. I could simulate my dumb RC-RC filter. That would make >> an IIR filter, which for some reason is not popular in FPGAs. >> >> I do want a filter that won't create aliases, namely one that rolls >> off and stays rolled off. > >so use a regular FIR filter
I'm looking at nearly a 1000:1 clock to cutoff ratio. That would be a giant FIR. Again, why not use an integrator-based IIR? Essentially simulate a state-variable filter, or in my case two cascaded RC lowpasses? B = B + K1 * (In-B) Out = Out + K2 * (B - Out) which in my case runs at 20 MHz, the delta-sigma clock rate. If you get lucky, the multiplies can just be right shifts (the Ks will be small) but in a modern FPGA, MAC blocks are free so we may as well do real multiplies. I've done this in software several times, and it works fine, but FPGA guys seem to be hostile to IIR filters. Too simple to be much fun, I assume. -- John Larkin Highland Technology, Inc lunatic fringe electronics
On Sun, 17 Nov 2019 11:36:12 -0500, bitrex <user@example.net> wrote:

>On 11/17/19 10:27 AM, jlarkin@highlandsniptechnology.com wrote: >> On Sun, 17 Nov 2019 07:01:20 -0500, bitrex <user@example.net> wrote: >> >>> On 11/16/19 12:57 PM, jlarkin@highlandsniptechnology.com wrote: >>>> >>>> >>>> I'm still playing with delta-sigma A/D conversion in LT Spice. I'll be >>>> using the ADUM7703 isolated 2nd order converter, clocked at 20 MHz, >>>> and we're thinking now about decimation filters in an FPGA. >>>> >>>> Win was considering using a d-s encoder and an analog recovery filter. >>>> >>>> My filter will be digital, and it will be inside a high-power control >>>> loop. The FPGA will drive a bunch of DACs at 500 KHz each, so if our >>>> d-s filter decimates it should deliver 500K samples per second to >>>> avoid squirrely aliasing hazards. I'd prefer it not decimate at all. I >>>> find the classic sinc3 recovery filter to be intellectually (ok, >>>> emotionally) repulsive. >>> >>> Can you clock at say 16 MHz and then use a cascade of five half-band >>> filter/decimators after each stage to get down to 500k? it's pretty >>> efficient because half the taps of each filter have a zero coefficient >>> and the tap requirements decrease as you go up the chain in frequency >>> >>> <https://www.dsprelated.com/showarticle/903.php> >>> >>> This approach worked well for my wideband phase-shifter project a while >>> back to get a near perfect 90 degree phase shift over the 300-4kHz audio >>> band with only like 800 taps on the FIR Hilbert transformer when the >>> signal was digitized at 96kHz, and about 40 more taps for a cascade of 3 >>> half-band decimators to bring the effective sample rate down to 12kHz. >>> Then I upsample and interpolate back to the system sampling rate for the DAC >>> >> >> Why decimate at all? To reduce the width of the data words? >> >> I can simulate an R-C lowpass in one line of code, or a similarly >> simple chunk of FPGA hardware. I'd probably use 32 bit variables, >> which is easy. I could simulate my dumb RC-RC filter. That would make >> an IIR filter, which for some reason is not popular in FPGAs. >> >> I do want a filter that won't create aliases, namely one that rolls >> off and stays rolled off. >> >> >> > >I'll preface by saying I'm not intimately familiar with how this kind of >delta-sigma converter you're making with an external analog block and >doing the loop in an FPGA is supposed to operate exactly, but...it >sounds like your bandwidth of interest is only to 500k but you're >getting 20MHz worth of samples.
Given the hardware realities, it looks like my loop bandwidth will be in the ballpark of 50 KHz. I'll have a 250 watt sine wave source that I want to program the impedance of. I can do some of that with a real inductor, and synthesize the rest.
> >you decimate because a sharp low-pass with good time-domain response at >high sampling rate requires a large number of FPGA gates/compute cycles, >but using a half-band filter/decimator block you perform an >anti-aliasing and decimation as one unit reducing the effective sample >rate, which relaxes the compute cycle requirement of the following stages. > >In my phase-shifter example a 90 degree phase shifter with both good >frequency and phase domain response wasn't possible over the bandwidth >of interest at the 96kHz fixed sampling rate whatever off-the-shelf >module's converters he got were feeding the DSP with, it would require >all the FIR taps than the machine had available and it still was >supposed to do other tasks besides phase shift. > >I guess what I'm trying to say is if you have highly oversampled data >already you can do better than running sinc3 over the whole bandwidth >signal by cascading stages of low-pass-and-resample filters then >re-calculating FIR coefficients on the following stages in the chain, at >the effective halved sampling rate. > >It's then not hard to get a very nice low-pass response in both the time >and freq domain without a lot of hyper-optimization, you can kind of >ball-park how many taps each succeeding stage will need via a power law >like x^1.8 the previous stage, and it works out pretty good 20 minutes >in Matlab can get there.
Why not a simple IIR filter clocked at 20 MHz? I don't understand why that is rarely done. -- John Larkin Highland Technology, Inc lunatic fringe electronics
On 11/17/19 11:49 AM, jlarkin@highlandsniptechnology.com wrote:
> On Sun, 17 Nov 2019 08:01:49 -0800 (PST), Lasse Langwadt Christensen > <langwadt@fonz.dk> wrote: > >> s&oslash;ndag den 17. november 2019 kl. 16.27.44 UTC+1 skrev jla...@highlandsniptechnology.com: >>> On Sun, 17 Nov 2019 07:01:20 -0500, bitrex <user@example.net> wrote: >>> >>>> On 11/16/19 12:57 PM, jlarkin@highlandsniptechnology.com wrote: >>>>> >>>>> >>>>> I'm still playing with delta-sigma A/D conversion in LT Spice. I'll be >>>>> using the ADUM7703 isolated 2nd order converter, clocked at 20 MHz, >>>>> and we're thinking now about decimation filters in an FPGA. >>>>> >>>>> Win was considering using a d-s encoder and an analog recovery filter. >>>>> >>>>> My filter will be digital, and it will be inside a high-power control >>>>> loop. The FPGA will drive a bunch of DACs at 500 KHz each, so if our >>>>> d-s filter decimates it should deliver 500K samples per second to >>>>> avoid squirrely aliasing hazards. I'd prefer it not decimate at all. I >>>>> find the classic sinc3 recovery filter to be intellectually (ok, >>>>> emotionally) repulsive. >>>> >>>> Can you clock at say 16 MHz and then use a cascade of five half-band >>>> filter/decimators after each stage to get down to 500k? it's pretty >>>> efficient because half the taps of each filter have a zero coefficient >>>> and the tap requirements decrease as you go up the chain in frequency >>>> >>>> <https://www.dsprelated.com/showarticle/903.php> >>>> >>>> This approach worked well for my wideband phase-shifter project a while >>>> back to get a near perfect 90 degree phase shift over the 300-4kHz audio >>>> band with only like 800 taps on the FIR Hilbert transformer when the >>>> signal was digitized at 96kHz, and about 40 more taps for a cascade of 3 >>>> half-band decimators to bring the effective sample rate down to 12kHz. >>>> Then I upsample and interpolate back to the system sampling rate for the DAC >>>> >>> >>> Why decimate at all? To reduce the width of the data words? >>> >>> I can simulate an R-C lowpass in one line of code, or a similarly >>> simple chunk of FPGA hardware. I'd probably use 32 bit variables, >>> which is easy. I could simulate my dumb RC-RC filter. That would make >>> an IIR filter, which for some reason is not popular in FPGAs. >>> >>> I do want a filter that won't create aliases, namely one that rolls >>> off and stays rolled off. >> >> so use a regular FIR filter > > I'm looking at nearly a 1000:1 clock to cutoff ratio. That would be a > giant FIR.
Filter and re-sample in stages!
> Again, why not use an integrator-based IIR? Essentially simulate a > state-variable filter, or in my case two cascaded RC lowpasses? > > B = B + K1 * (In-B) > > Out = Out + K2 * (B - Out) > > which in my case runs at 20 MHz, the delta-sigma clock rate. > > If you get lucky, the multiplies can just be right shifts (the Ks will > be small) but in a modern FPGA, MAC blocks are free so we may as well > do real multiplies. > > I've done this in software several times, and it works fine, but FPGA > guys seem to be hostile to IIR filters. Too simple to be much fun, I > assume.
FIRs can be designed and optimized using out-of-the-box functions in Matlab's signal processing toolkit there's not a great challenge to it once you settle on the requirements and a processing chain for the application. that's nice for people who like to get shit done
On 11/17/19 11:56 AM, jlarkin@highlandsniptechnology.com wrote:
> On Sun, 17 Nov 2019 11:36:12 -0500, bitrex <user@example.net> wrote: > >> On 11/17/19 10:27 AM, jlarkin@highlandsniptechnology.com wrote: >>> On Sun, 17 Nov 2019 07:01:20 -0500, bitrex <user@example.net> wrote: >>> >>>> On 11/16/19 12:57 PM, jlarkin@highlandsniptechnology.com wrote: >>>>> >>>>> >>>>> I'm still playing with delta-sigma A/D conversion in LT Spice. I'll be >>>>> using the ADUM7703 isolated 2nd order converter, clocked at 20 MHz, >>>>> and we're thinking now about decimation filters in an FPGA. >>>>> >>>>> Win was considering using a d-s encoder and an analog recovery filter. >>>>> >>>>> My filter will be digital, and it will be inside a high-power control >>>>> loop. The FPGA will drive a bunch of DACs at 500 KHz each, so if our >>>>> d-s filter decimates it should deliver 500K samples per second to >>>>> avoid squirrely aliasing hazards. I'd prefer it not decimate at all. I >>>>> find the classic sinc3 recovery filter to be intellectually (ok, >>>>> emotionally) repulsive. >>>> >>>> Can you clock at say 16 MHz and then use a cascade of five half-band >>>> filter/decimators after each stage to get down to 500k? it's pretty >>>> efficient because half the taps of each filter have a zero coefficient >>>> and the tap requirements decrease as you go up the chain in frequency >>>> >>>> <https://www.dsprelated.com/showarticle/903.php> >>>> >>>> This approach worked well for my wideband phase-shifter project a while >>>> back to get a near perfect 90 degree phase shift over the 300-4kHz audio >>>> band with only like 800 taps on the FIR Hilbert transformer when the >>>> signal was digitized at 96kHz, and about 40 more taps for a cascade of 3 >>>> half-band decimators to bring the effective sample rate down to 12kHz. >>>> Then I upsample and interpolate back to the system sampling rate for the DAC >>>> >>> >>> Why decimate at all? To reduce the width of the data words? >>> >>> I can simulate an R-C lowpass in one line of code, or a similarly >>> simple chunk of FPGA hardware. I'd probably use 32 bit variables, >>> which is easy. I could simulate my dumb RC-RC filter. That would make >>> an IIR filter, which for some reason is not popular in FPGAs. >>> >>> I do want a filter that won't create aliases, namely one that rolls >>> off and stays rolled off. >>> >>> >>> >> >> I'll preface by saying I'm not intimately familiar with how this kind of >> delta-sigma converter you're making with an external analog block and >> doing the loop in an FPGA is supposed to operate exactly, but...it >> sounds like your bandwidth of interest is only to 500k but you're >> getting 20MHz worth of samples. > > Given the hardware realities, it looks like my loop bandwidth will be > in the ballpark of 50 KHz. I'll have a 250 watt sine wave source that > I want to program the impedance of. I can do some of that with a real > inductor, and synthesize the rest. > >> >> you decimate because a sharp low-pass with good time-domain response at >> high sampling rate requires a large number of FPGA gates/compute cycles, >> but using a half-band filter/decimator block you perform an >> anti-aliasing and decimation as one unit reducing the effective sample >> rate, which relaxes the compute cycle requirement of the following stages. >> >> In my phase-shifter example a 90 degree phase shifter with both good >> frequency and phase domain response wasn't possible over the bandwidth >> of interest at the 96kHz fixed sampling rate whatever off-the-shelf >> module's converters he got were feeding the DSP with, it would require >> all the FIR taps than the machine had available and it still was >> supposed to do other tasks besides phase shift. >> >> I guess what I'm trying to say is if you have highly oversampled data >> already you can do better than running sinc3 over the whole bandwidth >> signal by cascading stages of low-pass-and-resample filters then >> re-calculating FIR coefficients on the following stages in the chain, at >> the effective halved sampling rate. >> >> It's then not hard to get a very nice low-pass response in both the time >> and freq domain without a lot of hyper-optimization, you can kind of >> ball-park how many taps each succeeding stage will need via a power law >> like x^1.8 the previous stage, and it works out pretty good 20 minutes >> in Matlab can get there. > > Why not a simple IIR filter clocked at 20 MHz? I don't understand why > that is rarely done. >
Usually people don't have the luxury of such a large oversampling bandwidth with respect to the pass band, and finding the optimal analog prototype for an IIR for a more bandwidth constrained situation can be difficult same as designing analog feedback filters. With FIR you can use tools that given a set of requirements can quickly compute the optimal coefficients and assure you that it's the mathematically-best you can get for those specs. On resource-constrained processors or when the delay introduced by a long FIR is unacceptable sometimes you must go IIR to get a job done. If you have a 1000:1 sampling to bandwith ratio and a two pole RCRC IIR prototype or something gives you the response you need yes, why not but 1000:1 is very luxurious :)