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:

1. 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.
2. 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.
3. 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. ATA Bus. Not used
6. 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.
7. 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.
8. 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.
9. 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).
10. 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.
11. 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.
12. 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.
13. Timers/GPIO. Various control signals are implemented with the Timer pins in GPIO mode. Examples are Mute, Reset, PowerDown, ...etc.
14. 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.
15. 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.

Intellon HomePlug AV White Paper

Homeplug uses the same OFDM modulation as 802.11 wireless. The Intellon chips contain dedicated hardware for doing real-time FFTs of the powerline signal. The actually circuitry is not that complicated. Here's a picture of an older 14Mb Homeplug device. The circuitry is very similar for 85Mb. The long back thing at the bottom of the photo has been replaced with an analog chip from Intellon.

DigiSpeaker is a cached music system. It is intended to be used to play music that has been previously stored in the system. Because DigiSpeakers are distributed throughout a home and buried in walls and ceilings (often inaccessible), it is important that all DigiSpeakers be connected in some manor as to make loading music simple and convenient. The obvious choice, of course, is to network DigiSpeakers together. Furthermore, it seems obvious that each DigiSpeaker appear as an Internet node so that they can be accessed inside or outside the home (depending on router settings, of course).

Since DigiSpeaker is a cached system, all music scheduled for playback exists in DigiSpeaker before it is played. As mentioned in previous posts, each DigiSpeaker will have ample storage for music (provided by plug-in flash sticks or memory cards). Also, as previously mentioned, several DigiSpeakers in an installation will 'band together' to form one large storage in such a way as to make music stored on one node accessible to all nodes in the home.

So, networking is important to DigiSpeaker. But at a glance, it would appear that the required network throughput is not all that high. Each DigiSpeaker need only be able to acquire (either from its own cache or from another unit) a new song in the time it takes to play the previous song. If that new song needs to come over the network, then the required throughput is low. For example, if an MP3 file containing a 3 minute song is around 3MBytes in size, then the required network throughput is only 17KBytes a second. Hardly taxing to modern networks even given dropouts and lost packets.

However, experience has taugh us that you can never have too much bandwidth. We anticipate DigiSpeaker to be no different. As the feature set of DigiSpeaker grows, so will its bandwidth requirements. For instance, if DigiSpeaker is ever used to stream live events (like sports or concerts), then a system of caches will add unacceptable delays to the sound. Those delays will be noticed by the user watching a video of the event and expecting the sound to be in sync. We expect this type of feature growth to be common with DigiSpeaker so it suggests a design goal for network throughput (and processing power in general). That is, we want to add as much bandwidth to the system as we can afford. In this case, we think we can afford about $10.

Another thing experience has taugh us is that networking devices in places that do not have networks can be problematic. This is the exact situation in homes. Most homes do not come wired with Ethernet cables in the walls. To get around this, of course, people use wireless or powerline connections. However, we notice that any of these solutions (wired, wireless, powerline) have 'challenges'. Wireless connections are sensitive to interference and building structure. Powerline connections have trouble transmitting across phases. Wired connections are impractical and/or unattractive if they haven't been built into the walls. Seeking to avoid these shortcomings suggest another design goal for the DigiSpeaker network. That is, each DigiSpeaker should have as many connection modalities as possible to give the user multiple connection choices. In this case, it means that each DigiSpeaker should be capable of communicating over wired, wireless or powerline connections. To avoid skyrocketing the cost, the choice of connection could be specified at manufacturing time so as to avoid including connection choices that the user knows they do not want.

Always mindful of cost, we went searching for ways to implement these three connection types on the MPC5200. Our goal was to find parts that could be afforably added to the design (once again, affordable generally means about $10 or less to us).

Starting with the wireless connection, we discovered that most wireless chipset manufacturers would not return our calls. Digging a little further, I found somebody at Broadcomm that explained to me that they don't work with independent hardware vendors (read: little guys) because most were not capable of passing through the worldwide licensing requirements for certifying a wireless device (hmmm). They suggested that we look into adding a prebuilt wifi module that presumably had already been blessed by the certification process. Fine enough... we went looking and discovered that they aren't affordable (by our standards, anyway). However, we noticed that USB modules, which are banged out in the millions per year, do seem to be at least reasonable (around $30 or so retail). Of course, cheap USB dongles are hardly appropriate to be the cornerstone of our network, so we went looking for an alternative.

That alternative appeared in the form of the Intellon INT5500 powerline mode chipset. This chipset is capable of transmitting information over powerlines in homes at up to 85Mbps. It is compatible with HomePlug 1.0 and doesn't interfere with Insteon (yet to be verified). Best of all, Intellon returned our calls and agreed to sell us chips.

The Intellon INT5500 connects to the MPC5200 via its MII interface. However, each DigiSpeaker is supposed to retain a wired connection. To get around this, Jon found an Ethernet controller with a PCI interface. It is the KSZ8841-PMQL from Micrel. This chip is affordable by our standards.

So, to achieve our goals of affordable bandwidth and varied connection types, we have decided to: 1) add a second USB connector so that any Wifi module can easily be added. 2) add the Intellon INT5500 chipset so that any DigiSpeaker can network with another over powerlines, and 3) add an Ethernet connection via PCI so that any DigiSpeaker can be networked directly.

There are a couple of ways to add an external audio clock to the MPC5200. The first thought is to run the MPC5200 I2S interfaces in slave mode and use an external audio clock to clock the interface externally. The idea would be to put the audio clock in the 'middle' of the connection between the MPC5200 and the TAS5504, running both devices in slave mode. The problem with this approach is that the MPC5200 can not produce bit and frame clocks while in slave mode. So, if an audio clock is added in this fashion, external logic also has to be added to create the bit and frame clocks. That adds complication/expense because that external logic would also have to be programmable to adapt to the different data rates we hope to support.

Jon pointed out that the MPC5200 does have a 'cell phone' mode where one programmable serial controller (PSC) can be used to clock another. The cell phone mode of the MPC5200 allows PSC1 to accept an external bit clock and pass it along to another PSC as its master clock. The second PSC is then free to use that master clock to produce bit and frame clocks, as well as transmit and receive data.

One hiccup in this plan is that when a PSC is driven in this fashion, it does not emit a master clock signal itself. So, the master clock has to be sent directly from the external clock chip to the TAS5504. A potential problem might be that as the master clock propagates through the MPC5200 to produce the bit and frame clocks of the slave PSC, it becomes delayed/skewed from the original master clock signal to the point that the TAS5504 is out of sync. However, the TAS5504 documenation says that this should not be a problem.

So, to prove this point and to gain some experience with this setup, we decided to do the following experiement.

We decided to use the MAX9485 from Maxim as the audio clock source. This chip can be controlled via I2C and supports audio data rates of 32KHz, 44.1KHz, 48KHz, 88.2KHz and 96KHz. Through internal manipulation of the clocks inside the MPC5200 and the TAS5504, we can also use this chip to support 176.4KHz and 192KHz.

The Clock Output of the MAX9485 was connected to the master clock input of the TAS5504 and the bit clock input of PSC1 on the MPC5200. The bit, frame and data output pins of PSC2 on the MPC5200 were then connected to the I2S channel 1 input of the TAS5504. The pictures below (sorry for the poor quality. Time for Tyler to get a new camera!) show how the chip was added to the first prototype. I decided to mount it on the bottom of the expansion card so that I could more easily wirewrap the connections to the patch field and the TAS5504 input header. You can just make out the power capacitor hanging out the bottom of the expansion card in the top view picture.

I have also attached two programs that I used to test the setup.

1. tasclock

This program is analogous to the previous program called tastone. It can be used to play square, triangle and sine waves of the supported frequencies on the TAS5504. The MAX9485 and the TAS5504 have to be setup manually (using something like i2cset) before tasclock can be used.

2. tasplay

This program is analogous to the previous program called taswave. It can be used to play small wave files on the TAS5504. This program sets up the MAX9485 and the TAS5504 so there is no need to manually configure them. However, you do still have to set the mater volume of the TAS5504 (I2C register 0xD9).