sample & hold timing again....

[Roel Das]

Thanks for your comment.

At the moment my heart is slowing down again to regular speed (still ain't
normal, but better), blood presure is lowering too, and my view is getting
clear again.   8-)

I've been looking at the 4051 earlier, and at the 4096. Problem is that the
DAC has a range from 0V to 10V, and those components can't handle something
higher than their supply (which has a 10V max!!).
That's why I used the DG506. Not taking anything else into account at the
time, only price, nr of channels (16) and the range they could handle...
Live and learn. Aouch.

Anyway, the idea of updating the CV channels twice as much is very good. You
could call it a dirty trick, but I'll tell my teachers one of my genious
ideas...   :-)

The leakage is indeed worst case. VERY worst case... Even worst component
case, probably.
For the max336, worst case at normal temp: 0.02 nA. Alot better. for the
intersils DG506: 10nA, 0.02 typical. That's also alot better. But I won't be
able to play northpole... Hell of a compromise.
Ron is typically 220 for the MAX336 and 270 for the DG506. This ain't alot
better tough.

But I still guess I overreacted a little... It will probably work out fine
if I adapt the PCB to use the DAC with control signals. I already noticed
this was a bad thing while I was writing the software. But now I found that
it is worse than I could think...
I wonder if the board would perform better with the 2 wires below...
Thoughts on this? Or would it be better to make a dongle with the DAC716 on
it, and two wires from a connector that go to the dongle? Or other options?

Thanks...
Roel


You wrote:

>Hi Roel!
>
>I just had a quick look at the CD4051 datasheet, and it suggests that
>its possibly an alternative switch for this application.
>(20pA @25°C leakage typ. and Ron=80 ohms typ.) However check the
>Datasheets again, your leakage figures might be worst-case figures.
>I.e. taken at +125°C which is not what you're gonna do. The opamps leakage
>would rise also with temperature, up to the point where even the best ones
>aren't friendly anymore.
>This might relax your problem, you might be able to lower the caps somewhat
>To get faster chargeing times.

>(I admitt this isn't striktly worst-case design, but often you get away
>with it.)
>
>You don't have to get the cap charged fully at the first cycle.
>Chances are, that you already have some charge at the cap, and a shorter
>cycle is sufficient to get close enough to your desired voltage.
>For a 1V output step, your switching time can be 10 times less than for a
>10V step, while still be within your < 1/2 LSB error limit! (Hehe, do you
>play jumps like c0-c10 all the time....?) I'd make the charge time 5*ln2
>RC. Then it takes two cycles for larger steps, and one for smaller ones.
>
>Or another idea, you could relax the requirements for some of the control
>outputs.
>I.e. allowing a higher ripple there (where it really isn't that important,
>like gate, pan, volume or so.) You could spend the time saved on charging
>the pitch CV (which is the most critical) for a longer period, while
>keeping the time for a cycle the same.
>
>These might be "dirty tricks" you could try. But OTOH, you could just make
>a small dongle and fit in a parallel DAC, this would help a lot.
>
>Don't worry about the absolute value of the refresh cycle.
>The 1ms figure was just a "order of maginitude". 5 or 20 might also work,
>it depends on your hardware. I'd recalculate, trying to get an optimum
>value, where the charge time and the leakage error requirements are both
>met, and what ever time would be required is your refresh cycle time. This
>would be an equation system to solve for C.
>If you find that the C is uncomfortably high, you have to relax your
>requirements.
>
>Good design demands compromise!
>
>Bye,
> René
>


At 17:16 22.04.00 +0200, you wrote:
>Hello again...
>
>I was just making some calculations on the timing. (With the help of the
>many responses from last week, thanks...)
>
>This is what I found out:
>I'm using a serial DAC, the DAC716 in 2 wire mode. (PCB is finished, no way
>back)
>This means; the mux has to be disabled while sending the data thru, every
>change in data appears at the ouput.
>
>Now, to send 16 bits at 2MHz (The fastest my µP can handle), you need 80
µs.
>
>This needs to be done 16 times. PLUS settling time of 6µs and an extra
>transition time, when the mux is enabled. (Take that total 20 µs)
>
>This results in about 100 µs per channel. Taken into count that there are
16
>channels; this means 1.6 ms total.
>
>This won't work. (more calculations below...)
>I'm really freakin' out. Best thing to do is get rid of the 2 wire
>operation.
>
>The main question: can I fix this for now, by cutting the traces on the
pcb,
>and connecting the pins with wires? Can it work that way? I will make a new
>PCB for it, once , but don't have the time at the moment. (This is more
than
>an endwork project. It will be mine, has to be perfect...)
>
>If I do it this way, timing won't be an issue. The mux can be enabled as
>long as the µP is sending data, which means about 80 µs. Together that's
>still 1280 µs. But this also means the caps can be really big, which lowers
>the ripple alot.
>
>Anyway, some people suggested that refresh time should be 1ms, any reasons
>for that? Is 1280 close enough?
>
>Other things I can fix in the upgrade?
>
>Oh boy. think i'm getting in a bad mood.
>
>Thanks...
>Roel.
>
>I guess I learned alot today. Damn. Hate to learn the hard way. Teachers
>ain't gonna like this...
>
>---------------------------------------------------------------------------
-
>-----------------------------
>some more calculations as the mails suggested:
>
>to get the cap loaded to a value lower than 1/2 LSB of the DAC, taken into
>account the 400 ohm Ron value for the DG506 mux ( max 400 ohm, typical
270);
>the time is t = R * C * 11.78 = 4712 * C
>
>The total time for one channel = 80 µs + 6 µs + (4712 * C)
>Total time = 1376 µs + 75392 * C
>
>---------------------------------------------------------------------------
-
>------------------------------
>Back with the 100 µs per channel...
>
>When you aproximate the ripple by using VoltsPerSecond = CurrentInAmps /
>CapacitanceInFarads
>
>or V / t = I / C
>
>The leakage current of the DG506 mux = 300 nA !!!!; that of the tl072 is
>much lower...
>I do use an upgrade however with leakage of 20 nA (maxim 336, I don't know
>it's price however, it's a sample...)
>
>This gives V = 20nA * 1.6ms / C
>
>This means: to get the ripple lower than 1 LSB (=0.15mV), the cap has to be
>bigger than approx. 200 nF
>
>All together: it's not gonna work. oh jee.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

transconductance | uzs159 at uni-bonn.de
isfutilepreparet | http://www.uni-bonn.de/~uzs159
obeassimilated.. | http://members.xoom.com/Rene_Schmitz