You've already forked torvalds-GuitarPedal
mirror of
https://github.com/torvalds/GuitarPedal.git
synced 2026-09-12 01:11:56 +00:00
e39790145d
This is a slightly modified 'minimal' board with the same board outline
but an added 3.5mm DC jack.
The upside: no coupling capacitors into the codec that have distortion
at low-end frequencies due to the capacitors' voltage coefficients. The
existing 0805 4.7uF caps were large for this minimal board, and caused
the THD+N to go to roughly -65dB for a low-B bass signal at a reasonable
signal level of 0.1Vrms. That's not horrible, but it's not optimal.
The 10Hz corner also caused issues for using the pedal as a measurement
instrument, since it introduced a consistent measurement error that was
initially incorrectly attributed to the pedal under test.
The other upside is simply the existence of the headphone jack. That
user-visible addition is likely a lot more noticeable than the
low-frequency THD+N improvement this should bring or the improvement in
low-end frequency response.
Downside: the TAC212 with a better noise floor is out of stock, and so I
am back to the slightly lower dynamic range of the TAC5112 - but with
the new fixed footprint with proper paste and thermal vias. The thermal
pad is likely to actually come into play now that the codec is used as a
headphone amplifier too.
The lower dynamic range is unlikely to be noticeable - it wasn't on the
original mono boards (the added noise was probably entirely due to the
negative inputs having been left floating on that board).
And I'll need to route i2c again, and it's an entirely new untested
configuration. I've added a trace to route one of the TAC5112 GPIOs
just in case it comes in useful - possibly as an ASI error reporting
interrupt line.
The default codec routing for that new pin being routed is as an
interrupt output: driven low with a weak pull-up. It's routed to GPIO15
on the rp2354, which hardware in turn defaults to a weak pull-down,
disconnected from any logic.
So without any firmware, this ends up being a few microamps of current
on that trace due to the pull-up and pull-down. Not really noticeable,
but the proper firmware fix is to either treat it as an interrupt line
on the MCU and doing a pull-up there too, or decide that the trace isn't
useful and just float it on either or both ends.
Harmless either way.
Minor incidental changes this brings: since the MICBIAS now needs to be
programmed to 1/2 VREF - which we can do over i2c - the input bias is
once again roughly in the middle of the 3.3V analog rail. So this makes
the op-amp share the same +3.3VA rail that the TC5212 uses, instead of
having a separate analog +5V rail.
It's worth noting that with MICBIAS being at 1.375 V (default VREF being
2.75V), and that being used as the bias voltage for the initial high-Z
opamp buffering, a 1 Vrms signal would swing below the rails. That's
not great. It's made worse by the fact that the OPA2323 is rail-to-rail
on input, but not on output - on output it's _close_ and TI calls it
rail-to-rail, but documents that i's really within 30mV or so.
There is a fix to that, which I already used in the original TAC5112
board: set MICBIAS_LDO_GAIN, which adds a gain factor of 1.096 and thus
raises MICBIAS from 1.375V to 1.5V. That isn't actually stated outright
in the datasheets, only implied by the register programming docs, but on
the old TAC5112 board it was a simple oneliner:
- { 0x4d, 0b00000000 }, // VREF and MICBIAS set to 2.75V for 1V_{rms} single-ended input
+ { 0x4d, 0b00010100 }, // VREF set to 2.75V and MICBIAS set to VREF/2 with LDO GAIN 1.096 for 1V_{rms} single-ended input
(That old board went from using a 2.75V MICBIAS and a 5V op-amp rails to
that 1.5V MICBIAS and 3.3V rails on the OPA365)
That LDO GAIN bit isn't mentioned anywhere else in the datasheet, but it
worked exactly as expected. That said: that was with the old
single-ended input where the thing was only ever used for that initial
opamp input biasing.
Now, in this board, the inputs are DC-coupled, and that MICBIAS will
also be used for IN1M and IN2M to make the signal basically
pseudo-differential. So the configuration is very different and
entirely untested.
This also uses the "V6" version of the WS2812B-4020 with the new
footprint due to better availability (and maybe it doesn't have the
slight "lean backwards" issue the other part had a tendency for)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>