Close
0%
0%

Sound Processing Shield for Arduino

Add reverb and other effects to a mike input, and have it ready on a speaker output

Public Chat
Similar projects worth following
This Arduino Shield project takes sound processing on the Spin Semiconductor FV-1 and applies it to a microphone input, then sends it to a speaker output. While the effects (including a separate volume control) are controlled by I2C, the audio signal itself never leaves the board.

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:

  • Wearable/portable voice changer
  • Musical instrument effects unit
  • Portable personal stereo

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 connect it; those GPIO pins will then be left unconnected.

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. Other than those two, plus one to control whether the EEPROM is Read-Only or Write-Capable, all the MAX11312's ports connect to the FV-1.

A Microchip MCP4652 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, there's also a Qwiic connector... 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 1MΩ 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...

Read more »

Sound Processing Shield 1.fzz

Fritzing file for the project. Anyone familiar with the chips and other components used here is invited to make useful comments.

- 174.86 kB - 08/26/2020 at 14:37

Download

  • 1 × PCB from the Fritzing file provided
  • 1 × Spin Semiconductor FV-1
  • 1 × 2.2KΩ resistor R19
  • 2 × 1uF capacitor C3, C10
  • 1 × ON Semiconductor NCS2211

View all 38 components

  • Rerouting

    bobgreenwade09/23/2020 at 15:09 0 comments

    I've been making minor, unlogged updates to the Fritzing file all along, but here's a big change: I moved the EEPROM Read-Write function from IO7 (on the MAX11312) to IO1. This means less crossing of traces, shorter leads, and fewer vias. It also means a few changes to the programming notes, which is why I'm logging it.

    Those minor, unlogged updates will probably continue, for much the same reasons (as well as to maximize ground plating), at least until I send off for a prototype.

  • Hopefully... though still not quite sure.

    bobgreenwade09/16/2020 at 14:43 0 comments

    I don't think just a bypass resistor is going to be enough to keep the piezo mic from sounding tinny, so I hunted down a schematic for a better circuit and plugged that in. The person who made it meant it for a guitar pickup at 9V, but I think it should work for a throat mike at 3.3V as well. I don't think I'll actually know for sure how well it works until I have the board in hand, with components.

    I think this (once I've double-checked the routing) probably will be the version of the board that I have printed (sans components) to check header placement. I'm particularly uncertain about the SPI header (at the right-hand end), though the standard Arduino headers may be a tiny bit off as well.

  • Finalizing, Part 3

    bobgreenwade09/11/2020 at 23:47 0 comments

    I'm still trying to get to a secure feeling about the use of a piezoelectric microphone, in the form of a throat mike. I've seen several takes on electronics to adjust the feed, ranging from complex circuitry that would require another breakout board to a single resistor. I've decided to go with the latter (at 1MΩ) for now, though I'll be asking a few more people about it; I suspect that the final answer will be somewhere in between.

    The problem I have with the more complex schematics I've seen is that they're set up for higher voltages (9V and up); assume positive and negative leads as well as Ground; or both. All I have to work with here is 3.3V, and maybe 5V, as well as Ground. Probably the layouts with just higher voltages could translate easily enough to 3.3V; the ones that ask for negative-voltage power separate from Ground, not so much.

    Whatever the end result, it'll be user-selectable with a solder jumper. (Yeah, if I have my way, half the underside would be covered in solder jumpers. I like to maximize options.)

    Also, speaking of Ground: in working on a good layout for including the ground plane, I've found a few redundant and/or excessive traces for the ground in the circuitry. Fixing those has made a few other traces easier to work with.

  • Finalizing, Part 2

    bobgreenwade09/07/2020 at 16:52 0 comments

    I've now checked the values and placement of all the passive components, and moved some of the traces around to make maximum use of the ground fills.

    I'm waiting on that last step because I'm still contemplating moving some components. For one thing, I could rotate the FV-1 90 degrees clockwise to make room for mounting holes for the BLE SPI Friend. For another, I might be able to organize the traces around the MAX11312 if I rotate it 45 degrees counterclockwise.

    I'll have until around October 3 to decide whether to do those things (and to do them if I decide to), as that's the day I plan to order the prototype.

  • Finalizing, Part 1

    bobgreenwade09/04/2020 at 16:08 0 comments

    I don't think there's anything more I can add, so I've started double-checking the connections and passive component values to make sure everything's right. It's good that I did, too; there were a few misplaced connections, and I'd especially screwed things up around the MAX4468. While I'm at it, I'm also making one last optimization run around the positions of the chips.

    I still need to check everything around the FV-1 and (especially) the MAX11312; once that's done I can generate the ground plating and have this ready for prototyping next month.

  • Too hot?

    bobgreenwade09/01/2020 at 14:19 0 comments

    I don't really think that it'll be a problem, but just to be safe I've added a temperature sensor to the space next to the FV-1 where the BLE SPI Friend is to be mounted. The MAX11312 has an internal temperature sensor and leads for two more (without even using any of the data ports!), and while they're meant to issue an instant shutdown of the chip itself, a bit of programming should make it possible to simply issue a warning to the user.

    Note: It'll be a wee while before I update the Programming instruction section to reflect this.

  • Whoops! SPI, not UART

    bobgreenwade08/31/2020 at 15:05 0 comments

    I found a bunch of compatibility issues with the BLE UART Friend that I'd installed as an option for this board. A bit of research showed me that the BLE SPI Friend is a much better choice. I've edited the Fritzing file to reflect that correction (the one tiny downside being that I no longer can include mounting holes; I'm not sure how significant those would be anyway).

  • Simpler EEPROM channeling, plus a BLE option

    bobgreenwade08/29/2020 at 15:24 0 comments

    To my near-complete lack of surprise, I've made a couple of significant changes to the design.

    For one thing, I realized that programming the EEPROM would only take a DPDT switch (the switch and the Write Protect tab can be controlled with the same signal), so I replaced the Nexperia 74CBTLV3257 with an ON Semiconductor FSA2211. As a bonus, the new chip is also much smaller.

    Then I also realized that there are too few Arduino processor boards with a Bluetooth option (see below). Most of the projects that I want to use this for involve controlling the FV-1's settings via Bluetooth using a phone app, and plugging in a Bluetooth Shield seems like just adding an extra 3/8" of thickness unnecessarily. On the other hand, not every project would call for such an app -- not enough to warrant the design time and expense of including it on the board.

    Fortunately, Adafruit offers (among other things) the BLE UART Friend (Adafruit 2479), which allows me to make including the Bluetooth capability optional by putting a row for a short-pin header. I had to juggle the traces from that header to the Arduino pins a bit to allow the sample code that comes with the breakout to work while also allowing it to be mounted within the Shield's boundaries, but with a bit of component-shifting there's room for both that and even including a couple of mounting holes. And if I have a project that doesn't call for BLE or if I decide to use a processor board that already has it, not installing the Friend frees up those pins for other Shields if they're needed.

    Now I have to just hope that the Shield's components aren't too tall to install the Friend. (Looking at the data sheets, I don't think they are; the crystal is the most likely offender, and I'm pretty sure it's fine.)

    An aside...

    I favor Adafruit's METRO M0 Express in general, but it surprises me a little that the company doesn't offer a version with BLE, especially given that they have it on multiple types of Feather boards. I have been able to find BLE-capable processor boards such as DFRobot's Bluno and Bluno M3, as well as models from HiLetgo, Emakefun, Diymore, and others that are listed on Amazon. (Personally, if I go this route, I'll probably look at the Bluno M3 first.)

  • Further Updating

    bobgreenwade08/26/2020 at 14:51 0 comments

    I've reworked the board for a bit more copper efficiency, and double-checked some suspicious-looking component values.

    Also, this will be "version 1" of the Shield; "version 2" will replace the 3.5mm TRRS plug and right-angle headers with a pair of 2.5mm mono audio plugs, for those cases where the mike and speaker go to separate places outside the enclosure for the Arduino boards.

    There are a few things I may yet change, such as rotating the 24LC32 counterclockwise; rewiring the audio plug to make it at least nominally compatible with one of the common TRRS standards; or possibly migrating the MAX11312, its surrounding capacitors, and some of the components to "south" in a "northward" direction. Other than that, a tiny bit of trace-juggling, and anything based on input from you, Dear Readers, this is pretty close to ready.

    If I upload another update to the layout, it'll probably be the last one... but I've said that before, so no promises.

  • Correcting the Layout for the BOM

    bobgreenwade08/22/2020 at 15:49 0 comments

    In building my BOM (I'll add a link to Octopart and enter the parts here at some later time), I found that [1] I was unable to find a plug whose footprint matched the one I'd placed, and [2] I'd been using altogether the wrong kind of plug for my Qwiic connectors anywhere I'd been using them. Those problems are now corrected, at least here (as of this writing I haven't even looked at my other designs).

    I've also managed to cram the components together enough that I could turn the MIC and SPKR headers around, leaving plenty of open space.

    There are probably a few other improvements I can make here, mostly in the interest of shortening traces, but on the whole I think I'm close to ready to start making the Gerber and Centroid files, toward having a prototype made.

    With any luck, I'll be able to order those prototypes around the start of October.

    An interesting note about the BOM: the Spin Semiconductor FV-1, which is the heart of the project, accounts for more than half the cost of components ($14.54 out of $28.77 as of this writing).

View all 15 project logs

  • 1
    Programming

    This is where I'll eventually include Python code for setting up and controlling this Shield. Until that's ready (or close to it), this will be a placeholder for notes on that.

    First, the I2C addresses will need to be declared. The defaults:

    MAX11312 = 0111000
    MCP4652  = 0101000
    EEPROM   = 1010000

    The FV-1 can only address the EEPROM at 1010000, so that one is immutable. The other two can change, depending on how the jumpers are connected. (One can still have two to four of these Shields and program the EEPROMs separately, since their Write Protect functions are controlled through the MAX11312. Just be sure that no more than one of them is Write-Capable at a time!)

    Then the MAX11312 will need instructions on how to handle its I/O ports. (For purposes of these "placeholder notes," I'm using the variable names from the chip's data sheet.)

    DACCTL       : 1 [DACs in immediate update mode]
    DACREF       : 0 [DAC uses external reference]
    
    TMPCTL       : 3 [int & 1st ext temperature monitors enabled]
    THSHDN       : 0 [thermal shutdown function disabled]
    TMPINTMONCFG : 2 [16 samples to average for current temp]
    TMPINTHI     : 320 [max temp for int temp is 100C]
    TMPINTLO     : 0 [min temp for int temp is 0C]
    TMPEXT1HI    : 228 [max temp for ext temp 1 is 67.5C]
    TMPEXT1LO    : 20 [min temp for ext temp 1 is 2.5C]
    
    FUNCPRM_5    : 800
    FUNCPRM_6    : 800
    FUNCPRM_7    : 800 [all DACs set to -5 to +5V]
    
    FUNCID_0     : 3 [GPO] [Mike Preamp Shutdown]
    FUNCID_1     : 3 [GPO] [EEPROM Read/Write]
    FUNCID_2     : 3 [GPO]
    FUNCID_3     : 3 [GPO]
    FUNCID_4     : 3 [GPO] [These 3 are FV-1 Program Select]
    FUNCID_5     : 5 [DAC]
    FUNCID_6     : 5 [DAC]
    FUNCID_7     : 5 [DAC] [These 3 control the FV-1 Pot inputs]
    FUNCID_8     : 3 [GPO] [FV-1 Int/Ext program select]
    FUNCID_9     : 1 [GPI] [FV-1 "Clip" signal]
    FUNCID_10    : 3 [GPO] [BLE Friend DFU]
    FUNCID_11    : [Not currently used]
    

    The temperature monitors are normally used to reset the MAX11312 itself if it overheats. However, this can screw up the settings, so for this instance it will instead generate an interrupt sequence that shuts down the mike preamp and/or sends an alert to the user interface. The internal one monitors the MAX11312; the external one monitors the space next to the FV-1, where it's covered by the BLE SPI Friend (if that breakout is attached).

    A function will be needed to translate program selection from a single digit (1-8 on the user's screen) into binary on pins 2, 3, and 4. A related (either inclusive or separate) function can select a larger number (1-16) into the same binary with an additional digit on pin 8.

    I also hope to include something that will store and recall "presets," setting not only the program as above (pins 2, 3, 4, and 8) but also the levels of the pots (pins 5, 6, and 7).

View all instructions

Enjoy this project?

Share

Discussions

bobgreenwade wrote 08/29/2020 at 16:36 point

At this time there are still two ports available on the MAX11312, and space for a few more ICs if I want to add them, so if anyone has any suggestions for functions or capabilities to add to this Shield, by all means feel free to post them.

  Are you sure? yes | no

bobgreenwade wrote 09/05/2020 at 14:11 point

Correction: one available port on the MAX11312.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates