pcm5102a
output stage:
-
a simple RC filter (as per PCM5102a datasheet), followed by a standard non-inverting op amp configuration and a 1k output resistor. I’ve tried with both TL072s and fancier op amps, i’d say the difference is mainly psychological (though YMMV).
-
either way, the DAC output is 2.1 V_rms (~6VPP); so 1.7x gain (V_out = V_in * (1 + R_fb/R_gr)) should get you into 10VPP territory (the values indicated on the pcb should be plenty). The outputs are DC coupled. (conveniently, the DAC puts out a ground-centred signal).
CV inputs 1-6, with offset:
- basic inverting op-amp configuration, followed by series resistor + diode clamps (bat54s). Specifically, incoming CVs are mixed with the pots (referenced to 3v) and a fixed negative voltage (-5V) == low parts count but the results need to be inverted in the software. (the external resp. C programme is taking care of that).
-
the 1k series resistor can/could be much lower, but it'll do here. if you're not a fan of sot-23, you'd probably get away without the bat54s -- the MCP3208 has internal clamping diodes, so it will be ok. that said, the bat54s also serve the purpose of isolating the various channels from one another (when exceeding the range, ie when < 0V or > 3V3). so, in fact, you want them to be there. the ADC is a SPI device, and it's wired to the SPI port (chip select = CE1).
-
in an ideal world, one probably would have used a mcu for sampling the CVs. apart from the added complexity (not that much, admittedly), the pay-off (in terms of bandwidth) likely would have been nil though, as getting the data into pd (or comparable non-custom software) is limited by a number of factors. as it stands, regarding puredata the limit for both the SPI external and C programme is (mainly) the pd 'control rate' (1ms max)
CV inputs 7-8:
- same thing, but without the pot/manual offset. (the fixed negative offset is such that the inputs are bipolar).
digital inputs 1-4:
-
wired as transistor switches, directly to the respective GPIO pins: collector tied to 3V3 via a series resistor; emitter to ground; the trigger signals go into the base via a 100k series resistor and 33k to ground. (pcb says diode to ground (unlabelled) – ignore this. (also see pictures here)).
-
at the software end of things, these inputs can be treated as interrupts (see commented out sections in ADC2FUDI.c) -- or be polled, as is done with the pd externals.
switches:
- simply wired to the GPIO. they need the internal pull-ups to be activated. the pd externals take care of that. if you don't use them, you'll need to pull them up by some other means, for instance a script such as this; it will typically be run at start-up.
digital outputs 1-2:
- standard non-inverting op amp configuration (note the LM358 – you can’t use a TL072 here). Following the resistor values as indicated on the pcb will yield 3x gain, or 10v pulses.
power:
-
regarding power, there's basically two options: supply the whole thing from your eurorack psu or supply the raspberry with 5V externally via the micro usb power inlet. the former will be ok when using say a model A+ (we're talking < 150ma in my experience) or model zero; those models will typically be preferred over pi 2. similar considerations apply if you intend to use, say, a usb WiFi dongle in regular use (ie, other than for getting patches or files onto or off the device).
-
to choose between the two options, there's a jumper ('5V') right next to the 2x20 header -- you want to connect this in order to supply everything, including the raspberry pi, from the psu. disconnect it, if you want to power the raspberry from usb or external 5v DC supply. using a 7805 will do to power a model A+, B+ or zero; more efficient (and more $) is to use the RECOM equivalent. the 0.5A version probably is sufficient (ie R-785.0-0.5). in terms of power draw, pi 2 is more demanding, to be on the safe side, better to use R-785.0-1.0 (viz, the 1.0A version). the codec itself is powered from the ADP150 'ultralow noise' linear regulator (as is the ADC).