[sdiy] Autotuning CEM3340/V3340 oscillators

Dave dlmanley at sonic.net
Thu Sep 21 23:24:42 CEST 2017


As long as you don't  mind variable step sizes.

-Dave 

On September 21, 2017 11:02:45 AM PDT, Tom Wiltshire <tom at electricdruid.net> wrote:
>Yeah, using a 4922 with one driving the other’s Vref is a good idea.
>That saves doing the weighting of the two DAcs at the VCO’s summing CV
>input. Thanks Paula. 
>
>Tom
>
>==================
>       Electric Druid
>Synth & Stompbox DIY
>==================
>
>> On 21 Sep 2017, at 11:56, paula at synth.net wrote:
>> 
>> Tom,
>> 
>> for 008 we used an analog devices 14bit DAC, which is beautiful, but
>is SMD and quite pricey (but SUPER linear and stable).
>> 
>> If you want more bit depth/resolution, why not use two DACs and have
>one driving the Vref of the other?
>> A single MCP4922 should do the trick (available in Through hole too),
>12 bit, dual channel external Vref for each DAC.
>> 
>> Paula
>> 
>> 
>> On 2017-09-20 13:19, Tom Wiltshire wrote:
>>> Hi all,
>>> A little while ago I was asking about setting the lowest frequency
>on
>>> a V3340 oscillator, because I was struggling a bit. In the end, it
>>> seemed to be only prototype woes, and the board has been fine since.
>>> Since then, I’ve been experimenting with autotuning the VCO using a
>>> PIC (a 16F1778), and I thought some of you might be interested to
>hear
>>> a progress report.
>>> I have the PIC receiving a MIDI input and producing control voltages
>>> for the VCO via both channels of a MCP4822 dual 12-bit DAC. The
>pulse
>>> output of the VCO drives a NPN transistor to pull down one of the
>>> PIC’s input pins to act as a tuning input.
>>> Tuning the VCO isn’t too difficult, except at the very low end (I’ll
>>> come to that in a mo). I’m using the typical “successive
>>> approximation” method, which is described nicely in the Prophet T8
>>> service manual. In short, you set the highest bit of the DAC, then
>>> measure the waveform period. If the waveform period is too short,
>you
>>> clear the bit, and otherwise you leave it set. Then you move to the
>>> next bit down, and set that and repeat the test. When you get down
>to
>>> the lowest bit, you have the DAC value that gives you the nearest
>>> frequency below your required frequency. Note any errors are always
>on
>>> the low side because of the algorithm.
>>> There have been some quirks. One is that I’m running the PIC at
>32MHz,
>>> and consequently have 32MHz or 8MHz available as 16-bit timer clock
>>> frequencies. Even with prescale settings of /2, /4, or /8, this is
>too
>>> fast to measure frequencies below 16Hz. I got around this by keeping
>>> track of timer overflow, which effectively gives me a 17-bit
>counter,
>>> which is *just* long enough for the job. To be honest, no-one will
>>> notice tuning errors way down there anyway - it’s on the border of
>>> sub-audio.
>>> Another quirk is using a cheap SPI DAC with only 12-bit resolution.
>>> There are some nice TI 16-bit DACs available in 8-pin DIP, but they
>>> cost £10/unit, unlike the one I’m using. Obviously I could go SMD,
>but
>>> I’m avoiding that.
>>> Twelve bits isn’t enough to produce a good CV over the full MIDI
>note
>>> range. 4096 / 128 notes = 32 sub-semitone steps, or about 3 cents -
>>> not audible, but borderline. So I’d thought to produce an fairly
>>> general “Octave CV” on one channel and a more detailed “Note CV” on
>>> the other, which would cover only a part of the full range - say
>four
>>> octaves (4096/48 = 85 steps, much better). This seems to work pretty
>>> well, as far as it goes. I can’t decide how wide to have the Note
>CV.
>>> Would it make sense for it to only cover a single octave? That’s the
>>> most efficient in some ways, but by making it wider, I can do larger
>>> pitch shifts without having to change the Octave CV. That makes
>>> updates quicker and also removes the risk of a glitch at the moment
>>> the octave switches. It’s “six of one and half a dozen of the
>other”,
>>> as we say in English.
>>> Another problem is the SPI interface. Since I have to send two bytes
>>> to program a 12-bit variable into the DAC (so four bytes for the two
>>> CVs) there is a limit to how fast the DAC can be updated. You can
>then
>>> reduce that theoretical maximum another chunk to allow for actual
>>> calculation time. This is a problem for something like MIDI pitch
>>> bend, where the data needs filtering (e.g. more calculation time)
>and
>>> also needs sending out frequently enough no steps are audible.
>Adding
>>> smoothing to the analog CV would be one solution, but if the steps
>in
>>> the Pitch Bend are heavily smoothed by analog filtering, then no
>rapid
>>> changes in Note CV are possible. Unless you change things around and
>>> use a separate channel for Pitch Bend CV, with the Bend CV filtered
>>> and the Note CV not - but then that’s three DAC channels for one
>note!
>>> Not very efficient!
>>> The advantage of that is that *only* the Pitch Bend CV has to update
>>> rapidly. The Note and Octave CVs can change only when a new note is
>>> played - much simpler.
>>> Finding the best way to do this with low-cost and easily-available
>>> chips is proving not entirely straightforward. There are a lot of
>>> possible ways to arrange things in terms of the range of the various
>>> CV channels and the distribution of different data to the CV
>channels,
>>> and I’m experimenting to see what gives a decent result.
>>> Hope this is of interest,
>>> Tom
>>> ==================
>>>       Electric Druid
>>> Synth & Stompbox DIY
>>> ==================
>>> _______________________________________________
>>> Synth-diy mailing list
>>> Synth-diy at synth-diy.org
>>> http://synth-diy.org/mailman/listinfo/synth-diy
>
>
>_______________________________________________
>Synth-diy mailing list
>Synth-diy at synth-diy.org
>http://synth-diy.org/mailman/listinfo/synth-diy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20170921/94d43d06/attachment.htm>


More information about the Synth-diy mailing list