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

We took another hard look at processors for the system and came to the conclusion that the FreeScale MPC5200 is a good choice. While it is true that its clocks are inaccurate for audio, it is a powerful and versatile processor that gives us a lot of design room. We have done some experiments with an external audio clock (see my next post) and have convinced ourselves that we can correct (replace) the inaccurate clocks without too much difficulty.

The MPC5200 is a powerful processor. It runs at 528MHz and has an integrated floating point unit. For audio processing, this is overkill. There are many ARM based processors that lack floating point that can handle audio processing (mp3 decodes and whatnot). However, we have decided to go with a processor that has ample processing power because we believe that DigiSpeaker is a platform that will take on many different purposes in the future. To embed a marginally powerful system in the walls and ceilings of homes for the next 20 years is probably a bad idea. It is clear that home entertainment is going to require more power, not less, in the future.

The MPC5200 is not the only powerful processor out there. We took a hard look at the EP9302 from Cirrus and the MX31 from FreeScale. Both are ARM based processors with integrated floating point units. The MX31 is a little more expensive than the MPC5200 and the EP9302 is way cheaper. However, in each case, we found that the processors were not as versatile as the MPC5200. For instance, the EP9302 can produce very accurate audio clocks, but it can't do it while still supporting USB. The MX31 can also produce accurate audio clocks, but it doesn't have an integrated Ethernet controller so that would have to be added to the cost of goods. Another processor that looks pretty good is the LPC3180 from NXP. However, it lacks I2S interfaces. Minus the inaccurate clocks problem, we have yet to find features that we could not easily add to our MPC5200 design.

Fast. Integrated FPU. Large and varied set of peripherals. Moderate price. Native Linux support. For now, MPC5200 is a good choice. We can reconsider that decision when/if NXP adds I2S to the LPC3180 and/or FreeScale makes an MX31 with integrated Ethernet.

The MPC5200 is a very powerful and versatile chip. It runs at better than 500MHz. It has an integrated FPU. It is well supported in Linux. It has a rich set of peripherals (UART, Ethernet, USB, I2C, I2S, ...etc). Unfortunately, as an audio processor, it has one serious flaw. The I2S interfaces can not be clocked at common audio frequencies using the internal clock. This means that any quality audio design using the MPC5200 requires an external clocking source.

The addition of an accurate external clock does not disqualify the MPC5200 as an audio processor. It is still very powerful and versatile. For instance, the FPU can be used to encode/decode audio files without really taxing the CPU. But, the MPC5200 is a little expensive compared with other chips that can be used for audio processing. The MPC5200 is about $18 in 1000 quantity. The addition of an external audio chip (with crystal and glue) will add another $2+ to the design. That adds up to $20 of cost just for the CPU.

By comparison, the Cirrus EP9302 is a $10 chip (in 1000 quantities) that has the ability to accurately produce all the common audio frequencies. That is half the price of the MPC5200 and translates into a $30 to $50 savings on the retail price. That is a significant percentage (10%) of the target price of a DigiSpeaker node (~$500 at this time).

For certain, the Cirrus EP9302 is far less powerful than the MPC5200. It is an ARM9 chip with an integrated FPU that runs at 200MHz. Decoding compressed audio files will take up a significant portion of the available CPU cycles. However, representatives of the company assure us that it can keep up with audio decodes and still have cycles left for other tasks (user interface, file read/write, network, ..etc). The EP9302 probably is not powerful enough to encode audio files, but that is not required of most DigiSpeaker nodes. The few nodes that do require audio I/O (we predict one to two per house) can be constructed with the MPC5200 driven by clocks sourced from the I/O module itself (the very accurate Wolfson WM8580).

At this time, the MPC5200 is our primary choice. However, we have purchased evaluation boards for the EP9302 to do some experimentation. The results of those experiments will tell us which CPU to use going forward.