mandag 11. september 2017

Noise research

I intend for the XM8 to have noise as a waveform for both oscillators, and also to be able to switch between various 'colors' of noise. At the very least, white and pink noise should be present, possibly even red. But what exactly does this mean?

White noise is noise where the signal has equal intensity at all frequencies. In the synth world, it is commonly generated by using a transistor with one leg disconnected.

Pink noise is a signal where each octave carries the same amount of noise energy. But how is this achieved in practice?

According to Wikipedia, pink noise falls off at 3dB per octave. To get pink noise one filters white noise through a filter with 3dB/octave drop off.

Problem is, most basic active low pass filter has a 6dB drop off (which would actually give us red noise if used). So how may this be solved?

This page shows one method - use multiple filter sections to approximate a 3dB filter with a flat response. The more sections the better, but even four sections is pretty good for a 20-20 000kHz signal.

As a side note - the same page mentions NP capacitors, bipolar electrolytics, and says that film capacitors cannot replace them - this is interesting information as I've stumbled across NP in other circuits.

A similar approach seems to be in use on this page, which is a modification for the Sequential Circuits Pro One. It uses fewer sections (two?) and has an additional cap (C3).

But how does one calculate the frequency of each section?

In a normal active low pass filter (6dB), the frequency is 1/(2*PI*R2*C) and the gain is -R2/R1 where R2 is the resistor in the feedback loop.

It seems that the same holds true for each section in the multi section filter. For example:

1/6.28*100nF*1MOhm) = 1.59Hz
1/6.28*33nF*330kOhm) = 14.6Hz
which matches the frequencies next to the sections.

This would mean that the lower section of the Pro one filter is 338.8Hz, but the rest - the 270k and 3.3n combined gives us a 268.1Hz filter which seems a bit strange - however, I'm not sure this is the way to calculate the combined frequencies.

As for the gain, if the same formula as before is correct, it would be -270k/15k = -18.

The pink noise filter in the pro one matches the inverting shelving low pass filter found on this page. However, the only formula, found in the gif, is missing the lone cap in the feedback circuit.

Funny enough, the same filter topology is found in the BOSS CE-2 pedal's de-emphasis filter :). The de-emphasis filter reduces treble, which of course means it is a low pass filter of sorts. :)

On that page, the circuit is fully explained. When calculating the frequencies, the lone cap is omitted. It says that it is an LP of some sort but it is not essential when calculating the shelving frequencies.

The filter right after the transistor in the pro one circuit is a simple non-inverting HP filter. I am not sure exactly what C2 does.

The first filter in the Ray Wilson Noise Cornucopia is a simplified non-inverting amplifier filter as shown here and here. Its gain is 1 + R10/R9 (=48), the frequency is 1/(2*PI*R10*C4), or approx 34kHz.

ERROR: det er et lowpass non inverting shelving filter.

lørdag 9. september 2017

Wiring the Xonik PSU3 v1.0

The Xonik PSU3 v1.0 is a copy of the Ken Stone CGS66 Rev 1.1.

In addition to the dual voltage of the CGS66, it has a third part meant for digital/logic voltage.

The input to the third channel may either be a dual secondary/centre-tap transformer or a single secondary. If using a dual secondary, do NOT connect D11 and D12.

Using two transformers - connect earth to ground/0V on both connectors and mount D11 and D12

Using one transformer (or two centre-tap transformers): do NOT mount D11 and D12.
NB: Remember to fit suitable fuses and switches on the primary sides of the transformers.

The colors on the dual secondary transformer are the ones used on my Noratel TA050/15:

PS: The Xonik PSU3 has the main smoothing capacitors mounted close to the heat sinks. If the heat sinks get hot, the lifespan of the caps may be reduced.

On transformers and rectifiers

Everywhere that you find information about transformers, it says "make sure that you know what you do, these things can kill you".

Well, I thought I knew, but I still managed to mess up. I didn't get killed, but I learned a bit about transformers and rectifiers.

Let me explain.

There are two basic ways of turning an AC voltage into a DC voltage. One uses a half wave rectifier, the second a full wave rectifier.

The difference is that the half way rectifier only uses the positive part of the voltage swing, whereas the full wave rectifier uses both parts by magically reflecting the negative part. The full wave rectifier requires a few extra diodes but gives a smoother DC voltage (or at least one that requires a smaller smoothing capacitor and is more efficient).

Then there are two basic transformer configurations - single and dual secondary. When the two outputs of the secondary are of equal voltage, and the "bottom" of one is connected to the "top" of the next, we call it a centre-tap transformer. This kind of transformer is often used if you want a dual voltage output, for example +15V and -15V for audio circuits.

Here is how the different transformers may be connected for a single output voltage.

First off, a single secondary, half wave rectified configuration:

Here, the lower pin of the secondary is connected to ground, and the top is connected to a smoothing cap through a power diode.

Then we have the single secondary, full wave rectified configuration:

Here, none of the secondary output pins are connected to ground. Instead, they are connected to the top and bottom of a diode bridge rectifier. Then, one of the other rectifier junctions is connected to the smoothing cap, and the last one is connected to ground.

Now, if we have a centre-tap transformer, we get to use a little trick:

Instead of using four diodes, we get away with two. Ground is connected to the centre tap.

So what if we want a dual (positive and negative) output from a centre-tap transformer? Well, just duplicate the circuit, but turn the diodes the other way around for the second half.

This looks suspiciously like the full wave rectifier for the single secondary transformer, but there is a crucial difference!

Instead of connecting the last pole of the diode bridge to ground, it is used as the point where we tap the negative voltage/connect the smoothing cap for the negative voltage.

This may seem obvious, but when I tried to use a centre-tap transformer for a single output voltage, I didn't think this part trough. I left the four diodes in and connected both the last pole of the diode bridge AND the centre-tap to ground. This immediately blew the input fuses (luckily I was using fuses) and it is easy to see why: With the diodes in place there is a direct short (well, through the diodes anyway) between the negative half wave and ground, which drew a large current.

As for my circuit design - the fact that I both have a three pin input with one pin connected to ground, and room for four diodes in the bridge rectifier, means I can use both a centre-tap and single secondary transformer - as long as I do not connect the diodes when connecting the centre tap.

fredag 8. september 2017

DCO: Slow crystal startup

I have problems with the crystal startup on the DCO. For some reason the crystal doesn't start up properly, and the Fail-Safe Clock Monitor kicks in and starts the internal oscillator, which runs at 16MHz (The external crystal runs at 32MHz). Switching over to the external crystal again after startup works fine.

Someone on the mikroe forum suggested that this was due to a too high stray capacitance on the breadboard. Today I read up on crystals and capacitors, and tested a few combinations to see if I could get it to boot up at the right speed.

First of all, in the datasheet of the crystals, the parameter C load tells what capacitance to use. For my crystals this is 18pF.

I always thought this meant that each of the two caps should be 18pF. This is definitely incorrect. Instead, the total capacitance should be 18pF. But what does this mean?

First of all, the two caps connected from the crystal to ground are in reality two caps in series between the two legs of the crystal. Two equal caps in series have a equivalent capacitance of half the capacitance of one of them. So running two 18pF caps in parallel would yield an equivalent capacitance of 9pF.

But in addition to this, the crystal sees an additional capacitance CS. CS is the stray capacitance of the circuit and the input/output capacitance of the inverter or microprocessor chip at the Crystal 1 (C1) and Crystal 2 (C2) pins, plus any parasitic capacitances (here). This is normally around 5pF but may be higher.

The total capacitance C load should then be CS + C1 * C2 / (C1 * C2), which means that C1 * C2 / (C1 * C2) = C load - CS.

C1 * C2 / (C1 * C2), as mentioned, will be half of C1 if C1 = C2.

For my crystal then, C1/2 = 18pF - 5pF = 13pF, which means C1 should be 26pF (or 27pF, which is a standard value).

So, would changing from 18pF to 27pF on the breadboard change anything?

I tried the following combinations with the following results (half frequency means the MCU fell back to the internal oscillator):

18pF: half frequency
22pF: half frequency
33pF: half frequency
36pF (two 18pF in parallel for each side): half frequency
9pF (two 18pF in series for each side): CORRECT frequency!

This is strange and interesting. At 9pF the serial equivalent is 4.5pF (leaving "room" for CS up to 12.5pF). At 18pF the serial equivalent is 9pF (with CS up to 9pF). If my reasoning is correct, the stray capacitance is more than 9pF. It does not sound implausible. I will have to retest this once I get a PCB made, in theory at least 27pF caps should be the ones to use.

fredag 18. august 2017

Program memory block size

When writing to program memory from code, it is necessary to be aware of the fact that writes happens in blocks. You cannot write a single word/instruction, instead you write what is called a row or block.

I have not tested this i practice, but this datasheet gives us the row size for the PIC16F18325 when writing through the ICP - presumably it's the same for programmatically written data as well:

"When write and erase operations are done on a row basis, the row size (number of 14-bit words) for erase operation is 32 and the row size (number of 14-bit latches) for the write operation is 32"

As each word takes up 14bits, you have to write two bytes to fill it (the two MSB are ignored). Thus, rows are 32 words but 64bytes long when dealt with from code.

PS: Before doing a write, you have to erase the memory you want to write to. Erasing flips all bits to 1 whereas writing can only flip bits to 0. If bits are not 1 when writing starts, it will not be possible to get a 1 after writing either.

Program memory size on MCUs

Funny thing: In most MCU datasheets, the program memory size is listed in KB. The PIC16F18325 for example is said to have 14KB of program memory.

Don't let this fool you! It does not mean that you can store 14KB of data/constants.

The problem is, each word (instruction) on the PIC16 is 14bits long. Storing an 8bit constant in program memory (flash/ROM) takes up 14bits of space.

So how big is the memory really? That's easy: 14KB = 14 * 1024 * 8 = 114688bits, divided by 14bits per word = 8192. Thus, the "real" memory size is 8KB - you can store 8K instructions or constants.

fredag 4. august 2017

DCO: Culprit found but not fixed

I did extensive testing of various op amps yesterday, and as suspected, the amplitude error at low frequencies is caused by the op amp. I also tried recalibrating the power supply but that had no effect whatsoever.

The results from various opamps varied wildly, and results from positive and inverting buffering configs also varied a lot.

My best hit was with a UA741, in inverting mode the amplitude was perfect across the entire frequency range! Unfortunately, it was only a lucky strike, I retried several other UA741s and the result varied from around 7 to around 13V amplitude (when the real amplitude should be 10V).

The conclusion then is that at voltages very close to zero will experience a lot of variation even between specimens of the same family.

Tested op amps

UA741 variations

I am not sure how the effects are over time and temperature, this must be tested.

If  the effects are mostly production variations, it would be possible to calibrate each DCO.

This can be done in code even if DAC lookup tables must reside in program memory due to RAM limitations (1kB of memory is required for DAC keystep and rise-per-substep tables and the MCU only has 1kB of RAM in total). The PIC16F allows programmatical/runtime writes to flash program memory, and though there is a limit to the number of times this can be done (>10 000), even a write on every system startup would probably be possible.

Hopefully though, calibration will seldom be necessary. As a nice side effect, calibration will correct variances in both charging caps and resistors as well as opamps.


Here is how I imagine it to be done:

A reference voltage is applied to one of the MCU pins. This is used as the reference voltage of one of the internal comparators.

First, apply the lowest frequency. By increasing and lowering the DAC output voltage until the comparator changes polarity, we figure out
- if the voltage is too high or too low
- if the amplitude error is within acceptable limits

A slightly too low amplitude is acceptable but a too high amplitude is not as this will trigger the comparator during normal operations, if we choose to use it as a reset-on-frequency-change trigger. The amplitude must also be adjusted to always be slightly lower than the comparator trigger point to prevent false triggers.

We also have to consider measuring the highest frequency amplitude error to see if errors are always either high or low. For now, I'll assume that they are always one or the other.

After finding the initial error, one loops through the remaining 255 samples, starting from the bottom.

For every frequency, the DAC voltage is increased or lowered (based on what we found for the lowest frequency) until the comparator changes polarity - this gives us the "correct" value for that step. To save time, we may stop checking once we reach a frequency where the error is small enough (and lower than the comparator voltage).

We should now have a correct lookup table for key samples. All that is needed now is to calculate the interpolation lookup table, and write everything to non-volatile flash memory.

To minimise the number of recalibrations, we could let the DCO check the keysamples on startup. If they are still within limits, no recalibration is necessary.

A different approach to finding the current amplitude would be letting the DCO control a PWM-based DAC to generate the reference voltage. It could then change the reference voltage instead of DAC output value to find the amplitude. Not sure that it's a better approach though.

PS:  If the signal amplitude is 10V, using a resistor divider with R1 = 100k and R2 = 68k will get the amplitude down to 4.048V. This lets us use the internal 4.096V voltage reference with the comparator.

onsdag 2. august 2017

DCO: Switching to JFET to try to improve low frequency amplitude

To try to fix the issue I'm having where the saw wave amplitude is too low at low frequencies, I decided to redesign the core using a JFET in place of the BJT that resets the integrator.

I found no p-channel JFET in my parts box, but I had plenty of the J112 n-channel JFETs, so to make things easier I decided to go with the yusynth design.

The Yusynth design however, has a 0-5V saw wave, whereas mine is 0 to -10V. To make sure things would still work, I changed the core ever so slightly to get a 0-10V:

instead of tapping the charge voltage directly from the DAC using a positive opamp buffer, I switched to a unity gain negative amplifier. This would sink current instead of sourcing it, changing the charging direction. To make this works one also have to replace the 2n3906 PNP transistor with a 2n3904 NPN (One should also switch the polarity of the timer output, but as both a positive and negative going spike are generated, just slightly offset in time, this was not required for testing).

But testing this, I got a big surprise - the low frequency amplitude was no longer too low - it was too high! Previously I had to increase the DAC value from 60 to 80-something, now I had to reduce it from 60 to 48 (steps times 5V/65536).

This made me less certain that switching to a JFET would improve anything, but I still decided to try it.

I added an LM311 comparator, and set its negative input to 0.118V using a 120k and a 4k7 resistor. This would assure that when the positive input was just slightly higher than 0V, the output would spike up to 15V, and when the input was 0V the output would be -15V - similarly to the yusynth circuit, where the comparator outputs a negative voltage to turn off the JFET. The circuit worked instantly (!), but as suspected, nothing changed.

So, now I guess I've ruled out the reset transistor as the cause of the offset. Also, the fact that the amplitude error changes when I swap the charging polarity, makes me believe that the cap is not at fault either (though I will still check this).

That leaves either the DAC (which is unlikely for the same reason as the CAP) or the opamp buffer.

It could also be that a small difference in the power lines (measured to +15.01 and -15.00 volts) could cause this, I don't know. I will try recalibrating and also try different opamps to see if that changes anything.

For reference: Here is the original breadboarded circuit with the 0 to -10V output. I have since added the missing 2R2 resistor, however, that changed nothing. The DAC is connected where the 20k pot is in this drawing

tirsdag 1. august 2017

Yusynth VCO core discharging

I may have written about this before, but here goes:

The Yusynth saw core ramps down from 5 to 0v, then resets to 5v. the top of the charging cap is always at 5V while the bottom drops towards zero as current is sunk through the expo converter (u4).

The LM311 comparator has its positive leg grounded (when sync is not used). The LM311 is an open collector type comparator. For these, the rule, as written here, is that: 

"Current WILL flow through the open collector when the voltage at the MINUS input is higher than the voltage at the PLUS input.

Current WILL NOT flow through the open collector when the voltage at the MINUS input is lower than the voltage at the PLUS input."

When current does NOT flow, the output is pulled towards 15V via R20. When current flows, the output is pulled towards -15V which is connected to pin 1 of U5.

Pin 1 is called ground, but it can be connected to a lower voltage if necessary.

During capacitor charging, the voltage at the minus input is positive and thus higher than the positive input. In this case, current flows and the output is negative.

Once the negative input reaches 0V, for an instant, the input is lower than the voltage at the positive input, and current stops flowing. The output is then pulled towards +15V.

This would mean that as long as the output is negative, the JFET transistor is switched off, and once the output is positive, the JFET conducts, resetting the cap.

This is in accordance with what wikipedia says about an n-channel JFET:  "To switch off an n-channel device requires a negative gate-source"

 The source and drain of the transistor will always be between 0V and 5V, thus a -15V gate voltage assures that it is turned off. Similarly, source and drain will never be above 5V, so a +15V will always turn it off.

Since the source/drain may however reach 0V, the emitter of the transistor cannot be connected to ground - this would leave the comparator output and thus the JFET gate at about 0.6V, which is not enough to keep it pinched off.

DCO: comparator to reset period

I've been thinking about ways to enable frequency changes in the middle of a period without having to restart the period, which resets the phase.

My thought so far has been to use a comparator with a reference voltage set to slightly higher than the maximum amplitude of the wave, and reset the period once it triggers. That way we can reset the timer and set a new charge voltage anytime, and it will just slightly overshoot the desired amplitude. I would think that this could be a good solution, but it has some issues.

1) The amplitude may be temperature sensitive - if the capacitor charge time varies with temperature or if the charging current changes due to temperature effects on the resistor.

2) Setting such a reset point requires a trimpot and a way to check that the point is not set too low, in which case it would interfer with the normal operation of the DCO

As for 1), that is just something that has to be tested. But in case 2), it would be possible to let the microcontroller figure out the cutoff point by itself. If the MCU controls the reference voltage, it can loop through all frequencies (or at least a subset) and find the maximum amplitude during normal operation, then set the reference voltage to slightly higher than this. It would also be possible to rerun this operation later if temperature rises. The cutoff point may be found either using an analog pin, or it can be done using the comparator and gradually lowering the reference voltage until the comparator triggers.

The MCU has a built in comparator. It also has a built in DAC that can generate a reference voltage, but its resolution is only 5 bits. We need something better than that, but we do not want to add another spi controlled DAC or similar.

A possible solution: Use the built-in PWM generator in conjunction with a lowpass filter to generate a DC voltage.  This post, this article and this article has some filter suggestions.

mandag 31. juli 2017

Wave centering - bias circuit

The DCO generates a wave running from 0 to -10V. To center this, I tried using two resistors and a 1uF capacitor, followed by a buffer. This works fine for higher frequencies, but at the bottom of the frequency range we get severe distortion, turning the straight lined saw wave into a slope.

Also, this arrangement won't work for Pulse signals as the pulse width has more energy at either top or bottom.

The square and pulse waves are a bit interesting as the amplitude CV does not have to run through a VCA. Instead, the amplitude is equal to the CV. This means that subtracting half the CV from the output wave will center it.

I've come up with the following, untested (and incomplete) circuit that shows my idea:

DCO: too low amplitude at low frequencies

The DCO is nearly finished, but a somewhat serious problem remains. At low frequencies, the saw wave amplitude drops significantly - at the lowest frequency, 8.16Hz, it is almost half of the expected value.

Fortunately, this can be compensated for by increasing the capacitor charging current at the low end. Using an oscilloscope, I've measured what increase in DAC output voltage is required to get the correct amplitude. The plot of frequency vs dac increase (in dac steps, each step is 76.3 uV, which when placed across a 56k resistor equals a current of 76.3uV/56kOhm = 1.36nA per step) is like this:

It shows that as the frequency drops, a higher and higher correction is needed to reach the correct amplitude in the available time. It also shows that the correction necessary is negligible for frequencies above 300Hz.

This plot shows the expected charge current vs the required one for the same range, blue being the expected and orange the required:

I am trying to find a function that fits what I see, to make it easy to add the necessary charge voltage to the precalculated dac lookup table. I've had some success with exponential regression but it doesn't quite fit.

But what is the effect I'm seeing? Why is a larger current than expected required at low frequencies, and why does it change?

The only thing I can think of is that we have a leak somewhere - some of the charge in the cap leaks out, or some of the current goes somewhere else or is turned to heat etc. As this effect goes on for a longer time the lower the frequency, it is a reasonable assumption which fits what I see.

There are very few parts involved in the integrator. A capacitor, a transistor and a 2.2Ohm resistor which I suspect is there to limit the current during capacitor discharging.

I tried removing the resistor, nothing changed. This leaves the transistor and cap.

A BJT like the one used in the DCO has a maximum leakage current of 15nA at 30V. It will be less at lower voltages, but not necessary propotionally less, according to this post. While I haven't tried to do any calculations, this is in the same range as the currents required to correct the error.

The Yusynth VCO, which also has an integrator core, uses a n-channel JFET instead of a BJT, and specifies a high quality capacitor - styroflex or silver mica, 1%. A JFET has a much lower channel-to-gate leakage current than a BJT, so this may improve things. I will try this, but it requires a slight redesign of the circuit.

onsdag 26. juli 2017

Technics sx-k100/150/200/250

I keep forgetting which is which of these. On the Rockheim pages ( they show the sx-k100 and mention that the sx-k200 was launched at the same time. Also, they say that the sx-k100 is the one used by Knutsen & Ludvigsen, but I have to check this with my photos from the exibition.

Anyway, these are the facts:

The sx-k100 and sx-k200 seem to be the analog ones. The sx-k200 has a solo synth part that the sx-k100 lacks.

The sx-k250 is labeled "PCM keyboard" in the photo of the cartridge bay here:

The sx-k200 here lacks that text.

The sx-k150 is sold as a PCM keyboard on Gumtree.

Conclusion: For me, the sx-k100 or sx-k200 are the ones to get.

mandag 24. juli 2017

Jupiter 8 X-mod

The Jupiter 8 has two oscillator, and the output of oscillator 2 can frequency modulate oscillator 1.

Oscillator 1 has four waveforms:
- Saw
- Triangle
- Pulse
- Square

I am not sure why both pulse and sqare are present as only one can be connected to the output at the time.

Oscillator 2 has these outputs:
- Sine - which replaces the saw form osc 1
- Triangle
- Pulse
- Noise

The x-mod input is tapped after the oscillator 2 waveform selector, to any of the osc 2 waveforms may modulate osc 1. X-mod has its own VCA The X-mod output (a current, as it is the output of an OTA) is mixed with the rest of the linear CV input, so x-mod is linear.

fredag 21. juli 2017

XM8 filters

I want the XM8 filters to be as flexible as possible. I've studied the various IR3109 based roland filter implementations and the CEM3320 ones found at Electric Druid, and found designs for state variable filters based on both.

I am thinking about having exchangable filter cassettes, possibly with two identical filters per cassette. I tried to find a common control scheme, but right now I think that just using a shift register to serially control the filters will be the most flexible - that way variations can be software controlled instead of implemented in hardware.

I also want to have two filters per voice, configured in either series or parallel - one state variable and one permanent LP.

I've found six different implementations using the IR3109 chip or similar. The JP4/6/8, the Juno 6/60, the JX-3P and the MKS-80 all use the IR3209. The MKS-7, MKS-30 and Juno 106 use the 80017a filter chip which is basically a combination of an IR3109, two BA662 and some additional components. I have not studied the use of these in detail, just compared the resonance and control circuitry.

SH101 and MC202 also use the IR3109, I have yet to look at those.

There seems to be a progression in the circuit through the years. Exact component values varies but all except two of the implementations use the same circuit for the filter part. The resonance feedback control and the cutoff frequency control circuits are quite different between the synths.

The JP-6 and the MKS-80 stand out however. The JP-6 has a state variable filter that allows both HP, LP and BP filters - the two first 24dB and the last 12dB. It would be easy to add 12dB HP and LP too, but this has not been done. The MKS-80, weirdly enough, has the same configuration as the JP-6, but hardwired to a LP.

The JP8 and the Juno 6/60 uses the exact same filters/component values, except for a few minor differences in the resonance feedback and cutoff frequency control. The JP8 can be tapped at 12dB or 24dB whereas the Juno is 24dB only. An interesting thing to note is that the Juno 6 datasheet indicates the CV for cutoff: 0.48V/oct.

All implementations have a posistor in the control circuit to compensate for temperature variations. The JP6 and MKS-80 have a posistor in the resonance circuit too.

State variable filter
I currently consider these implementations:
- The JP-6, with the added option of 12dB HP/LP
- The Elka Synthex CEM3320 based filter
- The CEM3320 multiple identity filter
- The Wasp filter.

Permanent LP filter
- The moog ladder filter
- possibly the Juno filter, if it actually sounds different than the JP-6 filter
- Possibly a SSM2044 (SSI2144) based filter - Korg PolySix or MonoPoly
- Korg MS20
- ARP4270 (ARP 2600)
- EMS Diode ladder filter

I will start out with the JP-6 and moog ladder filter and go from there.

digital: serial input, clock, load
analog: resonance CV, cutoff CV

digital, 12dB/24dB switching
analog: resonance CV, cutoff CV

tirsdag 18. juli 2017

BA662 pinout

While drawing up various uses of the Roland IR3109 VCF-chip, I needed to make an Eagle part for the OTA used in the resonance circuit. My initial circuit was the one from the Jupiter 4 service manual, and it uses a BA662, IC17:

The service manual only shows a part using four pins while the BA662 has 9:
This shows that the BA662 is actually an OTA and a buffer combined into one package. The buffer is apparently not used in the JP-4, so how is it disabled?

The Juno-6 and Juno-60 service manuals answers the question:
Pin four, the buffer control, is connected to -V and the buffer input is connected to +V. The buffer output, as expected, is not connected to anything.

Incidently, the IR3109 itself is just four OTAs, four buffers and an exponential converter connected to the control of each OTA.

onsdag 12. juli 2017

It's alive!

The XM8 just made its first ever sound - controlled by midi from a little phatty to the XM8 Voice controller, through the OMM and on through SPI to the DCO. Playing worked like a charm - pitch changes are delayed but that is to be expected since the SPI speed is set to a minimum right now. I had a lockup too, somewhere in the Voice controller code, but all in all I'm really pleased!

The tracking is awfull, I think I've used different intervals for semitones in the Voice controller code and the DCO, but it is very clearly playing semitones.

Woohooo! Videos to come.

onsdag 21. juni 2017

DCO - aribtrary reset point

I've been a bit worried about the fact that the DCO frequency may only be changed when the period reset timer runs. At low frequencies this may mean a noticeable loss of timing presision - worst case for a 20Hz signal would be 1/20 s off. At 120BMP, the duration of a 1/16th note is 1/32 second, so it will miss by a lot. If my calculations are correct, playing "flight of the bumblebee" at near-unhearably low frequencies will be impossible ;-) I am not sure how much of a problem the inaccuracy is in practice, but it is something to investigate further.

This constraint is there for a good reason, as we need a perfect match between charging voltage and reset time for the saw wave to get the correct amplitude.  If we choose to change the charge voltage at any given time, without changing the reset timer, the amplitude of the first cycle after the change will be either too high or too low.

Idea 1:
Ideally, we should change the remaining time of the reset timer too. This would be a case of subtracting the current remainder from the new period timer value, correcting for the time the calculation takes, and then updating the timer - IF the time the calculation took was less than the remaining time.

This is slightly more complicated than what it sounds like. As the current timer and the new timer may not have the same prescaler, we need to take this into account when calculating the correct reset values. We also need to make sure we don't mess up the reset pulse timer.

Idea 2:
A different approach would be to do the first reset in hardware. If we connect the saw output to a comparator, and check if the level is just slightly larger than the normal, correct amplitude, we could trigger a reset using the sync input, preventing a large amplitude error. The amplitude error that is inevitable because the reset point must be larger than the correct amplitude is hopefully small enough to be inaudible. This lets us change the charging voltage at any time and still not get a large amplitude error.

This will fix the case where the amplitude is too large, but the case where it is too small (e.g. the new charge voltage is lower) will not be fixed. To fix this, we must also reset the period timer at the same time. Doing so guarantees that the charging time is at least long enough for the new charging voltage to fully charge the cap. In most cases the charing time will be too long as it adds to the time already elapsed since the last reset, but then the previous comparator fix will reset the period at approximately the right time.

The disadvantages to this method may be:

  • Charging time may change slightly when the ambient temperature changes. Resistor values barely change so I have to check the effects on the charge capacitor.
  • The amplitude of the first period will always be slightly wrong after a frequency change. Not sure if that will be audible. It may possibly only be a problem for fast changing pitch.

Idea 3:
A third method would be to always reset the cap at the instant a frequency change occurs. The timing will then be as accurate as possible. The main disadvantages are

  • The saw wave will always start at the same position. Two DCOs running in parallel will then be in almost perfect sync.
  • A fast changing pitch will reset the timer multiple times per second, possibly hundreds or thousands of times. At low frequencies this means no saw wave runs to completion, giving us a way too low amplitude (though shifted to the maximum).

I will give the choice between 1 and 2 a more thorough thought and try to build 2 to see how it feels like. All options may be retrofitted to the current DCO even if the PCB has been created, as the comparator circuitry can be housed outside of the DCO itself..

onsdag 7. juni 2017

DCO core up and running

After spending a long time converting and optimising the DCO code for the PIC16F18325, I finally connected a DAC and tested the thing last night.

All frequency tests seemed ok, and the charge current tracked the frequency almost perfectly, charging the saw core capacitor to 5V even if frequencies changed. Only for the lowest frequency I tried (16.35Hz) did the cap not fully charge. I successfully tried frequencies up to 7000Hz. At 14000Hz the charge current was once again too low, but this was expected as the DAC output cannot reach a high enough level with the current combination of cap and charge current converter resistor (100kOhm). I tried swapping the resistor for a 56k one and the saw voltage swing doubled as expected, so a little experimenting with various resistor values will probably fix this issue.

I have had some issues with the saw core op amp oscillating. Not sure what causes it (well, I suspect it is due to the capacitor in the feedback loop), but some brands seem more susceptible to this than others.

I've tried the TL072CP and TL062CP from Texas Instruments and they both oscillate. TL072BD and 4556D from JRC work fine. Maybe the B/C difference could explain it.

The DCO uses modern, easily available components, the reset transistor is a 2N3906. The DAC currently used is a MAX541, with an SPI speed of 8MHz. The 'production version' will probably use a MAX5216 as this is way cheaper.

I was not aware that I could get such a high speed, now I consider moving the DAC update into the interrupt routine. It will probably double the time spent in the routine, but even this would only reduce the max transfer speed from the master controller to the DCO to around 950kbps, meaning we could still update the DCO 50.000 times per second (or rather, transfer new pitch values, the DCO will only update at period reset positions).

Next up is adding and testing SPI control, then recalculating the lookup tables to be centred around Cs (a C should be at 32768 = virtual 0V). Then finally breadboarding the wave shaper circuitry and deciding on voltage control and how to center the waves around 0V.

I must also decide the p-p voltage output. 12V seems to be the Juno way, this is the highest "safe" voltage possible since the saw is generated between gnd and the negative power rail (-15V). I assume that keeping the voltage as high as possible up to the point where several waves are summed is a good idea, to keep noise to a minimum.

The charge current is a bit too low at the lowest frequency

The dots above the peak of the saw wave is the reset pulse

The reset pulse gets more and more visible as the frequency increases and we zoom in

The charge current is too low above a certain frequency. This will be fixed.

mandag 29. mai 2017

Juno saw sub oscillator

Someone mentioned that there is such a thing as a juno sub osc mod that gives you a saw sub oscillator.

Now, I know nothing about this mod but I can immediately think of two ways of doing this:

1) Use my saw sub osc design that combines the saw with the square to shift and attenuate the saw wave and making a wave one octave down

2) Replicate the saw core - let the sub osc output control the reset transistor, and tap (a buffered version of) the charge voltage from the DAC output and attenuate it 50%

Should be an easy fix :)

søndag 16. april 2017

Juno 60 pre-filter level control

The Juno 60 mixes several waveforms before the filter, and it has a clever way of controlling the sub oscillator volume. As the sub oscillator output is a square wave, the wave is considered a binary on/off signal. It is connected to the base of a transistor, which when turned on and off either sinks its collector to ground or leaves it as it is.

To control the wave volume, the collector input is connected to the panel potentiometer (through a series of buffers/mux/demuxes, but that doesn't really matter, the principle is the same). The wave's amplitude (or "on value") will then equal the level of the panel potentiometer, though negative as the potentiometer value is inverted by IC17 on panel board A. The voltage is passed through an analog switch, IC16, which in turn is controlled by the Sub oscillator on/off switch, to completely disable the sub oscillator (incidentally, this feature has been removed from the Juno 106, here the potentiometer voltage is connected directly to the transistor collector).

Interestingly, the same arrangement exists for the pulse wave, only this time the analog switch connects the transistor to -15V instead of to a variable voltage. If one would like a controllable pulse wave volume, it would likely be easy to inject the control signal here.

As for the saw wave, it also has a switch and a transistor connected to it. However, as the saw wave is not binary, it cannot be controlled the same way. Instead, the wave is connected to the collector, and the transistor base is connected to the analog switch on panel board A. The wave is then sunk to ground if the transistor is on. In other words, the saw wave has no pre-filter volume control, only an on/off switch.

The noise input has its own volume control on panel board A (all voices use the same noise generator).

Oh, and by the way - all waveforms have a range of 0 to maximum -15V (the datasheet says the saw wave is 12V p.p, I have not checked the others but they have to be about the same to be mixable - the sub oscillator level for example originates as a 0 to +5V voltage but is inverted and amplified by IC17, and the pulse wave level is always 0 to -15V). They are fed through a 10uF non-polar capacitor (C5) just before the filter, which probably centers them around 0V.

onsdag 5. april 2017

Juno 106 vs 6/60 DCOs

There are some differences between the DCOs in the Juno 106 and the Juno 6/60 - except for the fact that the DCOs on the 106 are integrated into a single chip.

First of all, according to the datasheet, the 106 uses an NPN instead of a PNP transistor to reset the integrator (saw wave converter).

More interestingly, the way they sum the saw wave and the pulse waves are very different.

The Juno 60 has a separate control line for the pulse wave, connected to TR2. It looks just like the one for the saw wave (TR3) so one can assume that it turns on and off the pulse output. Also, the output of the pulse is sent through D2 which will block any positive halves of the pulse (? which sort of makes sense as the saw wave is also negative only).

The 106 on the other hand, has no such control line, which means that the pulse output is always on. The pulse output has a diode to ground which I assume means that it will never be negative (?).

So how can the 106 output a saw wave and no square wave? One theory may be that if the user selects saw wave only, the pwm is set to 50%. Summing the sqare and saw waves will chop up the saw wave just as it reaches its half period, and move the remainder upwards. If the amplitude of the saw and square waves are equal, the saw wave will magically realign with its phase shifted half a period, this time centered around 0V.

DISCLAIMER: This is only my initial theory after studying the datasheets, no measurements have been made. 

But how about when both the saw and pulse waves are on? Wouldn't this mess up how the wave turns out? Since the saw wave is positive and the pulse is negative, couldn't the total amplitude end up being double?

Well, the high part of the pulse will always come at the second half of the period, thus it will never "lift" the saw wave from higher that minus half the total voltage p-p. Also, The parts that are lifted will only be lifted by 1 x the voltage p-p.

In practice, this means that if we could set the duty cycle to 0%, the output would be a saw wave that starts at 0 and drops to minus the total voltage p-p. If the duty cycle is 50%, we get a saw wave with the same amplitude centered around 0V.

This is interesting and may reveal a flaw in my assumptions. As the wave is centered around 0V by a capacitor later, summing a pulse and saw wave this way will only shift the saw wave phase! I need to check if the polarity and phase assumptions for the square wave actually holds. What happens if instead the polarity is reversed or the phase shifted by half a period?

TODO: Write about SUB OSC and level control (done by using the output from the DAC) and how the passing through a diode affects the signal (reversed in one)- one uses NPN and the other uses PNP, 60 has a resistor to GND at the transistor base. The 106 has no on-off switch for the SUB OSC, only a volume control.

Both the 106 and the 60 DCOs have their outputs mixed with noise (with adjustable volume) right before a 10uF non-polarized cap and injected into the IR3109/800170 filter chips. The mixing point has no opamp connected to it so I assume this job is done by the chips. I guess the cap is there to filter out any DC component and center the waves around 0V. I have not looked closely at this - what happens here when the frequency changes for example, will still stay centered during the transition because the amplitude is still the same?

BTW: NP in the juno datasheet means Non-polarized (capacitor). MF means metal film (resistor).  G (capacitor) may mean 2% (needed for accuracy in the integrator).

mandag 3. april 2017

DCO saw core testing

I built the DCO saw core on a prototyping board Friday evening, and after some initial trouble, I got it working very well.

The core is heavily inspired by the Juno 6/60 DCO. The output of the MCU charges a capacitor, turning the output square wave into positive/negative spikes on each square wave edge. These in turn briefly switch on a transistor that discharges a capacitor. When the transistor is off, the capacitor is charged using a constant-current scheme where the cap is connected across an opamp (just like in a normal saw core VCO, see section "That old opamp trick again" of

The Juno 60 uses a 2SA1015 PNP transistor. I tried replacing this with both a 2N3906 and a BC557, they both work very well.

MCU output pulse train (top) vs. transistor control spikes (bottom). top is 5V/square, bottom is 1V/square and shifted down to make both visible

I had no DAC available for the trial, so the charging current was regulated using a potentiometer as a voltage divider, buffering the output with an opamp and piping the result through a resistor to convert it to a current. After initially screwing up and connecting the center pin of the pot to ground, things started working very well.
A perfect 5v p-p saw wave generated from the pulse train on top. 

A few challenges still persist:

1) The output wave starts at 0 and goes downwards until it is reset. It has to be centered

2) My calculations are based on an assumption that the maximum voltage should be 5V. I completely forgot that it has to be 5V on each side of the wave, making the full wave 10Vp.p.

3) For some reason, the charging stops at -8V. Not sure if this is due to the opamp or something else, but it has to be fixed. The Juno 60 service manual says they have a 12Vp-p output, so it should be possible to fix this.
The charging of the cap maxes out at 8V (looks like 10V here but Y-offset was wrong).
4) Charging starts at the negative going edge of the MCU output wave while the MCU output wave is first high then low through the course of a cycle. This has to change, either in code or by replacing the PNP with an NPN transistor (The Juno 106 service manual says it uses an NPN but I couldn't get this working immediately. I'll look into it).

5) With a 100k charging current resistor, the charging current won't be strong enough for the highest frequencies. A 39k resistor may work (but not for a 10Vp-p wave).

6) I should check if a constant reset timer interval may work (e.g. not a 50/50 duty cycle for the MCU output wave). If so I'll save some clock cycles during frequency calculations.

torsdag 30. mars 2017

Alternative approach - DCO MCU

It would be possible to use a lower-end PIC32 MCU as the DCO MCU. We'll get a few advantages:

1) It can run at a higher speed so calculations will be faster
2) It may have enough ROM to store a full lookup table, or where we may only have to interpolate every second sample. As the MCU is 32bit, interpolation is a simple case of adding two adjacent samples and shifting right by one (dividing by 2).
3) Even with a lookup table, 16 bit multiplications are supported in hardware so calculations will be very fast
4) Both input and output SPIs are buffered so we need not fear losing bytes
5) It natively supports I2S so interfacing with cheap DACs from ebay is possible.

1) It may possibly be harder to write an accurate timer as it has a different architecture with more complex pipelining?
2) Price (but not an issue if using DACs from ebay).

BTW: a faster interpolation without the use of a derivative lookup table is also possible on the PIC18F if we choose one with at least 64k program memory, such as the PIC18F26k40. Chosing the PIC18F27K40 means we will not have to do any interpolation at all as it has 128k program memory.

søndag 26. mars 2017

SPI Daisy chaining

Just  a quick tip from the PIC18F datasheet: SPI interfaces on multiple MCUs may be daisy chained, connecting the output of one to the input of the next. They will then function as a long shift register, shifted 8 bits for every SPI send. NB: Chip select must be connected to all MCUs if used.

DCO: SPI and DAC accuracy

A few compromises have to be made when making the DCO. There are however a few things that must be done right.

First of all, we cannot afford to lose any input commands. This will put the SPI input buffer in an unknown state, possibly locking up the DCO.

With this in mind, we can do a few calculations.

First of all - each frequency update is based on a 16bit integer. The SPI buffer is only 8 bits long, so two bytes must be transferred. Each transfer triggers an interrupt, and that interrupt must copy the transferred byte from the SPI buffer to somewhere else before the next byte arrives.

Fortunately, the SPI buffer is, as it says, buffered. This means that it is not written until the last bit of the byte is received. In addition, there is a short delay between bytes.

As an example, when running the SPI bus at 200kHz, a byte is 40uS long. The delay between two bytes is 7.5uS (when output from node.js on a Raspberry PI).

Running the MCU at 20MHz we have an instruction clock of 5MHz, and each instruction takes 0.2uS. This means that with a 200kHz SPI bus and 20MHz clock, we have 237 instruction cycles to handle a received byte.

This is of course much more than we need - as long as the interrupt handler triggers immediately. But for the DCO to be as accurate as possible, we have given priority to the timer that sets the output wave period. The SPI interrupt will be blocked if a timer interrupt has been received and will not be treated until the timer interrupt handler returns. Thus, we have to make sure the time it takes to enter the timer interrupt handler, do whatever it needs to do, return from the handler and then enter the SPI (low priority) interrupt handler, takes less than 237 instructions - if not, we may be inside the timer interrupt handler when the next SPI byte arrives and we'll lose the previous byte.

This sounds all good, right? The time it takes to reset the timer is not that long. Well, we do actually have a problem. If we are to both reset the timer AND change the DAC value (that controls the current that charges the integrator capacitor making the saw wave), we run into trouble. The DAC is written to using SPI, and we have to write three bytes to set it. Unless the DAC SPI runs at several MHz, we do not have time to write to it within the 47uS we have available. In simple terms, we cannot write to the DAC inside the interrupt handler.

So what is the consequence of this? 

The only other place to write to the DAC is inside the main program loop. As we will be at an arbitrary place in the code when a timer interrupt triggers, we will get a delay from when the timer triggers to where the DAC update call is found (+ the time spent writing to the DAC).

To reduce the maximum delay, we may check if a DAC update has been requested and update the DAC at several spots in the main loop.

But how big is the consequence of delaying the DAC?

At 200kHz, updating the DAC takes approximately 135uS = 675 instruction cycles. This delay is unavoidable.

The longest single method within the main loop, recalculating the frequency, takes 723 cycles. If we break this up into 5 intervals, we'll add around 150cycles to the maximum delay, which will then be around 825 cycles or 165uS.

What does this mean?

It means that for 165uS, the DAC will output the wrong voltage, and the capacitor will charge too fast or too slow. If it charges too slow, the capacitor will be at less than 5V when the charging is reset by the period timer. If it charges too fast, it will be at more than 5V. But how much?

Let's look at the two extremes:

Going from 16.5Hz to 20kHz

Here, the DAC will have a very low charge current. The period at 20kHz is 50uS. This means that for a little more than three periods, the charging will be way too low, in fact probably so low that the wave will look completely flat. However, this is only for 3 of 20.000 cycles within a second. Question is if it is audible.

Going from 20kHz to 16.5Hz

The DAC will have a very high charge current. It charges at the same level as when the frequency is 20kHz, which means that after 50uS, the output value is 5V and after 150uS it has reached 15V (but the buffer opamp or other parts of the circuit probably saturates, keeping the maximum at around 14.3V. The cap stays at this level for one full charging cycle, around 61mS. This is not a very ideal situation.

This is of course in the extreme cases. Most often the change in pitch will be small, but a few octaves are still likely.

What can be done to remedy this?

1) Increased DAC SPI speed - pushing the speed to 2MHz will reduce the write delay to 13.5uS, with a total of 43.5uS including the delay before we reach the reset DAC code. This is if the MCU and DAC can handle the increased SPI speed

2) Increase the MCU speed from 20MHz to 32MHz - this will reduce the maximum time before the DAC write is started from 30uS to 18.75uS (as each instruction now takes 0.125uS instead of 0.2uS.

3) Check more often if we need to update the DAC, further reducing the maximum time before the DAC is written to

4) If the DAC SPI speed is sufficiently high, put the write back into the interrupt routine, removing the delay before a write altogether.

If 1) is possible, and the rest of the timer interrupt handler takes less than 47.5uS - 13.5uS = 34uS, 4) is certainly the best option.

Input SPI speed

We chose 200kHz as the SPI speed at the start of this post. At this speed, 16 bytes will take 47.5uS to transfer (inc delay between bytes), giving an effective transfer rate of 21kB/s.  The Xonik M8 voice controller runs at less than 4k updates/second, so this is sufficient for updating tree DCOs at that rate. The PIC32 has a multi-byte SPI buffer, so we may actually write all bytes to the SPI buffer and forget about them, leaving the voice card MCU to do other duties while the buffer is written (though we have to write to the separate DCOs one at the time as the chip select lines must be changed between the DCO writes.

To further improve the performance of the main MCU (and reduce the delay between when a frequency update is requested and a new frequency is visible on the output), we should calculate the maximum time spent in the period timer interrupt handler and optimize the SPI speed such that the time spent transferring a byte is just barely longer than this.

Maximum delay

The maximum delay from a byte request has been received at the main voice controller to it is visible at the DCO input may be calculated as follows:

2 x matrix calculation time
+ 2 x byte transfer time
+ 1 x transfer delay
+ 1 x time spent calculating new frequency params
+ 1 x delay writing to timer registers
+ 1 x time that must be left for an update
+ 1 x longest cycle time
+ 1 x time within period interrupt handler
+ 1 x maximum delay before DAC write starts
+ 1 x DAC write time.

2 x matrix calc time because the command may arrive just after a calc has started and be written at the end of a calc update

Update: SPI and DAC speeds

The MAX5216 SPI can run at 50Mhz. The PIC SPI runs at maximum Fosc/4, which equals 5MHz with a 20MHz crystal, 8MHz with a 32Mhz. In any case, transferring 24 bits takes approx 27 instruction cycles, so setting the DAC in the interrupt routine is well within what is feasible. Thus, the delay from period start to the DAC is set is 27 * 0.125uS = 3.4uS + any cycles between the timer reset and the call to set the DAC - 7 cycles + the time it takes to call the SPI function - an estimate may be 40 cycles = 5uS in total (at 32MHz).

This means that in the case of a too-high charging current, the cap will be charged at max for about 1/10th of the charge time at 20kHz, contributing about 0.5V too much to the end result (5.5V instead of 5V). This is probably tolerable.

Similarly, the whole interrupt function will take 33 cycles (timer) + 40 cycles (DAC). Add 10 cycles to enter and store the SPI byte and the total is 83 cycles or 10.4uS. Transmission speed will then have to be more than 1.3uS per bit, which gives a max SPI speed of 769kHz (at 32MHz)

Update 2:

The only times we should have to update the charging current will be right after we have calculated and set a new frequency. For most frequencies, this update will happen right after an SPI write (for low frequencies we will get a delay, though). If we keep the DAC update outside of the interrupt handler, we will still normally not be inside the calculation routine for a new frequency when the interrupt returns, so the delay between timer update and DAC update will be minimal. We may still encounter a large delay as it may take up to one period from frequency calculation to the frequency has been set. If SPI bytes arrive faster than this (as they most likely will if the main controller runs at 2-4kHz), we may still be inside the calculation routine.

By moving the DAC update we'll shorten the delay to 43 cycles = 5.38uS, giving us a bit time of 0.673uS and a max SPI speed of 1.49MHz (at 32MHz clock speed)

Ultimately it all comes down to what is most important - a high SPI speed to minimize the time the master spends writing or a short delay before the DAC is set to assure a high max voltage accuracy.

As mentioned previously, we may use the multi-byte SPI buffer on the PIC32 based voice controller, so the exact write speed is not all that important (as we do writes as fire-and-forget) but faster is still better - we will have to write some special code that writes to the DCOs at regular intervals through one matrix recalculation cycle as we cannot afford wasting calculation time waiting for a write to complete before filling the SPI buffer with the next DCO values (Though perhaps it would be possible to come up with a chaining scheme where six bytes are clocked through the three DCOs before they are "commited" and the values read - perhaps by a chip select line going low or similar. The PIC32 is capable of generating an interrupt once the SPI buffer is empty, so it's easy to add a single line change when transmission is complete).

onsdag 22. mars 2017

SPI from raspberry PI to PIC18F

This is mostly for my own reference later:

The following is confirmed to work:

I've connected the raspberry PI as an SPI master. Only output and clock from the PI must be connected, not the PIC18F SPI out, as the PI is not 5V tolerant.

In my special PI-to-xonik m8 voice controller cable, the following pins are used:

PIN0: Signal (Master out/slave in, PI is master)
PIN2: Clock

These must be connected to the following on the EasyPIC 3 card:
RC3: Clock
RC4: Signal (SPI in)

With this connection, the following settings work:


(incidentally the same as in my libstock example)

Raspberry PI:
let mode = 'MODE_1';     // clock idle low, clock phase active to idle.

function initSPI(){

  var spiConfig = {
    'mode': SPI.MODE[mode],   
    'chipSelect': SPI.CS['none'], 
    'maxSpeed': 200000

  spi = new SPI.Spi(


lørdag 18. mars 2017

Vocoder analysis/synthesis boards arrived

I picked up the vocoder analysis/synthesis boards yesterday. They look good as always, though I noticed some differences. Nothing to be alarmed about but I get why they are a bit cheaper than other boards:

- The silk screen is a bit misplaced on some boards
- The holes aren't always dead center on the pads
- One of the boards isn't completely flat, i.e. the fibre glass is slightly bent.

These are just very tiny deviations and well within what is acceptable, they just aren't perfect.

I'm very excited to get started on the build, to see if I've managed to get the circuit and layout right :)

mandag 27. februar 2017

ETI Vocoder voltage to current converter

The VCAs in the  ETI vocoder use a voltage to current converter that is slightly different than what I'm used to. This post tries to understand what is going on. It may be wrong, so do not use the findings without verifying them first.

The transistor in the vocoder has its base tied to ground, collector connected to the control pin of the LM13600 and the emitter to the output of an opamp (and a trim pot) through a resistor.

Unlike other converters I've seen, it does not have the transistor inside the feedback loop of the op amp.

I suspect that the converter does not rely on the \(\beta\) or Hfe of the transistor, it only has to be high enough. I believe that what is important is the relationship between \(V_b\), \(V_e\) and the output voltage of the op amp.

I've chosen the VCA in the internal excitation circuit as my reference when analysing the circuit.

R34 is a 10k resistor, you can see these in most all designs using the LM13600 OTA. It's most likely there to protect the lm13600 from self destructing - the maximum control current of an LM13600 is 2mA. See my post on the Xonik VCA for an explanation of its value.

So how do we calculate the collector current (which is what controls the OTA, Iabc)?

Here is a page that explains how a transistor may be used as a constant current source:

It says that

\(I_{load} = \frac{\beta \cdot V_e}{(\beta + 1) \cdot R_e}\)

If \(\beta\), the transistor gain, is large, \(\frac{\beta}{\beta + 1}\) is approximately 1 (and thus \(I_{load} = I_c = I_e\)). Also, \(V_e\) is always one diode drop below \(V_b\) when the transistor is on (\(V_e = V_b - 0.6V\)), which means that the formula above may be simplified to

\(I_{load} = \frac{V_b - 0.6V}{Re}\)

In our case, \(I_c = I_{load}\) and \(R_e = R32\) (=22k).

What the page above fails to mention is that the bottom of \(R_e\) must be connected to ground, or at very least that \(V_e\) is the voltage across \(R_e\).

This final detail is of importance to us, because in our case the voltage at the op amp end of \(R_e\) (R32) is what varies, not the voltage at the base. The base is stuck at 0V/GND. Thus, the voltage across the resistor is not \(V_e\), it is \(V_{out} - V_e\), where \(V_{out}\) is the output voltage of the opamp (IC8b).

We also have to take into account that the vocoder uses a PNP transistor, not an NPN as in the constant current source above. while the emitter of an NPN transistor is 0.6V below the base, the emitter of a PNP transistor is 0.6V above the base. Thus, for a PNP transistor:

\(V_e = V_b + 0.6V\)

Now we can calculate the emitter current = current through \(R_e\), which will also be approximately the collector current if \(\beta\) is large:

\(I_e = \frac{V_{out} - V_e}{R_e} = \frac{V_{out} - V_b -0.6V}{R_e} = \frac{V_{out} - 0V -0.6V}{22k}\)
\(I_e = \frac{V_{out} - 0.6V}{22k}\)

What does this mean

Well, first of all, Ie is independent of the transistor \(\beta\), which means that we can replace the BC212L transistor with something else without having to look too hard for a perfect match.

Second, we can calculate the maximum current through the base. Knowing that

\(I_e = (\beta + 1) \cdot I_b\)

we get that

\(I_b = \frac{\frac{V_{out} - 0.6V}{22k}}{\beta + 1}\)

The vocoder uses a +/-12V power supply. Thus, the maximum output value of the opamp is +/-12V (in practice it will be a bit lower than this, and the vocoder may even be designed to use an even lower control voltage, but the absolute theoretical maximum is +/-12V).

The transistor only conducts if the emitter is more positive than the base. Thus, only \(V_{out}\) values > 0.6V will turn on the transistor. As the maximum \(V_{out}\) is 12V, the maximum \(I_b\) can be found as

\(I_e = \frac{12V - 0.6V}{22k} = \frac{11.4V}{22k} = 0.52mA\)

\(I_b = \frac{0.52mA}{\beta + 1}\)

Thus, when selecting the transistor to use, we need to make sure that it has a maximum \(I_b\) higher than this when entering its \(\beta\) in the formula above.

Also, we can see that \(I_e = I_c = 0.52mA\) is well within the 2mA maximum for the LM13600.


As for the trimmer potentiometer PR1 and its associated resistor R33, I assume they add a constant current that trims the 0-point of the VCA.

The potentiometer acts as a voltage divider, so the maximum current through R33 will be:


\(\frac{12V - 0.6V}{470k} = 0.024mA\)


\(\frac{-12V -0.6V}{470k} = -0.027mA\)

A final note

I suspect that the diode D5 in the op amp feedback loop is there for this reason:

When the opamp positive input is at 0V, the opamp output must be at 0.6V (one diode drop above to keep the negative output at 0V. This means that the opamp output always stays 0.6V above its positive input, which cancels out the -0.6V from \(V_e\) in the calculations above.

The voltage to current conversion formula will then be

\(I_e = \frac{V_{out} - 0.6V}{R_e}\)
\(I_e = \frac{V_{in} + 0.6V - 0.6V}{R_e}\)
\(I_e = \frac{V_{in}}{R_e}\)

where \(V_{in}\) is the input voltage at the positive opamp input terminal, i.e. the control voltage.

I tried breadboarding the circuit to confirm my suspicions.

R31, D5 and IC8b form what is called a simple precision rectifier, see this wikipedia post: As we tap the output at the opamp output instead of at the negative input, we should see the 0.6V offset.

My measurements clearly showed that this is indeed true. The positive input and the output of IC8b follow each other closely, with a difference of 0.6V.

Input at the bottom, output on top. The difference is almost exactly 0.6V

Also, to confirm that this is indeed the precision rectifier from the wikipedia article, once the input goes below 0V, the output immediately drops to the negative rail - no surprises there. As the input is connected to the previous rectifier however, this doesn't really matter, the CV will never be negative.

The output saturates to the negative rail once the input is less than 0V

As for R31, removing it makes the circuit act like a normal buffer. Increasing the value from 3.9k to 12k has no effect at all. Replacing the diode with a wire also changes the circuit back to a buffer.

Some transistor rules:
The load should always be on the collector side
\(V_b = V_e + 0.6V\) for NPN
\(V_b = V_e -0.6V\) for PNP
The \(V_b\) to \(V_e\) relationship stays constant, the currents are what change.

If \(\beta\) is large, \(V_c = V_e\). Good designs do not rely on \(\beta\) as is varies widely.