These speakers made a guest appearance at the DIYDC 2009 hosted by Dennis Murphy. They were partially functional but needed a lot more software to properly control the DSP and were not auditioned. The DSP used the biquad arrays that are embedded in the DDX8001 chip used in the XBox Spherex amp, controlled by a Motorola microcontroller programmed in assembler language. That’s a challenging development environment. And while the DDX8001 was an astonishing powerful chip for its time, it had some limitations with its 24-bit architecture, especially for implementing low frequency filters. Given the amount of effort it would take to finish the assembly code and the limitations of the DDX8001, a decision was made to “mothball” the speakers until a better amp/DSP solution was available. These speakers have been stashed in a closet for the last 14 years, but now it’s time for them to re-emerge and show their stuff. Also, I knew it was past time to get back to them when my wife recently asked: “if you ever die, what should I do with those things?” *sigh*.
The Marthas are unique in several ways. First, they are intended to be software selectable from 3-way to 5-way, using programmable crossovers. Second, they are “ring arrays”, with 8 drivers arranged in a octagonal ring on each tier. That configuration was intended to provide a non-directional radiation pattern. The top tier uses an array of 8mm headphone drivers to maintain this non-directional radiation even to the highest frequencies. Third, the drivers in the front and back are wired such that the phase can be reversed, making the radiation pattern dipolar rather than point source. The original design included relay boards to switch between these modes, but going forward both front and back drivers will use dedicated amplifiers with phase switching done in the DSP. And, finally, 3 of the tiers use drivers with transparent cones or translucent enclosures. This is a bit of silliness to show off the 160W of LED’s inside the rings, powered by a 3-channel color organ. In fact, the name “Marthas” comes from the translucent Martha Stewart cutting boards that were used to make the upper midrange array (R.I.P. Kmart and their bluelight specials).
So, what is the point of resurrecting these speakers? The answer is simple: there is a lot to learn from these. The ring array concept has a lot of potential for making a truly omnidirectional speaker. And being able to switch to a dipole radiation pattern using the same drivers should be an interesting experiment that could yield some valuable insights on how to build our next speakers. Also, being able to easily switch from low order crossover filters to steep ones in a 5-way design is something that needs to be explored. The ability to switch between 3-way to 4-way to 5-way is yet another area to explore. And having electronic delay on each ring to “steer” the vertical radiation pattern could yield even more valuable insights into loudspeaker design. I envision a lot of knowledge can be derived from experimenting with the Marthas, and that alone is a good reason to revive this project.
The Drivers and Cabinets
The 5 rings were intended to follow the slope of the bedroom walls in our cabin in Western Maryland, which are pitched at 45 degrees. That’s one reason for the odd appearance of this system. The other reason, of course, is that these speakers are multi-way “ring arrays,” and the tiered structure allows us to avoid comb filtering without using a large number of drivers. The electronic delay applied to each tier will compensate for that 45-degree angle and result in the drivers appearing to be an “acoustical cylinder.”
All of the tiers have 8 drivers arranged in an octagon, except the bottom tier, which has 4 8″ long-throw drivers. The bottom tier started out a good bit larger with 8 drivers, also, but when my wife asked if I was building a playhouse for the grandkids, I knew I needed to scale back the design (love that snarcasm). The “subwoofer” drivers in the bottom tier are the long throw MCM 55-2421.
The woofer tier uses 8 SEAS 5″ drivers with TPX clear plastic cones. There are also 16 1W Blue LED’s in this tier with over 600 lumens of output buried behind the drivers, mounted on aluminum angle brackets for heatsinking. The octagonal panels are 3/4″ walnut, with the grain matching from panel to panel. The top and bottom panels use high density polyethylene (HDPE) to transmit even more light. HDPE has some nice properties, but rigidity is not one of them, so the top and bottom plates got reinforced with HDPE rods, with everything held together with nylon screws.
The midrange tier uses 8 HiVi U2S drivers that have transparent surrounds to allow the 8 green 1W LED’s to shine through. Those green rings around the aluminum drivers impart an “eerie” look that works well with the 1/2″ walnut panels.
The tweeter array has red LED’s, with the light coming through the HDPE cutting board material that is on the top and bottom of the array. The panels are made from 3/8″ cocobolo wood to provide plenty of strength. The tweeters are the Dayton ND16’s that have been removed from their plastic cases to ensure very tight spacing and they are glued directly to the frame.
The top tier is the supertweeter, and the original design called for a cylindrical Heil as described elsewhere on these pages. However, an alternate design using 8 10mm Sony earphone drivers was used instead. It was impossible to machine a wood frame for this tier without a CNC machine, so it was built using acrylic panels that were solvent-bonded to each other. This array was measured and shown to have useful output down to 5KHz. The spacing of the drivers is very tight to minimize any comb filter effects. There wasn’t enough space available inside this structure to incorporate LED’s.
Martha Redesign, Part 1: DSP/Amp
The original design used a highly modified Spherex 5.1 XBox amp, which is built around the Apogee/ST DDX8001 amplifier chip. Although there are plenty of digital biquads available in the DDX8001, the amplifier lacks some features of a modern DSP, such as delay and overall EQ that can be applied to all channels. I debated whether to simply update the microprocessor to a more modern Wi-Fi-enabled device but decided instead to switch to the ADAU1466 DSP paired with SSM3582 amplifiers.
Fortunately, there is an 8-channel SSM3582 board with an ADAU1452 DSP sold on AliExpress that can be adapted for this application, so I didn’t need to design any new circuitry to update these speakers.
The SSM3582 amplifier board has 8 channels, which we will use to power the top 4 tiers of the Marthas. Four of those channels will power the front drivers and the other four will be for the rear. However, we need two more amplifiers for the “sub” channels. Unfortunately, the serial output ports do not use TDM in these boards, so there are no other outputs from the DSP except for SPDIF. The boards shown on the AliExpress web site have the SPDIF output connector, but what they actually ship has an analog input in place of the SPDIF output (arghh). But with a little bit of PCB surgery, it is possible to attach a wire to a tiny via that has the SPDIF signal. We will send that wire to an SPDIF-to-analog module and then to a separate stereo amplifier to have the 10 amplifier channels we need for each Martha. There are a number of amps available on AliExpress that are suitable for the “sub” ring. The final selection for the sub amps are some low-cost TPA3255 amps, using 36V switching power supplies. Like the other tiers, we need both front and rear amps for the 8″ subs, so the stereo TPA3255 for each side works well.
The final cost for 10 channels of amplification and DSP and power supplies is around $250–that’s nice! Add in the Wiim mini as the primary source, and we’ll have the Marthas back online without costing too much at all.
Part 2: The Amp Board
There is a 6″ by 9.5″ cutout on the back of the subwoofer tier for the Spherex amp that I wanted to re-use. However, the new amps, Wiim mini, ESP32, and SPDIF-to-analog board barely fit in this opening, and I still needed to mount two power supplies for the amp boards. So, the only workable solution was to take advantage of the depth of this opening by mounting the circuitry on panels that extend into the speaker cabinet. I don’t have a lot of metal-working tools outside of a bandsaw and drill press, so I needed a solution made from aluminum plates.
I had never used those low temperature aluminum brazing rods before, but after watching this video, I was impressed. And, sure enough, it was very easy to fabricate some mounting plates for the amplifier modules from 1/16″ aluminum sheets and angle stock. The welds aren’t beautiful, but they are very strong and the material bonds perfectly to brass nuts for quick and easy threaded inserts. Where was this stuff years ago when I used to do more chassis work?
The final amp/DSP/CPU/WiFi/power supply layout is shown below. The power supplies are 100W (15V) and 150W (36V), which may seem on the small side for a speaker of this size. However, the speaker has a total of 36 drivers, and with that many motors the efficiency is very high. The primary input is the Wiim Mini, connected to the SSM3582 amp board via TOSLINK. There is an additional analog input to connect to a TV. The board has an another I2S input, but it hasn’t been made available at the back panel. There is still a lot of wiring to be completed that will make this 10-channel amp quite a bit “busier.”
Part 3: Software
The Sigma Studio Code (DSP)
Sigma Studio allows you to design the required DSP architecture. Once this architecture is defined, it can be “controlled” in real-time by an Arduino microcontroller. Since we want a 5-way crossover with up to 10 poles for each filter, we have assigned 10 biquads to each channel. There is also delay for each channel, along with volume controls and polarity management. There is an overall 10-band EQ, along with baffle step compensation. An architecture that meets these requirements is shown below:
This architecture is a variation of the one used for the ADAU1701, and it pretty much provides cells that can do anything you would expect of a 5-way crossover with volume, delays, polarity, etc, and some common EQ/BSC/volume/selector/bass enhancement functions. Once this generic architecture is properly defined, we won’t need to make any changes, as all of the features that we need are available. And we don’t need SigmaStudio anymore to control the DSP. We simply provide the right parameters from the Arduino CPU to control these cells in real time using the slave SPI interface.
Even with this rather large SigmaStudio design implemented with double precision, we are only using 21% of the total capacity of the ADAU1466. If we want to add other features later on, there is plenty of “horsepower” that is still available.
There are over 80 unique cells that we need to control in this architecture. The compiler assigns addresses to each cell that we can extract from the “PARAM.h” file for the ADAU1466. There is a simple .NET program that I use to extract these addresses, and the output is formatted as code that can be compiled for the Arduino. For example, the first few addresses in the Cell_map.h file for the EQ block looks like this:
#define EQ_32 39
#define EQ_64 44
#define EQ_125 49
#define EQ_250 54
...These addresses define the starting location of each of the 80+ cells, and then the next challenge is figuring out what to put in those locations to control the volume, set up the biquad parameters, or control other functions. Fortunately, this work was done for the ADAU1701, and the existing ADAU1701 software is mostly reusable. For example, the biquad coefficients are calculated as floating-point values, and the only difference between the ADAU1701 and ADAU1466 routines is the conversion to a different numeric representation. The ADAU1466 represents numbers in 8.24 format versus 5.23, and the conversion routine from floating point to either of these formats is straightforward.
There were a number of other changes to the code as discussed in the post of April 16, 2023. Also, some volume tables need to be changed to adjust for the 32-bit integer format of the ADAU1466 audio data vs the zero-filled 40-bit data used in the ADAU1701, but none of the changes are difficult–just very, very tedious. Each cell will need some code change, and with over 80 cells these changes will take a long time to complete.
The Arduino Software
As documented elsewhere on these pages, there is a lot of ADAU1701 code that I can adapt to the ADAU1466. There are a lot of new features that need to be implemented, but the code is nicely structured such that adding new commands is relatively painless. But the first major change was getting the lowest tier working, which is the layer I was calling “I2C”. I had this layer implemented for the ADAU1466 Core Board but ran into a major problem with the SSM3582/ADAU1452 board. It turns out the I2C slave pins on the DSP aren’t connected to the USBi 10-pin connector on this board, so the code had to be re-written to use SPI. It took some futzing with a logic analyzer to get this code working, but now I have a working SPI library that can control the ADAU1452/ADAU1466 from the ESP32C3 microprocessor. The two main routines in this lowest layer, “multiple write” and “biquad write,” still need some refinement to be more versatile library functions, but they are both working using the default ESP32C3 SPI pins.
The high-level commands for controlling the speaker are similar to those described in the article on the ADAU1701 software, but some of those commands have evolved, and we will need several new ones for this speaker and the next-generation line array. For example, we will need to support multiple configurations with extensions to the “Save” command, and we will want “Curvature” and “Shading” for the line array. And for the Marthas, we will need a “Dipole” command to switch between dipole and monopole modes and to apply the frequency compensation for the dipole cancellation. The Marthas also need to support a 5-way crossover, and this will result in some re-thinking of the crossover commands. The final set of commands and the responses from the microprocessor will be posted in a subsequent article on this site.
I added a simple multiplexer board to automatically switch control of the ADAU1466 between the ESP32C3 and the USBi board. Whenever the USBi board is plugged in, it routes the SPI signals from the USBi instead of the ESP32C3. This makes going back and forth between SigmaStudio and Arduino code much easier. The board also provides an easy way to mount the ESP32C2 to the chassis. The board cost a whopping $4.90 at SEEED fusion for a run of 10 boards (49 cents each). I’ve got a second-generation version of this board on order that provides an I2C expansion port plus some additional I/O pins to allow resetting the ADAU1466 with the micro. The I2C port will allow controlling the LED’s from the cell phone app.
The Android/iOS Code
The more challenging software upgrades will be in the cell phone app, as it is time to do some major overhauling using the latest Android SDK. The current design is based on a relatively old implementation of the Bluetooth BLE services, and there has been significant evolution of these services to address security concerns.
But the bigger challenge with using Bluetooth control is that we are trying to control stereo speakers, and Bluetooth BLE is not a “broadcast” protocol that can connect to both left and right BLE clients at the same time. There are ways to deal with that limitation, with BLE mesh or BLE/Classic coexistence, but we need a solution that will work for both Android and iOS, and that further limits our options. Rather than spend a lot of effort on getting the Bluetooth messaging to work with stereo speakers, it seemed time to take advantage of the emerging Internet of Things (IOT) software. Arduino IOT Cloud has been available for several years now, and it seems to have enough momentum to justify incorporating that protocol in our design.
Arduino IoT Cloud is based on MQTT, which has been available for many years. I have used MQTT in the past to control the ADAU1701, and it works well. But the Arduino IoT Cloud tool has evolved nicely, with some nice widget software for quickly developing apps that will run on Android, iOS or the PC. We will continue to work with Android Studio as our main client software but will provide a simpler client using Arduino IoT Cloud for the more common control functions for the Marthas, such as volume, input selection and switching between saved configurations.
The biggest “problem” with MQTT is that it requires a server “somewhere” to receive requests and publish responses to which clients can subscribe. The MQTT server can run on a PC or other computer in your own house, but ideally, you want a cloud-based server to allow remote connections. There are several free MQTT servers that anyone can use, but at some point, you will probably want the additional features provided by a commercial server. Arduino provides a free server for a limited number of clients, plus a good choice of low-cost plans that work well for Maker and DIY hobbyists, so we will focus on using the Arduino IoT server. The emerging Matter protocol might be a better choice in the future, but until there is a proven library for the ESP32, we’ll stick with MQTT.
Dipole Compensation and Switching
The initial design of the repurposed Marthas will employ a 5-way crossover. Each tier or “ring” of the structure will have radiators on both the front and back that can either be in-phase or out of phase. When the radiators are out of phase, some frequency response compensation will be required to compensate for the phase cancellation, and perhaps we will need to adjust the gain to have the same room response. Linkwitz discusses the required compensating network for the simple dipole radiator on this page, but his model is derived from two point-sources rather than 4 drivers arranged in a semicircle. We will attempt a mathematical model of the response at a later date, but initially characterize the response experimentally, using measurements.
To ensure adequate compensation for the dipole low frequency response, we have added an additional biquad to each driver pair, along with the phase reversal and switching. The SigmaStudio module that implements these functions is shown below. This module is a “Hierarchy Board” in the SigmaStudio Design, so it shows up as a single block in the main schematic.
Adding this compensation network to the SigmaStudio design requires 20 new command codes in our Android Studio code to control the type of biquad filter, the frequency, the “Q” and gain for each driver set, plus another command that controls all the selector switches for bypassing these filter stages. This requires a new Android Studio layout for all of the new controls, plus handlers to convert the user inputs to the command codes. Once the commands are defined, we can implement each of the commands in the Arduino code. These commands use existing library functions to calculate the biquad coefficients and to format the data for the ADAU1466, so adding this dipole compensation is tedious but not “hard”. The overall flow for adding new functionality to our active speakers is summarized in this list:
- Add the DSP functionality in SigmaStudio
- Develop a new user interface layout in Android Studio
- Develop the code to handle the Android Studio controls
- Add the commands to the Arduino code
- Add the command execution to the Arduino code
Desktop testing
[Lots more to come…]