On 2015-05-30, Bill Sloman wrote: as diagramming the transformation to make to the clock
(you said 4 but then diagrammed 5 bits reversed, I'll go with 4 as that's what you're discussing most recently)
By my reading of your wiring pattern above the comparitor sees a sequence that starts 0,1,2,3,4,5...,62,63,512,513,..543,256...319,
768...831, (please excuse any trivial arithmeti errors) so if we assume the pwm level input is is at 600 we'd see high for 192 clock periods then low for 64 ...
"my" pattern (for some reason we're counting from 1 instead of from 0, I'll keep doing that)
b6 b5 b4 b3 b2 b1 b7 b8 b9 b10
My wiring pattern (shifting the low bits to the top and reversing the high bits at the bottom) gives 0,16,32,48,64...992,1008,8,24,40...1016,4,20...1004 ,1020,12... which is 16 steepness 16 staircases of dithered offset, and, I expect, what you intended.
it can be improved by usung the msb of the shifted bits to turn that sequence into a double staircase like so. ( ^ represents XOR ) b5 ^ b6 b4 ^ b6 b3 ^ b6 b2 ^ b6 b1 ^ b6 b6 b7 b8 b9 b10 that will stop the input from phase modulating the output to the same extent.. all the bit shuffling has me wondering about how a LFSR would perform in this application, has anyone tried that?
The appnote is ST's AN4507, about PWM dithering. They reference only one paper, by Angel Peterchev, who was a student engineer in my lab for a few years. Here's his 2001 PESC paper on DropBox.
Read the paper. We squeezed the process into a tiny programmable logic device - an ICT7024 - like it says in the paper, and it took Paul Buggs a couple of days to get it to fit. Since then it should have got a lot easier
It's not something where a linear feedback shift register would be any help at all, unless you wanted to do each of the comparisons involved in serial rather than parallel logic, and why would you bother?
John Larkin wants to do a comparison every 50nsec on 20-bit long words, which would 2.5nsec per serial comparison - fine in ECLinPs, but much more expensive than programmable logic.
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?
--
John Larkin Highland Technology, Inc
picosecond timing laser drivers and controllers
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
Accuracy is remarkably good, but only after self-calibration. And - with my faith in TI - I'd worry that the calibration would only be good where it was easy to test.
Tricky, when it has to communicate with the rest of the world over a serial line.
It's not as if you spend a lot on development ...
Our rule was never to develop what you could buy. There are better ways to keep engineers busy than re-inventing the wheel.
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. Also, you only need one additional opto for each additional channel since the interface has chip selects. So you need 2 or 3 + N optos, not much more than the PWM approach if you have multiple channels per unit.
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. There's some error with the turn-on and turn-off time asymmetry in the opto-isolator. 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.
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
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 2 or 3 + N optos, not much more
The low quantity price on that TI part isn't great. I'd probably never buy 1000 at a time.
formatting link
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.
--
John Larkin Highland Technology, Inc
picosecond timing laser drivers and controllers
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
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.
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.
That translates to a little DC offset. There's no linearity error as long as I keep the edges away from one another.
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.
--
John Larkin Highland Technology, Inc
picosecond timing laser drivers and controllers
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
So you need isolated power for each channel? That's a lot more hassle than the optos.
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.
maybe add a common-mode choke or two to tame the switching noise.
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.
--
John Larkin Highland Technology, Inc
picosecond timing laser drivers and controllers
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
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?
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.
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.
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.
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.
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.
--
John Larkin Highland Technology, Inc
picosecond timing laser drivers and controllers
jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com
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.
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
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.