The complete schematic for Prototype IV can be found here. This is the electrical expression of the ideas outlined in my previous post. For the most part, nothing has changed. Use the first page of the schematic (Block Diagram) to get an overview of how the features have been included in the design.
- Block Diagram. Notice that ATA is about the only pin group not used in the design.
- Boot Configuration. We are using the default boot configuration. Could be changed via jumpers.
- Core Logic. Memory and I/O signals of the MPC5200. Here is a list of the pin group assignments:
- PSC1: Configured as a Codec in Cell Phone mode. The clock pulse from the MAX9585 is input on the BitClock of this port. This port acts as the Cell Phone master for PSC2.
- PSC2: Configured as a Codec in Cell Phone mode. This PSC is a Cell Phone slave to PSC1. It is the source of the I2S stream to the TAS5504.
- PSC3: Configured as USB. The USB pin group was configured as two UARTs so the USB function was moved to this pin group.
- USB: Configured as UART4 & 5. The design needs a serial port for Boot (UART4) and Insteon (UART5). The USB pin group is the only pin group that can have two UARTs. So USB was moved to the PSC3 pin group.
- Ethernet: Configured as Ethernet. This pin group connects to the Power Line modem.
- PSC6: Configured as SPI. This pin group connects to the SD Card connector. SD Cards are going to be used for our mass storage.
- Timers: Configured as GPIO. This pin group connects to the various control lines for the peripherals. There is a note on the schematic with the assigned functions.
- IRQs: The CPU can be interrupted by PCI or the amplifier power stages (on over heat or shutdown).
- I2Cs: I2C1 is connected to the TAS5504. I2C2 is connected to the MAS9485. Jon says the TAS5504 requires a lot of configuration information so he wants to run the I2C lines at full speed. So I2C1 will be high speed and I2C2 will be left for slow speed devices.
- Dedicated GPIO: The CPU can be woke-up on IR signal or by the PCI bus. I think we still need to find a way to wake-up the CPU on Insteon and Power Line events. Hmm...
- LocalBus: Contains two 16MB Flashes. One is on CS0 and the other is on CS1. There are jumpers so they can be swapped.
- MemoryBus: Configured for DDR. There is 64MBs of 133MHz RAM.
- Core Clocks & Debug. The MPC5200 JTAG interface has been brought out. We plan on purchasing a JTAG probe for boundary scan and programming the Flash. Notice that we are using two voltage monitors (MAX6717 - open collectors) to hold the CPU in reset until all the power rails are stable.
- Core Power. Bunch of capacitors to provide immediate power to the CPU.
- Flash Memory. We have included 32MBs of memory in two Flash chips. They are on separate chip selects that can be swapped. The idea here is that one can be used as backup during development.
- Insteon Interface. DigiSpeaker can be commanded with Insteon devices through this interface. It connects to the CPU via UART5. It detects/transmits 131.65KHz signals on the powerline.
- Ethernet via PCI. The Ethernet interface on the MPC5200 is used by the Power Line modem so regular ethernet has been added via PCI.
- Power Line Modem Controller. This is the Power Line modem controller and Analog Frontend from Intellon.
- Power Line Modem Driver. More Power Line modem stuff. This is the actual interface to the powerline. It transmits packets simultaneously on several channels between 4MHz and 22MHz (transmit path). It can receive them as well (receive path).
- Pulse Width Modulator. All four outputs of the PWM have been connected to output stages. This schematic also has the clock chip that drive the Cell Phone mode PSCs.
- Primary Output Power Stage. Channels 1 & 2 of the TAS5504 are connected to this power stage. The two channels are configured as BTL.
- Secondary Output Power Stage. Optional second power stage. Channels 3 & 4 of the TAS5504 are connected to this power stage. There are jumpers to configure the power stage as PBTL. In which case, channel 4 of the TAS5504 is used. Otherwise, it can be configured as two BTL channels.
- Memory Bus Terminators. Inline current limiters for the SDRAM memory lines.
- SDRAM. 64MBs of 133MHz SDRAM.
- Serial Port, SDIO & IR Remote. Boot serial port that can be used to monitor the system. SD Card connector that is used as mass storage. IR receiver so DigiSpeaker can be commanded with an IR remote.
- USB. USB connector for whatever device we think we need. Ideas are Z-wave or Wifi.
- Power Regulation. This prototype is designed to work with a three rail power supply (24V, 12V & 5V). The remaining power rails are created with LDOs.
A conceptual diagram of DigiSpeaker Prototype IV is pictured below. Unlike previous versions, this design does not include analog/digital I/O and is capable of driving stereo speakers or bi/tri-amping a single speaker.
- Simple Stereo Mode. In this mode, a single DigiSpeaker is used to drive two speakers in stereo. The speakers will have crossover circuitry to handle the separation of tweeter and woofer frequencies. In this configuration, only two of the TAS5504 processing pipelines will be used (PWM 1 & 2) for left and right channels of a stereo signal. The bi-quad filters are used for music shaping (country, rock, rap, jazz, ...etc). The treble, bass, loudness and dynamic range control are used in the traditional manor.
- Full Stereo Mode. In this mode, a single DigiSpeaker is used to drive two speakers in stereo. In addition, a subwoofer channel is driven from a second TAS5342 built into the DigiSpeaker. In this configuration, two TAS5504 processing pipelines are used for stereo processing (PWM 1 & 2) and a third is used for subwoofer processing (PWM 4). The bi-quad filters are used for music shaping. Treble, bass, loudness and dynamic range are set as the user prefers.
- Bi-Amp Mode. In this mode, a single DigiSpeaker is used to drive the tweeter and woofer of a single stereo channel (either left or right). Two DigiSpeakers are expected to be used in a zone to complete the delivery of both left and right stereo signals. Two TAS5504 processing pipelines are used (PWM 1 & 2) but they both are given the same input signal (either the left or right stereo channel). The bi-quad filters are used to implement the speaker crossover as well as music shaping. Treble, bass, loudness and dynamic range control are used as the user prefers. Notice that using two DigiSpeakers in a single zone doubles the power delivered to that zone. In fact, it is possible to add any even number of DigiSpeakers (2, 4, 6, ...etc) to increase the power delivered to a zone.
- Tri-Amp Mode. In this mode, a single DigiSpeaker is used to drive the tweeter, mid-range and woofer of a single stereo channel (either left or right). Two DigiSpeakers are expected to be used in a zone to complete the delivery of both the left and right stereo signals. Three TAS5504 processing pipelines are used (PWM 1, 2 & 4) but they all are given the same input signale. The bi-quad filters are used to implement the speaker crossover as well as music shaping. Treble, bass, loudness and dynamic range control are used as the users prefers. Like the Bi-Amp mode, this mode can be used to increase the power delivered to a zone simply by installing more DigiSpeakers.
- Power Supply
Like previous versions of DigiSpeaker, Prototype IV has the MPC5200B from FreeScale at its core. Even though this processor is a little expensive ($18ea. in 1000s) we still like it. It is well supported in the Linux kernel. It has a wide range of peripherals. It consumes little power yet has a lot of punch (contains an FPU also). This might change in the future, however. NXP has developed the LPC32xx family of processors. These processors are enhancements of their LPC3000 series. We previously considered these processors but rejected them because they lacked I2S interfaces. However, the new family of processors has a couple I2S interfaces. They are comparable to the MPC5200 in power yet they cost half the price (that is just a rumor at this point). For now, we are sticking with the MPC5200 until the LP32xx processors are in production.
We have dropped WiFi support in favor of a powerline modem chip set from Intellon (INT5500CS). WiFi modules are expensive and can be 'tricky' depending on the installation. We noticed in the Sonos forums that the major complaint about their unit is WiFi reliability (or lack there of). Sonos has recently elected to step up the 802.11n to try and fix the problem. This plan has a chance but is yet again, more expensive and the vendors that sell the chips are even harder to work with. So, we have decided to use the powerline modem approach. Notice that we still have USB in our system so it would be possible to slip in a USB WiFi module if it is required.
We still plan on using Insteon as our wall control. The idea here is that users will outfit their homes with Insteon compatible switches that can command the DigiSpeakers for things like volume control and playlist selection. We are also keeping our IR control link (not pictured) so that any 38KHz remote control can be used to control the unit. Also, we are keeping our browser interface to an installation for full control. Finally, Jon has been playing with the iPhone and iTouch devices from Apple. He likes them a lot and will probably build an interface into these devices (browser based?) as well.
The major difference between this prototype and previous versions is the amplifier. We are still using the TAS5504 as our PWM processor and the TAS5142 (or TAS5342 if available) as our power stage. Both are from Texas Instruments. However, we now configure the output stage as Bridge-Tied-Load (BTL) and drive the speakers differently via software depending on the product (more on the products in a minute).
At 96KHz and below, the TAS5504 has 4 independent processing channels that can be configured to accept either channel (left or right) from any of the I2S interfaces. Above 96KHz, the TAS5504 runs out of processing power and can only process 3 channels (see page 11 in this document). The processing pipeline for each channel is impressive. Each channel has seven bi-quad filters, base, treble, volume, loudness and dynamic range control. Also, each channel has an output mixer with gain control to mix any of the processing channels at output. With this flexibility, it is possible, via software, to create several products from the proposed design.
The MPC5200 requires an external clock chip to reach speeds above 96KHz. So, there are potentially two grades of each of these products depending on whether the clock chip is included or not. In addition, the addition of the second TAS5342 could also be a product differentiator.
The power supply for DigiSpeaker is still an important component. Power supplies tend to get more expensive above 100W where high efficiencies are required to keep the heat produced to acceptable levels for installation in a wall or ceiling. However, power supplies in the 60W to 70W range are pretty cheap because they are commonly used for TVs and Laptops and they produce less heat. The new DigiSpeaker design could potentially use a cheaper power supply when configured in Bi-Amp or Tri-Amp modes because they are powering less speaker. Deploying two DigiSpeakers in a zone could add up to the same power as a single DigiSpeaker in Stereo mode.
For now, the power supply remains the same as previous version. We will try to deploy a 130W power supply that can be used to power the logic and deliver 100W of power to the speakers. This is probably overkill for he Bi-Amp mode (and possibly the Tri-amp mode), but will just be comfortable for either of the Stereo modes.
Both Jon and I had to camp this project to deal with issues in RL. We are done with that now and back to work on DigiSpeaker.
During the break, Jon had a chance to rethink our model and has made some adjustments. For instance, Jon no longer feels it is important to have direct I/O in the modules (analog/digital input and output). He feels that there are other devices that do a better job of this and it is not worth the expense. I agree with this change. DigiSpeaker shines as an internet connected amplifier. How the music gets into the cache of each node is really a separate problem. I would prefer that users simply 'drag and drop' music files into the nodes of an installation and forget about it. How the music files are created (ripped from CD, recorded from analog, ..etc) is another problem that has been well solved by other devices.
Also, Jon would like me to design a system where DigiSpeakers can be 'piled' into a zone to achieve higher power levels and better sound quality. This is a little harder to explain. But what he is getting at is a system where two or more independent DigiSpeakers cooperate to play music. For instance, if a single DigiSpeaker is in a zone, then it should be capable of driving a pair of stereo speakers (traditional left and right speakers with crossover circuitry). However, if two DigiSpeakers are installed in a zone, then one should be able to play the left channel while another plays the right channel. Since two DigiSpeakers are involved, each with a separate power supply, it would be possible to double the power delivered in that zone. Furthermore, in this configuration, it would be possible to bi-amp the speakers attached to a node so that the tweeters and woofers are driven directly from the amplifier. Crossover would be achieved digitally in the PWM processor. This could greatly enhance the quality of sound for any installation because all deployment flaws could be corrected in software.
A block diagram will make these two important changes clearer. I will post one with a discussion in the coming days.
The block diagram of the third prototype can be found here. You will have to zoom in quite a bit with this diagram. This diagram is the front page of the third prototype schematics and I still don't have a good/free method for translating DXF files to PDF yet.
Notice that there are actually three separate systems in this block diagram connected to a common controller design. The intention is to build a single PCB, but change its function by including/removing certain parts. The three systems are:
- Embedded. The Embedded Model is intended to be the unit that is installed in ceilings and walls of homes. It is assumed that this system will not have direct connections to external music sources so it does not have an I/O module. Of course, it does have an amplifier.
- Desktop. The Desktop Model is intended to be an standalone unit that might sit on a desk or table in a room. This unit has the potential to be directly connected to legacy music sources so it does include an I/O module. Of course, it also includes an amplifier.
- Media Center. The Media Center unit does not include an amplifier. This unit is intended to be used with other media equipment in a cabinet so it does have an I/O module. However, it is assumed that the music is shipped out to other amplifiers (including other DigiSpeakers) so it does not include an amplifier.
The controller is a Freescale MPC5200. Its subsystems have been assigned as follows:
- Clocks and Reset. A 33MHz crystal will be used to set the MPC5200 clock speed to 528MHz (fastest setting). Soft and hard (button) resets will be supported.
- JTAG. We are going to use JTAG to program the embedded Flash during production. We hope to make our own simple JTAG system for doing boundary scan on the MPC5200 and leave in-circuit debugging for later when we can afford a nice JTAG system.
- SDRAM Memory Controller. We are going to add 64MBytes of DDR266 memory (MT46V16M16P-75 or equivalent). Jon says that will be plenty of memory. We might back this down to 32MBytes depending on price. Right now, there isn't much difference. Notice that the 128MBits and 256MBits share the same package footprint.
- Local Bus. The MPC5200 boots on chip select zero of the local bus. We are going to put 8MBytes of NOR Flash at chip select zero as the boot ROM. More than likely, it will be a Spansion S29GL064. Jon thinks that 8MBytes might be a little tight (compressed kernel + root file system is about 6Mbytes). If so, we will up the flash memory to 16MBytes with a Spansion S29GL128N. The two packages have the same footprint.
- ATA Bus. Not used
- PCI Bus. The MII of the MPC5200 is used for the powerline modem so a PCI to Ethernet bridge is used on this port to give the system cabled Ethernet. We are going to use the KSZ8841-PMQL from Micrel.
- PSC1. The audio clocks that the MPC5200 can generate are not very accurate, especially at 192KHz. To fix this problem, we have added an external audio clock to the design. To cut down on the amount of external logic it might take to integrate the clock, we decided to put a couple of the serial ports on the MPC5200 into 'cell phone' mode. This mode allows an external clock to be input on one port and then used as a master clock for another port. The 'master' cell phone port is PSC1. In the case of the Embedded system, we are using the MAX9485 from Maxim. For the other systems, we are using the integrated clock of the WM8580 from Wolfson.
- PSC2. The second serial port of the MPC5200 is used as the slave cell phone port. This port receives a master clock from the first serial controller and uses it to compute bit and frame clocks for an I2S connection to the PWM modulator (TAS5504 from TI). Notice that in the case where music is being sourced from an external device, the MPC5200 can be bypassed with a direct connection from the WM8580 to the TAS5504.
- PSC3. This port is split between a UART and SPI connections. The UART is connected to an RS232 driver and is used as the boot monitor. The SPI connections is used as the connection to a mass storage device (SD Card or MMC).
- PSC4. This is the USB port. Right now, the USB connection is unassigned. However, it can be used for more mass storage or a WiFi module connection.
- PSC5. This port contains an Ethernet controller that is normally connected to an Ethernet PHY. However, the powerline modem chipset (INT5500CS) acts like an Ethernet PHY and expects an MII to a controller. So, this port is connected to the powerline modem and cabled Ethernet is supported via the PCI bus.
- PSC6. The port is used at the serial connection to the Insteon controller. The Insteon controller connects directly into the powerline and can receive and send commands from/to other Insteon devices. This is one way the unit can be remotely controlled.
- Timers/GPIO. Various control signals are implemented with the Timer pins in GPIO mode. Examples are Mute, Reset, PowerDown, ...etc.
- Dedicated GPIO. The Infrared receiver is connected to these pins so the user can control the device with a simple IR remote. These pins have wakeup capability so they can be used to get the system out of sleep mode.
- Power. The power supply is split into two sections roughly corresponding to Digital and Analog power. The Analog supply is a variable power supply (+32V to 0V) that can be controlled by the volume control of the PWM modulator. The Digital supply has a separate controller and outputs the various fixed system voltages.
If you are interested in the technical details of how powerline broadband modems work the paper linked below provides a nice overview. We're using the 85Mb PHY version which really means about 30Mb of useful bandwidth. We considered the 200Mb version (65Mb useful) but we don't think it is worth the added cost for our application. The only time you'll notice the peak network speed is when you are copying music to the nodes. Once the music is in the nodes there is plenty of bandwidth available to play it.
The bandwidth of powerline modems is shared with your neighbors on the same power transformer, usually not more than five homes. This could potentially be a problem that will be examined with field testing. The load caused by bulk copying to the nodes can be controlled using QOS. We don't think the shared medium will matter since music doesn't need a lot of bandwidth to play.