Wednesday, February 10, 2021

CV refresh rates

My Teensy-based voice controller prototype currently has a CV refresh rate of 1kHz. In this post I noted that the OB-6 has a refresh rate of 24kHz for < 1ms attack on envelopes, and the VS-1 OB-X remake uses 48kHz. I want my controller to get closer to those numbers.

I will have 48 CVs. Refreshing them at 40kHz means I need to update the DAC at 1.92MHz. With a 600MHz processor, this leaves around 300 clock cycles per update. It may be possible but could be a little on the short side.

I have tried dividing the CVs into those that will probably be modulated by envelopes, and those that can be a bit more slow moving. I ended up with 32 that I really want to be fast. If at the same time I reduce my refresh rate to what the OB-6 is using, 24kHz, I end up with a refresh rate of 768kHz for the 32 CVs. Add inn a 1kHz+ refresh rate for the remaining 16 and we end up with approximately 800kHz. 

In a new video on the VS-1 I noted that it now has 112CVs. It uses an 8 channel DAC, which means each channel has to be updated at 14 * 48kHz = 672kHz - that's pretty close to what I'm trying to do!


Necessary changes to my circuit

Capacitance

On the 1kHz version I use a 10nF sample & hold cap for 40kHz updates. Increasing to 800kHz means I should probably use a cap with 1/20 the capacitance. Closest match would be 470pF.

I tried putting this into my prototype but I'm having issues with noise - trying to generate a 800kHz square wave for testing doesn't seem to work very well. I switched to using my function generator but still had issues. It could be just because of the breadboard, so I will try this on a beta board, but before that I simulated the circuit in LTSpice to see what it looked like there. 


Initially I had a hard time getting the simulation to work. I couldn't get a proper square wave (I tried using the opamp comparator trick to turn my sine into a sqare), and started worrying that the TL072 is not up to the task. Perhaps the slew rate is too low? 

The datasheet says that the slew rate is between 13 and 20V/uS. In our case we want to charge the cap from 0 to 5V in  1/800000s = 5V/1.25uS = 4V/uS. So the slew rate should not be a problem.

After switching to the built-in pulse generator things looked a little better, but there were heavy noise on the square after I passed it through an op amp buffer. I then realised that by adding a resistor in series with the output, I would get a simple low pass filter. The formula for the filter is 1 / (2*pi*R*C). If we use a 470pF cap, and want an 800kHz cutoff, we need to use a 424 ohm resistor. A more standard value of 390 ohm gives us cutoff at 869kHz. Bear in mind though that this is a one pole filter, so the falloff is not very steep. Still, it should do away with some of the issue.

Simulating this turned out very well indeed, and adding it to the physical circuit also worked wonders for the INPUT to the S & H. The output, however, still looked the same. Connecting a 1k resistor between the output and the scope made it look a lot better.

Input vs output when using a filter resistor

Output still has some distortion at the bottom

Input, ringing is gone


I tried reducing the cap even further to get even higher refresh rates. This did not have the intended effect and I saw the same in the physical circuit as in the simulation. We get about the same response as with the 470pF cap. It looks like we're hitting some other limitation with the op amp perhaps - could it be internal capacitance or something? I'll see if I care to look closer into it.


Top: Square wave input vs output when we don't have a filtering resistor



Square wave vs unbuffered ("ideal") input to op amps (both top and middle are equal) and filtered version  (bottom) outputs


responses - top and middle are again equal and slightly rising towards higher frequencies, bottom shows low pass filtering,


Adding a similar passive filter to the output of the others - top and bottom show same response while middle gets a bit of a resonance peak.


Clock speed

The CD4520 clock can run at speeds up to 1.5MHz. I initially thought this too slow (for 1.92MHz, the refresh rate needed for 48 CVs at 40kHz it definitely is). I tried switching to a 74HC393, but running that at 3v3 meant the clock speed had to be around the same. The logic output also looked like 2V instead of 3v3,  and looked more noisy on the scope. Increasing Vdd to 5V let me run the chip at 3MHz and the logic output increased to 4V.

Something is definitely wrong here. Maybe it is the scope, maybe it is the breadboarding, but the 393 should be capable of clock speeds > 6MHz at 2V. I will test this further with my beta controller. It could also simply be that the timer I use cannot reach higher speeds than 2-3MHz. Oh well, it seems it may not be necessary after all.

As for the CD4051 mux, it probably has some of the same speed limitations as the CD4520. In the production version I will probably use vishay DG406 or similar which will probably work better.

Also, I may try to not use a clock at all, instead directly controlling the addresses of the muxes.


Addressing

To address 48 CVs I will either use 6 8ch MUXes or 3 16ch. Unfortunately, I cannot simply clock them sequentially. I can, however, use a clock for the three/four address lines, and then use the enable pin on each to select what mux to turn on. I would then update all 3/6 channels that have the same mux address sequentially to save time. 

I could possibly also use a separate mux to select which one of the other muxes to address. Doing this would actually make it possible to clock everything from the same clock (but possibly waste some clock cycles as I can either clock 4 or 8 muxes.


Multi channel DACs

Increasing the number of DAC channels would let us do less waits and also decrease the refresh rates since we would update multiple channels in parallel. This last thing is good as it lets us use a bigger cap that will keep its charge longer, giving us a more stable output.