Skip to content
mxmxmx edited this page Feb 22, 2018 · 31 revisions

hardware basics

First: a disclaimer: I drew the the pcb by hand (which is to say, in pcb view), so i don’t have a proper schematic. (Sorry, i know it’s helpful having one). it's simple though.

=====================

and here’s the basics, anyway:

  • as noted, pin usage is identical to the pjrc "audio adapter"; except pin 15 (VOL), which isn't used here; pins 18, 19 (i2c) aren't needed, owing to the different codec used (pcm5102a). (to be be precise, those pins are used, but for the (i2c) display). MCLK (11) isn't used either, as pcm5102a has its own PLL. the audio API defaults to 44.1kHz. in theory (for other purposes than wav playing), higher sample rates can be achieved by modifying the i2s code. chances are, that'll require further modifications downstream (the API is coded around 44.1kHz); also see 9.3.5.3 in the pcm5102a data sheet (Clock Slave Mode with BCK PLL to Generate Internal Clocks (3-Wire PCM))

  • being a module, this thing also has the following :

- 4x CV in    < >   pins A1,A2,A3,A6
- 2x clk in   < >   pins 5,8
- 3x switches < >   pins 0,13,21
- 1x encoders < >   pins 1,2

- OLED SH1106 < >   pins 18,19  

details:

CV inputs:

  • standard inverting op amp configuration / 100k input impedance / 0.33x gain; this is the MCP6004, running off the 3v3_A rail. the LM4040-10 provides for negative offset via 200k (-> 1.65V); in the code, the incoming ADC samples thus have to be inverted. the 100R series resistor is for stability. (note audio is processed in blocks of 128 samples (= 2.9ms @ 44.1k), so typically there's no point sampling the ADC crazy fast). (it also means the caps in feedback path could be larger, like 10n. it's not particularly critical though, and 1n is what i had plenty of ..)

digital inputs:

  • wired as transistor switches, directly to the respective GPIO pins: collector tied to 3V3 via the internal pull up resistors; emitter to ground; the trigger signals go into the base via a 100k series resistor and 33k to ground. at the software end of things, these inputs can be/are treated as interrupts; they are normally high, and low if/when the transistor saturates. any signal > 3V-12V should do:

audio out:

  • a simple RC filter (as per PCM5102a datasheet), followed by an output amp (standard non-inverting) and a 1k series output resistor. I’ve tried with both TL072s and fancier audio op amps, i’d say the difference is mainly psychological, though i tend to go for the latter (and YMMV in any case). either way, the DAC output is 2.1 V_rms (~6VPP); so 1.7x gain (V_out = V_in * (1 + R_fb/R_gr)) will get you into 10VPP territory. as per BOM, R_fb = 33k, R_gr = 22k, which is plenty; the outputs are DC coupled. (conveniently, the DAC puts out a ground-centred signal).

power:

  • LM1117-5 goes into teensy VIN and supplies both the ADP150 (3v3_A) and LM1117-3 (3v3_D) regulators; the latter supplies the OLED and microSD (the onboard 3v3 regulator might have been used, but it's rated only for 100ma (that's re teensy 3.1), which seemed a little non-conservative; peak-current draw with SD can be + 100ma, They say); the ADP150 supplies the codec (AVDD). the two SM5817 diodes provide for basic / reverse polarity protection.

switches + encoders:

  • directly wired to the respective GPIO; the internal pull-ups are used (must be used).

OLED:

  • an i2c OLED was used to relax demands made on the SPI port (which will be fairly busy with SD & SPI flash) as well as to simplify the design (mk1 used an atmega328 as co-processor, which is convenient to have, but put off people and made things needlessly complex; perhaps). at any rate, the two 4k7 pull-ups are for SDA and SCL; on the software side, driving the OLED requires/uses two libraries: i2c_t3 and u8glib; i2c is run at 3000kHz (requires: F_CPU = 120MHz; it's 2400kHz @ 96MHz), which gives usable results.