Sound Processing Shield for Arduino

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.

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.

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.

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.

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.

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.

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).

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.)

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.

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).