Reply by June 15, 20152015-06-15
On Monday, June 15, 2015 at 1:44:51 PM UTC-4, John Larkin wrote:
> On Sun, 14 Jun 2015 20:37:29 -0700 (PDT), dagmargoo...@yahoo.com > wrote: > >On Friday, May 29, 2015 at 10:19:04 AM UTC-4, John Larkin wrote: > >> On 29 May 2015 05:54:35 -0700, Winfield Hill wrote: > >> > >> >Bill Sloman wrote... > >> >> > >> >> John Larkin wrote: > >> >>> > >> >>> I need an isolated analog output (many of them, actually) > >> >>> with, say, 1 PPM programmability and linearity. An > >> >>> optocoupled DAC would be silly, so I'll use PWM. > >> > > >> >>> The average value will be disturbed by the rise and > >> >>> fall times of the optocoupler (or whatever) so > >> >>> getting to 1 PPM linearity is scary.) > >> >> > >> >> There are more sources of potential linearity error at > >> >> the 1ppm level than just differences between rise and > >> >> fall times. > >> > > >> > It's actually the overall ON vs OFF delay times, > >> > rather than rise time alone. The on vs off delays > >> > are often quite different for optical-couplers and > >> > drivers, but they're generally fairly stable and > >> > repeatable. It'd be easy to add adjustable fixed > >> > delays to both the on and off times, so they could > >> > be trimmed to be more or less the same. I'll bet > >> > a given choice of components in a production run > >> > would have pretty closely matched delays; measure > >> > one and apply the delay components to the rest. > >> > >> Yeah, the bottom line problem with D-S is on/off asymmetry, which > >> makes errors at high, and essentially random, pulse rates. But I > >> wouldn't want to attempt to tune it out. > >> > >> 1 0 1 0 has 8 edges, whereas 1 1 0 0 has only 4, so they won't > >> average the same. Delta-sigma generates too many cases. The IC boys > >> must do tricks to make D-S ICs as good as they are. > >> > >> The clustered/boogered PWM always has the same, small number of edges, > >> so will always be monotonic and noise-free. > >> > >> It's really not worth trying to de-cluster the wider pulses, ie > >> > >> 50001 50000 50001 50000 ON versus > >> 50001 50001 50000 50000 > >> > >> since the difference in ripple is a couple PPMs, and the lowpass > >> filter will kill that tiny residual ripple. > >> > >> There probably *is* some tricky math algorithm to evenly disperse the > >> N+1 pulses, some bit-field reversal or something, sort of a Van der > >> Corput sequence thing. My guys will get into that math fun, even if > >> it's unnecessary. > > > > > >The ripple waveform for a given code is known. Why not S/H the > >filtered PWM waveform, sampling at the precise time the waveform > >is/will be at the correct voltage for that code? > > It's hard to make a really accurate and stable s/h. And it's a bunch > of parts. > > I may just use the DAC1220 and feed it clk/data/stb through a quad > isolator, and not do the ADC feedback. But the goofy PWM was fun to > think about.
It's hard to compete with the DAC1220 for parts count. The PWM's advantage would be $6-$7 per channel savings. The DAC1220 makes sense. You can crank it out, no delay, no technical risk. And if you sell zillions, we'll make you a nice PWM version. Cheers, James
Reply by John Larkin June 15, 20152015-06-15
On Sun, 14 Jun 2015 20:37:29 -0700 (PDT), dagmargoodboat@yahoo.com
wrote:

>On Friday, May 29, 2015 at 10:19:04 AM UTC-4, John Larkin wrote: >> On 29 May 2015 05:54:35 -0700, Winfield Hill wrote: >> >> >Bill Sloman wrote... >> >> >> >> John Larkin wrote: >> >>> >> >>> I need an isolated analog output (many of them, actually) >> >>> with, say, 1 PPM programmability and linearity. An >> >>> optocoupled DAC would be silly, so I'll use PWM. >> > >> >>> The average value will be disturbed by the rise and >> >>> fall times of the optocoupler (or whatever) so >> >>> getting to 1 PPM linearity is scary.) >> >> >> >> There are more sources of potential linearity error at >> >> the 1ppm level than just differences between rise and >> >> fall times. >> > >> > It's actually the overall ON vs OFF delay times, >> > rather than rise time alone. The on vs off delays >> > are often quite different for optical-couplers and >> > drivers, but they're generally fairly stable and >> > repeatable. It'd be easy to add adjustable fixed >> > delays to both the on and off times, so they could >> > be trimmed to be more or less the same. I'll bet >> > a given choice of components in a production run >> > would have pretty closely matched delays; measure >> > one and apply the delay components to the rest. >> >> Yeah, the bottom line problem with D-S is on/off asymmetry, which >> makes errors at high, and essentially random, pulse rates. But I >> wouldn't want to attempt to tune it out. >> >> 1 0 1 0 has 8 edges, whereas 1 1 0 0 has only 4, so they won't >> average the same. Delta-sigma generates too many cases. The IC boys >> must do tricks to make D-S ICs as good as they are. >> >> The clustered/boogered PWM always has the same, small number of edges, >> so will always be monotonic and noise-free. >> >> It's really not worth trying to de-cluster the wider pulses, ie >> >> 50001 50000 50001 50000 ON versus >> 50001 50001 50000 50000 >> >> since the difference in ripple is a couple PPMs, and the lowpass >> filter will kill that tiny residual ripple. >> >> There probably *is* some tricky math algorithm to evenly disperse the >> N+1 pulses, some bit-field reversal or something, sort of a Van der >> Corput sequence thing. My guys will get into that math fun, even if >> it's unnecessary. > > >The ripple waveform for a given code is known. Why not S/H the >filtered PWM waveform, sampling at the precise time the waveform >is/will be at the correct voltage for that code?
It's hard to make a really accurate and stable s/h. And it's a bunch of parts. I may just use the DAC1220 and feed it clk/data/stb through a quad isolator, and not do the ADC feedback. But the goofy PWM was fun to think about. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by Bill Sloman June 15, 20152015-06-15
On Saturday, May 30, 2015 at 6:00:53 AM UTC+2, Jasen Betts wrote:
> On 2015-05-30, Bill Sloman <bill.sloman@ieee.org> wrote: > > On 30/05/2015 9:20 AM, Jasen Betts wrote: > >> On 2015-05-29, John Larkin <jlarkin@highlandtechnology.com> wrote: > >>> On 29 May 2015 05:54:35 -0700, Winfield Hill > >>> <hill@rowland.harvard.edu> wrote: > >>>> Bill Sloman wrote... > >>>>> John Larkin wrote: > >>>>>> > >>>>>> I need an isolated analog output (many of them, actually) > >>>>>> with, say, 1 PPM programmability and linearity. An > >>>>>> optocoupled DAC would be silly, so I'll use PWM. > >>>> > >>>>>> The average value will be disturbed by the rise and > >>>>>> fall times of the optocoupler (or whatever) so > >>>>>> getting to 1 PPM linearity is scary.) > >>>>> > >>>>> There are more sources of potential linearity error at > >>>>> the 1ppm level than just differences between rise and > >>>>> fall times. > >>>> > >>>> It's actually the overall ON vs OFF delay times, > >>>> rather than rise time alone. The on vs off delays > >>>> are often quite different for optical-couplers and > >>>> drivers, but they're generally fairly stable and > >>>> repeatable. It'd be easy to add adjustable fixed > >>>> delays to both the on and off times, so they could > >>>> be trimmed to be more or less the same. I'll bet > >>>> a given choice of components in a production run > >>>> would have pretty closely matched delays; measure > >>>> one and apply the delay components to the rest. > >>> > >>> Yeah, the bottom line problem with D-S is on/off asymmetry, which > >>> makes errors at high, and essentially random, pulse rates. But I > >>> wouldn't want to attempt to tune it out. > >>> > >>> 1 0 1 0 has 8 edges, whereas 1 1 0 0 has only 4, so they won't > >>> average the same. Delta-sigma generates too many cases. The IC boys > >>> must do tricks to make D-S ICs as good as they are. > >> > >> ??? I count 4 and and 2 not 8 and 4 > >> > >>> The clustered/boogered PWM always has the same, small number of edges, > >>> so will always be monotonic and noise-free. > >>> > >>> It's really not worth trying to de-cluster the wider pulses, ie > >>> > >>> 50001 50000 50001 50000 ON versus > >>> 50001 50001 50000 50000 > >>> > >>> since the difference in ripple is a couple PPMs, and the lowpass > >>> filter will kill that tiny residual ripple. > >>> > >>> There probably *is* some tricky math algorithm to evenly disperse the > >>> N+1 pulses, some bit-field reversal or something, sort of a Van der > >>> Corput sequence thing. My guys will get into that math fun, even if > >>> it's unnecessary. > >> > >> pure bit field reversal gives an effect a bit like a delta-sigma, most > >> of the noise goes into the high frequencies but the number of transitions > >> is variable. burkes dither used to convert photos one bit depth works > >> like that. > >> > >> If you want a fixed number of transitions > >> > >> pick how many sub-fields you want in your modified PWM and then > >> shift your counter output log_2 that many bits leftwards, reverse > >> the order of the bits that overflowed and insert them into the > >> vacated spots on the right, > >> > >> so for an n bit counter to be split into 8 > >> > >>b n n-3 > >> n-1 .... > >> n-2 ----\ 3 > >> n-3 \ 2 > >> ... / 1 > >> 3 -----/ 0 > >> 2 n-2 > >> 1 n-1 > >> 0 n > > I was diagramming the transformation to make to the clock > my second column is the order the go into the comparitor > > > > My scheme was to reverse just the top four bits of the 10-bit counter output > > > > Counter Comparator > > > > 6 \ 10 > > 7 \ 9 > > 8 \ 8 > > 9 / 7 > > 10 / 6 > > 5 5 > > 4 4 > > 3 3 > > 2 2 > > 1 1 > > > > which gave 16x more transitions, and a well defined maximum transition rate. > > that looks like it would give mismatched pulse lengths: most of the of the 32 > slices would be either full or empty. > > What I have done is reverse all the bits which gives maximum > deterministic dither at the cost of an umpredictable number of edges > per cycle, but then un-reverse the least-signifigant bits to limit the > number of edges. so long as he programme input stays in the middle of > of its range (does fill or empty all its high-order bits there will be > a predictable number of transitions (2^(b+1)) for b bits moved.
I believe that's exactly what I described back in 1996, and more recently here. -- Bill Sloman, Sydney
Reply by Bill Sloman June 15, 20152015-06-15
On Saturday, May 30, 2015 at 6:00:53 AM UTC+2, Jasen Betts wrote:
> On 2015-05-30, Bill Sloman <bill.sloman@ieee.org> wrote: > > On 30/05/2015 9:20 AM, Jasen Betts wrote: > >> On 2015-05-29, John Larkin <jlarkin@highlandtechnology.com> wrote: > >>> On 29 May 2015 05:54:35 -0700, Winfield Hill > >>> <hill@rowland.harvard.edu> wrote: > >>>> Bill Sloman wrote... > >>>>> John Larkin wrote: > >>>>>> > >>>>>> I need an isolated analog output (many of them, actually) > >>>>>> with, say, 1 PPM programmability and linearity. An > >>>>>> optocoupled DAC would be silly, so I'll use PWM. > >>>> > >>>>>> The average value will be disturbed by the rise and > >>>>>> fall times of the optocoupler (or whatever) so > >>>>>> getting to 1 PPM linearity is scary.) > >>>>> > >>>>> There are more sources of potential linearity error at > >>>>> the 1ppm level than just differences between rise and > >>>>> fall times. > >>>> > >>>> It's actually the overall ON vs OFF delay times, > >>>> rather than rise time alone. The on vs off delays > >>>> are often quite different for optical-couplers and > >>>> drivers, but they're generally fairly stable and > >>>> repeatable. It'd be easy to add adjustable fixed > >>>> delays to both the on and off times, so they could > >>>> be trimmed to be more or less the same. I'll bet > >>>> a given choice of components in a production run > >>>> would have pretty closely matched delays; measure > >>>> one and apply the delay components to the rest. > >>> > >>> Yeah, the bottom line problem with D-S is on/off asymmetry, which > >>> makes errors at high, and essentially random, pulse rates. But I > >>> wouldn't want to attempt to tune it out. > >>> > >>> 1 0 1 0 has 8 edges, whereas 1 1 0 0 has only 4, so they won't > >>> average the same. Delta-sigma generates too many cases. The IC boys > >>> must do tricks to make D-S ICs as good as they are. > >> > >> ??? I count 4 and and 2 not 8 and 4 > >> > >>> The clustered/boogered PWM always has the same, small number of edges, > >>> so will always be monotonic and noise-free. > >>> > >>> It's really not worth trying to de-cluster the wider pulses, ie > >>> > >>> 50001 50000 50001 50000 ON versus > >>> 50001 50001 50000 50000 > >>> > >>> since the difference in ripple is a couple PPMs, and the lowpass > >>> filter will kill that tiny residual ripple. > >>> > >>> There probably *is* some tricky math algorithm to evenly disperse the > >>> N+1 pulses, some bit-field reversal or something, sort of a Van der > >>> Corput sequence thing. My guys will get into that math fun, even if > >>> it's unnecessary. > >> > >> pure bit field reversal gives an effect a bit like a delta-sigma, most > >> of the noise goes into the high frequencies but the number of transitions > >> is variable. burkes dither used to convert photos one bit depth works > >> like that. > >> > >> If you want a fixed number of transitions > >> > >> pick how many sub-fields you want in your modified PWM and then > >> shift your counter output log_2 that many bits leftwards, reverse > >> the order of the bits that overflowed and insert them into the > >> vacated spots on the right, > >> > >> so for an n bit counter to be split into 8 > >> > >>b n n-3 > >> n-1 .... > >> n-2 ----\ 3 > >> n-3 \ 2 > >> ... / 1 > >> 3 -----/ 0 > >> 2 n-2 > >> 1 n-1 > >> 0 n > > I was diagramming the transformation to make to the clock > my second column is the order the go into the comparitor > > > > My scheme was to reverse just the top four bits of the 10-bit counter output > > > > Counter Comparator > > > > 6 \ 10 > > 7 \ 9 > > 8 \ 8 > > 9 / 7 > > 10 / 6 > > 5 5 > > 4 4 > > 3 3 > > 2 2 > > 1 1 > > > > which gave 16x more transitions, and a well defined maximum transition rate. > > that looks like it would give mismatched pulse lengths: most of the of the 32 > slices would be either full or empty. > > What I have done is reverse all the bits which gives maximum > deterministic dither at the cost of an umpredictable number of edges > per cycle, but then un-reverse the least-signifigant bits to limit the > number of edges. so long as he programme input stays in the middle of > of its range (does fill or empty all its high-order bits there will be > a predictable number of transitions (2^(b+1)) for b bits moved.
I believe that's exactly what I described back in 1996, and more recently here. -- Bill Sloman, Sydney
Reply by June 15, 20152015-06-15
On Friday, May 29, 2015 at 10:19:04 AM UTC-4, John Larkin wrote:
> On 29 May 2015 05:54:35 -0700, Winfield Hill wrote: > > >Bill Sloman wrote... > >> > >> John Larkin wrote: > >>> > >>> I need an isolated analog output (many of them, actually) > >>> with, say, 1 PPM programmability and linearity. An > >>> optocoupled DAC would be silly, so I'll use PWM. > > > >>> The average value will be disturbed by the rise and > >>> fall times of the optocoupler (or whatever) so > >>> getting to 1 PPM linearity is scary.) > >> > >> There are more sources of potential linearity error at > >> the 1ppm level than just differences between rise and > >> fall times. > > > > It's actually the overall ON vs OFF delay times, > > rather than rise time alone. The on vs off delays > > are often quite different for optical-couplers and > > drivers, but they're generally fairly stable and > > repeatable. It'd be easy to add adjustable fixed > > delays to both the on and off times, so they could > > be trimmed to be more or less the same. I'll bet > > a given choice of components in a production run > > would have pretty closely matched delays; measure > > one and apply the delay components to the rest. > > Yeah, the bottom line problem with D-S is on/off asymmetry, which > makes errors at high, and essentially random, pulse rates. But I > wouldn't want to attempt to tune it out. > > 1 0 1 0 has 8 edges, whereas 1 1 0 0 has only 4, so they won't > average the same. Delta-sigma generates too many cases. The IC boys > must do tricks to make D-S ICs as good as they are. > > The clustered/boogered PWM always has the same, small number of edges, > so will always be monotonic and noise-free. > > It's really not worth trying to de-cluster the wider pulses, ie > > 50001 50000 50001 50000 ON versus > 50001 50001 50000 50000 > > since the difference in ripple is a couple PPMs, and the lowpass > filter will kill that tiny residual ripple. > > There probably *is* some tricky math algorithm to evenly disperse the > N+1 pulses, some bit-field reversal or something, sort of a Van der > Corput sequence thing. My guys will get into that math fun, even if > it's unnecessary.
The ripple waveform for a given code is known. Why not S/H the filtered PWM waveform, sampling at the precise time the waveform is/will be at the correct voltage for that code? That is, effectively, adaptively sample the ripple 'ramp' in lieu of PWM 'boogering.' Sort of the opposite of a time-to-digital converter. Even a first-order filter settles to zip ripple, quickly. Cheers, James Arthur
Reply by Bill Sloman May 31, 20152015-05-31
On 31/05/2015 3:29 AM, John Larkin wrote:
> On Sat, 30 May 2015 09:56:41 -0700 (PDT), George Herold > <gherold@teachspin.com> wrote: >> On Friday, May 29, 2015 at 1:20:19 AM UTC-4, John Larkin wrote:
<snip>
>> Nice thread, I don't have anything to add. >> I wanted to check my understanding. >> You chop up the PWM finer to make the LP filter easier. > > Yes. The alternate to the goofy non-equal pulses would be straight PWM > with a higher clock frequency. 200 MHz is about the practical upper > limit inside the FPGA, which gives 200 Hz plain PWM at 20 bits. That > will get lowpass filtered to maybe 2 Hz net. Higher order filters > would just accumulate delay. So, sneaky tricks are indicated.
Higher order filters give more attenuation at higher frequencies, but with PWM the worst case gets to be the PWM repeat frequency - 200Hz in this case - and more than two or three poles isn't worth the effort
> We could do something else exotic, like use a SERDES channel to make > PWM with 1 ns or better edge resolution, something like that. 1KHz > straight PWM with 1 ns width resolution is 1 PPM. We've done the > SERDES trick before; it's not bad. > > I guess I'd let my FPGA folks decide which way to do it, SERDES or > some goofy multi-pulse algorithm.
There's nothing goofy about using more than two transitions per PWM period. The more you divide up your marks and spaces, the lower the amplitude of the repetition rate ripple - 200Hz in this case. Breaking up your 1,000,000 clock edges into chunks that would mostly be 1024 clock edges long drops the worst case 200Hz ripple component by a factor of 1000, which helps the filter design no end.
> >> There's some error with the turn-on and turn-off >> time asymmetry in the opto-isolator. > > That translates to a little DC offset. There's no linearity error as > long as I keep the edges away from one another.
There no linearity error except at the top and bottom ends where individual - nominally 1024 clock edge long - chunks start vanishing or fusing, so the number of transitions per cycle moves away from 2000 - at the bottom of the range, from 0% to 0.1% of full scale and at the top, from 99.9% of full scale to 100%.
>> So you keep the number of edges (chunks) fixed. >> (Hmm, could be other on-off timing errors too.) >> >> For accuracy it would be nice to have a symmetric opto-iso. > > The TI parts are capacitively coupled, and the ADI parts are magnetic. > Most optos are slow and have nasty TCs. One TI coupler specs 2.5 ns > max pulse width distortion, awfully good.
You could always re-synchronise to a local clock on the other side of the isolation barrier ... -- Bill Sloman, Sydney
Reply by Bill Sloman May 30, 20152015-05-30
On Sunday, 31 May 2015 08:31:00 UTC+10, Jasen Betts  wrote:
> On 2015-05-30, Bill Sloman <bill.sloman@gmail.com> wrote: > > On Saturday, 30 May 2015 18:31:13 UTC+10, Jasen Betts wrote: > >> On 2015-05-30, Bill Sloman <bill.sloman@gmail.com> wrote: > > > > ><snip> > > > > Read the paper. > > if you are not prepared to defend your position here I'm going to > ignore it.
All you need to do to get a copy of the paper is to e-mail me at bill.sloman@ieee.org I don't see the point of repeating what I've long since published. -- Bill Sloman, Sydney
Reply by N. Coesel May 30, 20152015-05-30
John Larkin schreef op 05/29/2015 om 04:18 PM:
> > The clustered/boogered PWM always has the same, small number of edges, > so will always be monotonic and noise-free. > > It's really not worth trying to de-cluster the wider pulses, ie > > 50001 50000 50001 50000 ON versus > 50001 50001 50000 50000 > > since the difference in ripple is a couple PPMs, and the lowpass > filter will kill that tiny residual ripple. > > There probably *is* some tricky math algorithm to evenly disperse the > N+1 pulses, some bit-field reversal or something, sort of a Van der > Corput sequence thing. My guys will get into that math fun, even if > it's unnecessary.
I had a similar problem where I had to spread normal pulses and pulses with a length N-1 over several periods for a DPLL design. I turns out that using the reversed bit order of the period counter does that nicely. From a decade old memory: say you have 16 periods and 4 periods need to be extended. Reverse the bits of the counter and extend the period when the reversed counter is less than 4.
Reply by rickman May 30, 20152015-05-30
On 5/30/2015 5:41 PM, John Larkin wrote:
> On Sat, 30 May 2015 16:30:12 -0400, rickman <gnuarm@gmail.com> wrote: > >> On 5/30/2015 4:06 PM, John Larkin wrote: >>> On Sat, 30 May 2015 14:47:50 -0400, rickman <gnuarm@gmail.com> wrote: >>> >>>> On 5/30/2015 1:04 PM, John Larkin wrote: >>>>> On Sat, 30 May 2015 11:50:44 -0400, rickman <gnuarm@gmail.com> wrote: >>>>> >>>>>> On 5/30/2015 11:19 AM, John Larkin wrote: >>>>>>> On 30 May 2015 04:56:48 -0700, Winfield Hill >>>>>>> <hill@rowland.harvard.edu> wrote: >>>>>>> >>>>>>>> John Larkin wrote... >>>>>>>>> rickman wrote: >>>>>>>>>> John Larkin wrote: >>>>>>>> >>>>>>>>>>> Right. Delta-sigma ADCs are astonishing. There's nothing that you can >>>>>>>>>>> afford that's anywhere close to as accurate and linear as they are. >>>>>>>>>> >>>>>>>>>> So what's so bad about a DS DAC? They can be had at up to 24 bits. >>>>>>>>> >>>>>>>>> Got any parts in mind? I need DC accuracy, and audio parts don't >>>>>>>>> generally guarantee that. >>>>>>>> >>>>>>>> How about TI's DAC1220, 20-bits, 2ms to 0.012%, $9. >>>>>>> >>>>>>> That would probably work. It has the filter built-in, which is its >>>>>>> main advantage. Performance-wise, it's about a tie with what I could >>>>>>> do with PWM. >>>>>>> >>>>>>> It will need a triple or quad coupler, including the 2.5 MHz clock, no >>>>>>> big deal. Too bad they didn't include an internal clock. >>>>>>> >>>>>>> The PWM thing would be about $7 cheaper per channel. You never know >>>>>>> how many channels you're gonna sell. 100? 20000? >>>>>> >>>>>> The PWM will only be cheaper if you can get it to meet spec and the >>>>>> sales covers the NRE. Right now the NRE is an unknown quantity as is >>>>>> the sales volume it would seem. Then there is the opportunity cost of >>>>>> spending an unknown amount of time on developing the PWM approach, time >>>>>> you could spend on work with a known payoff. >>>>>> >>>>>> BTW, you don't need an opto for the clock. The TI part can work with a >>>>>> crystal although that's pretty much a wash in most regards. >>>>> >>>>> It's easier to optoisolate the clock. Getting crystals to work >>>>> reliably with chips like that is always a hassle. The TI data sheet >>>>> has the usual fuzzy advice about the crystal. >>>>> >>>>> I usually buy oscillators, not crystals. The oscillators always >>>>> oscillate. >>>>> >>>>> Also, you >>>>>> only need one additional opto for each additional channel since the >>>>>> interface has chip selects. >>>>> >>>>> The channels need to be individually isolated. CS is optional on this >>>>> chip, which would allow me to use 3 opto channels per DAC (clock, SPI >>>>> clock, SPI data.) >>>> >>>> So you need isolated power for each channel? That's a lot more hassle >>>> than the optos. >>> >>> These are cute: >>> >>> http://www.cui.com/product/resource/digikeypdf/pds1-d-m.pdf >>> >>> maybe add a common-mode choke or two to tame the switching noise. >> >> Really? This is four times the size of the DAC without the choke! I >> guess space is not a concern. I would think a device that only needs a >> few uAs could be powered with a very simple capacitive coupling, a few >> passives and a three pin regulator. Am I wrong about that? You can >> generate the square wave from any logic output. Or do you still need an >> opamp that uses a lot more power? >> >> >>>>> So you need 2 or 3 + N optos, not much more >>>>>> than the PWM approach if you have multiple channels per unit. >>>>> >>>>> The low quantity price on that TI part isn't great. I'd probably never >>>>> buy 1000 at a time. >>>>> >>>>> http://tinyurl.com/pwa5cgq >>>>> >>>>> The FPGA logic is about a wash: SPI or PWM, no big deal either way. >>>>> The goofy PWM is more fun. >>>>> >>>>> The DAC1220 has 16 registers to deal with! Not fun. >>>> >>>> Lol, 15 minutes with the data sheet and the simplest of state >>>> machines... also called a counter. Often chips like these default to a >>>> basic usable mode with no setup. But then you won't be doing the FPGA >>>> code anyway. Let someone who knows how decide if it is hard or not. >>> >>> Assuming the data sheet tells you all you need to know, and is right. >>> >>> The digital interfaces and documentation of mixed-signal parts tends >>> to be ghastly. >>> >>> The SPI part is easy, since an ARM program would do all the detailed >>> stuff. It's not a big deal to mash all those bits, just a nuisance. >>> >>> We use one SPI DAC that has a control bit that switches the SPI clock >>> from rising edge active to falling edge. The initial state is not >>> defined. Think about that. >> >> If you have that much trouble programming the part, let me know and I >> will be happy to do it for you. I'm pretty bored at the moment. > > > The fix for that dac edge problem was to make the data wide in time > and pulse the clock, so that the part sees both edges on each data > bit. Crazy.
I don't see why that is so crazy. It might not work with an MCU SPI port which doesn't have that capability. Did anyone provide feedback about this? Likely all they needed to do was document the start up state. If that was not controlled they should rev the part and control it.
> If we use the TI dac, and programming it looks like work, I'll let you > know. My c guy will just want to slam a struct full of setups at > powerup time, then poke in DAC values later.
That's pretty much all you need to do. Seems to me the structure is a bit of overkill, but some folks like a lot of organization. In a case like this where the data is very unlikely to change over the course of the project, I would just define an array of words
>> BTW, I did notice one section in this data sheet, "Brownouts and >> Power-On Reset". Seems the part can get into a state on brownout that >> you can't reset it from since there is no reset pin. They use a "reset >> pattern" on the SCLK pin which might not be recognized if it is brownout >> hung. I'll admit this sounds very goofy. The fix is to discharge the >> supply completely which shouldn't be a problem with your setup. > > Typical for mixed-signal parts. Analog designers apparently can't do > logic. > > Sometimes the bugs are only implied in application examples or > footnotes. Look for the ominous "For optimum operation..." phrases.
They cheaped out on the internal reset and because of pin limitations (I assume), they don't have a spare for reset. I don't know why it didn't occur to someone on the crew that the logic could get in a state that wouldn't detect a sequence on the inputs.... that's what the reset is supposed to cure, duh. A simple mistake in an effort to stay in a 16 pin package. I'd say it was more inexperience than systemic incompetence. -- Rick
Reply by Jasen Betts May 30, 20152015-05-30
On 2015-05-30, Bill Sloman <bill.sloman@gmail.com> wrote:
> On Saturday, 30 May 2015 18:31:13 UTC+10, Jasen Betts wrote: >> On 2015-05-30, Bill Sloman <bill.sloman@gmail.com> wrote:
> ><snip> > > Read the paper.
if you are not prepared to defend your position here I'm going to ignore it. -- umop apisdn