Overload indicator

As the moog filter overloads nicely by feeding back the output, we need a way to know when the filter starts overloading.

We do know how high the maximum input signal may be, so overloading happens when the input passes this threshold.

The following circuit lights up the led whenever the input is too high. In the analog domain, the brightness of the led corresponds to how much of the signal is too high, as it will rapidly turn on and off.

If we choose to remove the led and connect the output to an MCU instead, a positive (5v) signal means overloading and 0 means not overloading - for a single signal cycle.

Doing this digitally lets us also filter the signal - we may trigger a "overloading" flag whenever the input is high, set a timer to clear the flag, and reset the timer whenever a new high input is received. That way we get a continous overload if the time between a low and a high overload input is short enough.

Some MCUs even have built in comparators, which lets us supply a reference voltage on one pin and the input on the other, meaning we do not need the pullup resistor or LM311.

In the XM8 I intend to have replaceable filters. For our filter, the reference voltage should be generated by the filter circuit using a trimpot or resistor divider, and the signal to measure should be tapped after the input mixer.

By doing it this way we don't need a separate comparator for each filter.

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 http://xonik.no/theory/vco/reference_current.html).

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.