Reply by John Larkin December 30, 20162016-12-30
On Fri, 30 Dec 2016 20:47:15 +0000, John Devereux
<john@devereux.me.uk> wrote:

>John Larkin <jjlarkinxyxy@highlandtechnology.com> writes: > >> On Thu, 22 Dec 2016 21:09:18 -0500, "Michael A. Terrell" >> <mike.terrell@earthlink.net> wrote: >> >>>John Larkin wrote: >>>> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=38&ved=0ahUKEwjG19u1n_TQAhVnrlQKHRUMAEc4HhAWCEgwBw&url=https%3A%2F%2Fwww.cscamm.umd.edu%2Fprograms%2Focq05%2Fadams%2Fadams_ocq05.pdf&usg=AFQjCNFFz_m97QqzWywq87nBJJ5uONIk0A&bvm=bv.141320020,d.cGc&cad=rja >>>> >>>> or maybe >>>> >>>> http://tinyurl.com/zhlgolz >>> >>> >>>It's easy to eliminate the garbage from a google search link: >>> >>><https://www.cscamm.umd.edu/programs/ocq05/adams/adams_ocq05.pdf> >>> >>> >> >> Cool. How? > >Looks like I use the "google search link fix" firefox addon. I expect >there are others.
That works great. Thanks. -- John Larkin Highland Technology, Inc lunatic fringe electronics
Reply by Lasse Langwadt Christensen December 30, 20162016-12-30
Den fredag den 30. december 2016 kl. 19.49.09 UTC+1 skrev John Larkin:
> On Thu, 22 Dec 2016 21:09:18 -0500, "Michael A. Terrell" > <mike.terrell@earthlink.net> wrote: > > >John Larkin wrote: > >> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=38&ved=0ahUKEwjG19u1n_TQAhVnrlQKHRUMAEc4HhAWCEgwBw&url=https%3A%2F%2Fwww.cscamm.umd.edu%2Fprograms%2Focq05%2Fadams%2Fadams_ocq05.pdf&usg=AFQjCNFFz_m97QqzWywq87nBJJ5uONIk0A&bvm=bv.141320020,d.cGc&cad=rja > >> > >> or maybe > >> > >> http://tinyurl.com/zhlgolz > > > > > >It's easy to eliminate the garbage from a google search link: > > > ><https://www.cscamm.umd.edu/programs/ocq05/adams/adams_ocq05.pdf> > > > > > > Cool. How? >
I used foxit so pdfs show up in downloads, there you can right-click copy link adress
Reply by John Devereux December 30, 20162016-12-30
John Larkin <jjlarkinxyxy@highlandtechnology.com> writes:

> On Thu, 22 Dec 2016 21:09:18 -0500, "Michael A. Terrell" > <mike.terrell@earthlink.net> wrote: > >>John Larkin wrote: >>> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=38&ved=0ahUKEwjG19u1n_TQAhVnrlQKHRUMAEc4HhAWCEgwBw&url=https%3A%2F%2Fwww.cscamm.umd.edu%2Fprograms%2Focq05%2Fadams%2Fadams_ocq05.pdf&usg=AFQjCNFFz_m97QqzWywq87nBJJ5uONIk0A&bvm=bv.141320020,d.cGc&cad=rja >>> >>> or maybe >>> >>> http://tinyurl.com/zhlgolz >> >> >>It's easy to eliminate the garbage from a google search link: >> >><https://www.cscamm.umd.edu/programs/ocq05/adams/adams_ocq05.pdf> >> >> > > Cool. How?
Looks like I use the "google search link fix" firefox addon. I expect there are others. -- John Devereux
Reply by John Larkin December 30, 20162016-12-30
On Thu, 22 Dec 2016 21:09:18 -0500, "Michael A. Terrell"
<mike.terrell@earthlink.net> wrote:

>John Larkin wrote: >> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=38&ved=0ahUKEwjG19u1n_TQAhVnrlQKHRUMAEc4HhAWCEgwBw&url=https%3A%2F%2Fwww.cscamm.umd.edu%2Fprograms%2Focq05%2Fadams%2Fadams_ocq05.pdf&usg=AFQjCNFFz_m97QqzWywq87nBJJ5uONIk0A&bvm=bv.141320020,d.cGc&cad=rja >> >> or maybe >> >> http://tinyurl.com/zhlgolz > > >It's easy to eliminate the garbage from a google search link: > ><https://www.cscamm.umd.edu/programs/ocq05/adams/adams_ocq05.pdf> > >
Cool. How? -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by Michael A. Terrell December 22, 20162016-12-22
John Larkin wrote:
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=38&ved=0ahUKEwjG19u1n_TQAhVnrlQKHRUMAEc4HhAWCEgwBw&url=https%3A%2F%2Fwww.cscamm.umd.edu%2Fprograms%2Focq05%2Fadams%2Fadams_ocq05.pdf&usg=AFQjCNFFz_m97QqzWywq87nBJJ5uONIk0A&bvm=bv.141320020,d.cGc&cad=rja > > or maybe > > http://tinyurl.com/zhlgolz
It's easy to eliminate the garbage from a google search link: <https://www.cscamm.umd.edu/programs/ocq05/adams/adams_ocq05.pdf>
> This has some really interesting ideas about extending DAC resolution > with scrambled thermometer codes and such. Some class-D audio stuff, > too. > > I've got to take time to study this; there are a lot of ideas here. > > I want to make a 16-bit multi-channel, maybe 5 MHz, arbitrary waveform > generator, and I have some nice, fast (120 MHz) 14-bit dual DACs in > stock, DAC2904s. They have speed to burn, so I should be able to > dither them up to 16 bits. I can't do simple (wiggle the LSB) > delta-sigma, because the DNL of the DACs is 4 LSBs p-p, so the dither > has to be big enough to smooth out DNL errors too. This will involve > noise shaping of the dither pattern, sort of like a high-order > delta-sigma, where you push the dither spectrum up so the final analog > 5 MHz lowpass filter kills the noise you add. > > I'm playing with that in LT Spice, which is admittedly a clumsy tool > for this sort of thing. > > I have a huge respect, and some envy, for people who are really good > with this signals+systems stuff. I do have a copy of "Signals and > Systems for Dummies." > > > > >
-- Never piss off an Engineer! They don't get mad. They don't get even. They go for over unity! ;-)
Reply by December 22, 20162016-12-22
On Tuesday, 20 December 2016 06:35:55 UTC+11, John Larkin  wrote:
> On Mon, 19 Dec 2016 11:00:21 -0800 (PST), makolber@yahoo.com wrote: > > >On Friday, December 16, 2016 at 4:08:29 PM UTC-5, John Larkin wrote: > >> On Fri, 16 Dec 2016 13:00:10 -0800 (PST), makolber@yahoo.com wrote: > >> > >> > I don't have the time or the gear to characterize a 14-bit, 125 > >> >> MHz DAC. We'll design the real board and see how it works. > >> >> > >> >> TI is pretty good about specs and performance. > >> > > >> >you probably know they usually have EVAL boards for those types of parts > >> > >> Sure, but it would still be very difficult to make INL and DNL > >> measurements on a 14-bit 125 MHz DAC. A more efficient path to done is > >> to design and lay out the real product, and do some thinking and > >> simulation first to be reasonably confident it will work. > >> > >> > >or use the eval board, not to make raw measurements of the part, > >but to make a prototype of your "real product" and see if it works well enoughfor your application. > > We never prototype products; it's a big waste of time. The best > prototype is the first production unit.
John Larkin typical development cycle takes two weeks. He seems to be deeply into incremental development, and his new product is mostly going to be less different from his current product than regular people's pre-production prototypes are different from their first production unit.
> We do breadboard little circuits, if we don't fully understand or > trust the specs on a part.
Designing straight on a printed circuit board is making more and more sense these days. When layout is critical, it's hard to make a useful breadboard.
> Testing and dithering that DAC will need a 484-ball FPGA, so we may as > well go for the real board and hope we can sell it.
And it won't cost much to modify the first board layout if you can't. -- Bill Sloman, Sydney
Reply by John Larkin December 19, 20162016-12-19
On Mon, 19 Dec 2016 11:00:21 -0800 (PST), makolber@yahoo.com wrote:

>On Friday, December 16, 2016 at 4:08:29 PM UTC-5, John Larkin wrote: >> On Fri, 16 Dec 2016 13:00:10 -0800 (PST), makolber@yahoo.com wrote: >> >> > I don't have the time or the gear to characterize a 14-bit, 125 >> >> MHz DAC. We'll design the real board and see how it works. >> >> >> >> TI is pretty good about specs and performance. >> >> >> >> >> >> -- >> > >> >you probably know they usually have EVAL boards for those types of parts >> > >> >m >> >> Sure, but it would still be very difficult to make INL and DNL >> measurements on a 14-bit 125 MHz DAC. A more efficient path to done is >> to design and lay out the real product, and do some thinking and >> simulation first to be reasonably confident it will work. >> >> >or use the eval board, not to make raw measurements of the part, >but to make a prototype of your "real product" and see if it works well enough >for your application. > >m
We never prototype products; it's a big waste of time. The best prototype is the first production unit. We do breadboard little circuits, if we don't fully understand or trust the specs on a part. Testing and dithering that DAC will need a 484-ball FPGA, so we may as well go for the real board and hope we can sell it. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Reply by December 19, 20162016-12-19
On Friday, December 16, 2016 at 4:08:29 PM UTC-5, John Larkin wrote:
> On Fri, 16 Dec 2016 13:00:10 -0800 (PST), makolber@yahoo.com wrote: > > > I don't have the time or the gear to characterize a 14-bit, 125 > >> MHz DAC. We'll design the real board and see how it works. > >> > >> TI is pretty good about specs and performance. > >> > >> > >> -- > > > >you probably know they usually have EVAL boards for those types of parts > > > >m > > Sure, but it would still be very difficult to make INL and DNL > measurements on a 14-bit 125 MHz DAC. A more efficient path to done is > to design and lay out the real product, and do some thinking and > simulation first to be reasonably confident it will work. > >
or use the eval board, not to make raw measurements of the part, but to make a prototype of your "real product" and see if it works well enough for your application. m
Reply by Chris Jones December 18, 20162016-12-18
On 17/12/2016 02:28, John Larkin wrote:
> On Fri, 16 Dec 2016 15:44:36 +1100, Chris Jones > <lugnut808@spam.yahoo.com> wrote: > >> On 15/12/2016 05:23, John Larkin wrote: >>> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=38&ved=0ahUKEwjG19u1n_TQAhVnrlQKHRUMAEc4HhAWCEgwBw&url=https%3A%2F%2Fwww.cscamm.umd.edu%2Fprograms%2Focq05%2Fadams%2Fadams_ocq05.pdf&usg=AFQjCNFFz_m97QqzWywq87nBJJ5uONIk0A&bvm=bv.141320020,d.cGc&cad=rja >>> >>> or maybe >>> >>> http://tinyurl.com/zhlgolz >>> >>> >>> This has some really interesting ideas about extending DAC resolution >>> with scrambled thermometer codes and such. Some class-D audio stuff, >>> too. >>> >>> I've got to take time to study this; there are a lot of ideas here. >>> >>> I want to make a 16-bit multi-channel, maybe 5 MHz, arbitrary waveform >>> generator, and I have some nice, fast (120 MHz) 14-bit dual DACs in >>> stock, DAC2904s. They have speed to burn, so I should be able to >>> dither them up to 16 bits. >> >> >> You might have a chance, given that the converter is a lot faster than >> you are aiming for, > > In my case, 25:1 over Nyquist. > > > but it would be a good idea to plot out the actual >> INL first, as you won't fix e.g. the major code transition with a few >> bits of dither. > > I'm not concerned about INL, I can spec the system for, say, 0.1% > accuracy. The data sheet has a typical DNL curve, which would be a > major project to verify.
Ah, ok. I thought you were expecting to get proper 16-bit accuracy, which is a lot more difficult than 0.1%
> Also, beware glitch energy. Your scheme might be perfect >> near DC (with sample rates near DC) but if code transitions have a lot >> (or differ by a lot) of glitch energy, that could still mess you up. > > These TXdacs are design for communications; they are awfully good.
Yes, that is the sort you would have a good chance with.
>> It's funny that everyone who buys ADC or DAC chips thinks that they are >> the first ones to discover dithering, interleaving and averaging etc., >> and decides that they can make a cheap converter as good as a more >> expensive one. > > Everyone?
No, that was clearly an exaggeration, it is just many people, especially those who have not thought about what limits the accuracy that the manufacturer specified on their datasheet, other than running out of pins for more input bits.
> Sometimes the chip company has already used all of those >> techniques inside the chip, to the maximum extent that they could, >> without telling you. (Not necessarily in the part that you are using - I >> have not looked into that one.) > > I doubt that this 125 MHz DAC gets any of its bits from internal > dithering. Its analog settling time is 2 ns. It does probably do some > low bits, three maybe, as thermometer codes.
More likely thermometer coding the msbs, to avoid a big major code transition error.
>> When polishing a shiny turd, you have to stop before you start to rub >> off the polish that the last guy added. >> > > Now you are being needlessly offensive. And obtuse.
Yes, sorry that part was more aimed at the crowd who believe that they can make a DAC with 16 bits, using two 8-bit DACS and two resistors.
Reply by Martin Brown December 16, 20162016-12-16
On 16/12/2016 16:35, John Larkin wrote:
> On Fri, 16 Dec 2016 09:12:42 +0000, Martin Brown > <|||newspam|||@nezumi.demon.co.uk> wrote: > >> On 14/12/2016 21:35, John Larkin wrote:
>>> Our spec will claim 16 bit resolution, but certainly not 16 bit >>> accuracy. The real benefit to 16 bits is to avoid gross steps when >>> making small signals. Dithering can really help there. There's no >>> reason we shouldn't try to dither out to 18 bits... it's easy in an >>> FPGA. >>> >>> These fast dacs tend to be hybrid architectures, some mix of R-2R and >>> thermometer codes at the low end. So the dithering will be a little >>> weird. >> >> You might be able to do it by calibrating the DAC against another >> precision voltage measurement system 18bit reference linear ADC or DVM. >> >> The first battle will be to determine the internal ladder structure and >> systematic errors in it. We used to do something similar to make the >> DACs of old perform well enough for mass spectrometry to get optimum >> performance out of each one. Slightly tedious process but can be speeded >> up by judicious choice of step size so that every bit is explored in >> sufficient combinations with the others. >> >> You will have to do a separate test to figure out the thermometer codes >> and try and find out if their behaviour varies with where you are on the >> output level. A lot a DACs have a small amount of mid range quadratic >> droop which you might find advantageous to calibrate out. > > I don't too much care what's inside the chip. The data sheet has INL, > DNL, DC, and AC specs and measurements. I'll asssume they are about > right. I don't have the time or the gear to characterize a 14-bit, 125 > MHz DAC. We'll design the real board and see how it works. > > TI is pretty good about specs and performance.
Indeed. But if you can characterise and calibrate out the main systematic errors you can probably get a fair bit closer to true 16 bit behaviour with the same hardware and only slightly more complex runtime code. -- Regards, Martin Brown