Intro

This Shield brings sound in through a Maxim MAX4468 microphone pre-amp, sends it straight to a Spin Semiconductor FV-1, and then out through an ON Semiconductor NCS2211 speaker amplifier.

Purpose

There are several applications one could use this Shield for in an Arduino project:

I'm sure others can come up with other ideas, including as just one element in a much larger and more complex project. (The wearable voice changer is my pet project, but I also plan to make this Shield as broadly applicable as I can.)

Details

The FV-1's settings are controlled via a Maxim MAX11312 I2C controller. That same controller also operates an ON Semiconductor FSA2211 data switch, which serves as an electronic DPDT switch. The same signal that operates the switch changes the 24LC32 EEPROM chip from its normal connection to the FV-1, storing "external" programs as a Read-only chip, to a Write-capable chip connected directly to the I2C bus so those external programs can be loaded onto it. The switch connects the EEPROM to the FV-1 when in Read-Only mode, or to the main I2C bus when in Write-Capable mode.

There's also an option for adding a Bluetooth Low Energy (BLE) capability to a project, via Adafruit's BLE SPI Friend. The header for this connects the Friend's pins to the GPIO pins used in the breakout's provided sample code (as shown in the Wiring section of its tutorial; these are 4, 7, 8, 11, 12, and 13). If you don't want to use the Friend for any reason, just don't include it; those GPIO pins will then be left open, so other Shields can use them.

Besides the GPIO pins mentioned in the preceding paragraph, the only pins used by this Shield are those that can be easily shared with other Shields: Power (both 3.3V and 5V), Ground, ARef (analog reference), and the I2C pins.

One of the MAX11312's ports controls the MAX4468's Shutdown function; another is connected to the Friend's DFU (Device Firmware Update) pin; another controls whether the EEPROM is Read-Only or Write-Capable. All the MAX11312's other ports connect to the FV-1 (including one to read the CLIP function and another intercepting the mike input).

A Microchip MCP4652-503 dual 50kΩ digital rheostat -- with a separate I2C address -- controls the mike and speaker volume.

There are three ways that the audio signal can leave the board. The "normal" way is through a 3.5mm TRRS audio jack (the four leads carrying IN+, OUT-, OUT+, and IN- respectively). In case the user is building something with the mike and speaker in the same enclosure as the Shield, there's also a pair of two-lead right-angle headers to connect them.

Finally, should the user want to process a signal through more than one FV-1, a pair of connectors allow the user to send the output of one directly to the input of the next. While the MAX11312 is capable of up to eight I2C addresses, the selection on this board is limited to four; it's highly unlikely anyone will want more than two.

(For those who might want to connect the mike and speaker through separate mono audio jacks or bare-wire connectors, a separate version of this will feature those options in place of the TRRS jack and right-angle headers. That's why the board is labeled Sound Processing Shield 1; the other one will be Sound Processing Shield 2. That will be the only difference, so all sketches should work equally well with both.)

As a bonus, the board also has three Qwiic connectors... because, well, you can never have too many Qwiic connectors.

Usage

This Shield is designed to be usable with either an electret or piezoelectric microphone. By default, it's set up for an electret; to use it with a piezo (without it sounding tinny), just switch the "Mic Type" solder jumper on the underside from "E" to "P."

The 10kΩ Pull-Up resistors are connected by default. If you have other I2C boards with their own Pull-Up resistors, you may want to disconnect these by opening the solder jumpers next to them.

Two other sets of solder jumpers control the I2C addresses for the MAX11312 and MCP4652; these will be discussed in more detail under Programming.

For most purposes, you'll have to devise your mike/speaker combo yourself; few, if any, devices exist that would be compatible with this TRRS plug configuration (though some may be close enough to use). This is also true if you use one of the other methods of audio input/output.

The BLE SPI Friend connection is here so the user can control this Shield's functions via Bluetooth. This offers a solution for projects where the project's dimensions need to be kept small; it saves using the Bluetooth Shield or some other method, by sandwiching the BLE between this Shield and the one above. Of course, there are other possibilities as well: base Arduino-compatible boards are available with Bluetooth built in, the user might not want to use Bluetooth at all, the BLE SPI Friend may cause other problems (such as conflicting pin I/O or raising the temperature near the FV-1), and so forth, so this is optional. (It's actually more likely that either physical switches or a touchscreen will be preferred for control.)

The FV-1's clipping function can tell the user when the mike volume is so high that it causes the waveform to clip. In most cases this can be fixed by turning the mike volume down, and the speaker volume up. However, there may be cases where this contributes to the desired effect, in which case the user would turn the mike volume up and the speaker volume down.

Links

Here are a few links that might be handy.

Data Sheets for the ICs

Spin Semiconductor FV-1

Maxim Integrated MAX11312

Maxim Integrated MAX4468

ON Semiconductor FSA2211

ON Semiconductor NCS2211

Microchip Technology 24LC32A (the EEPROM on the Octopart BOM)

Microchip Technology MCP4652

Other Links

Make this DIY Contact MIC Circuit (the Piezo mic circuitry is based on this)

Bill of Materials at Octoport (properly ordered, and more reliably up-to-date)

History

This is a replacement project for two FeatherWing projects I'd initiated, the SoundWing and the EchoWing. These two projects processed sound through the I2C bus, which was deemed impractical, especially since each would pass the sound through that bus twice -- and, just as some projects might call for two Sound Processing Shields, their Feather counterparts would call for two EchoWings, boosting the total to 6 passes through I2C.

While I2S was recommended to me, I had tremendous difficulty implementing that on the Feather ecosystem, as well as figuring out how to send the sound through an I2S bus both directions and multiple times (I'm not sure it's even possible). Therefore, I dropped the idea of sending the audio through the processor at all.

It might be possible to devise a system on those FeatherWings that bypass the processor, in the same way that this project has a way of sending audio directly between boards; that's why I haven't deleted those projects. However, I thought it might be best, at least in the short term, to try a standard Arduino Shield.

Notes

Some things that you should know, or that I should know that you might:

Special Thanks

I want to give a special shout-out to the folks at Spin Semiconductor and Maxim Integrated Products for their help in making sure these components work the way I need for them to. Their feedback and advice saved me a lot of work and grief. Thanks, people!