I simplified the schematic in the previous post and built up the circuit on a breadboard.
Here is Schematic A.
I have also included the basic design information in the schematic.

UPDATE: I have redone the schematic again. I now bypass the error amplifier in the UC3845. I removed the +15VDC and +20VDC secondary to simplify testing. I have included snubbers on the primary side.
Here is Schematic C.

The Board. VAC comes in at the top left. The top row is the line filter and AC rectification. The second row has the controller, the power switch and the transformer output. The third row has the optoisolator and feedback control logic. I wound the transformer by hand. It has five separate windings (primary, bias, +5V, +15V, +20V). Each winding is insulated from the other (my first attempt was prettier but it shorted out during a current spike -- always insulate!). The transformer is 'gapped' with 4 pieces of electrical tape. The exact gap was a process of trial and error. I used an RLC circuit to measure the inductance. I had computed that I needed a 450uH inductor so I simply kept adding more gap (more tape) until I got the inductance to come down to 450uH. Of course, this added to the leakage inductance (~26uH).	Built PSU Schematic A - No Snubbers	Built PSU Schematic C - With Snubbers
Here is a picture of the MOSFET drain-to-source voltage (Vds) while regulating a 500mA load on the +5V line. The yellow trace is my Vds and the blue trace is the MOSFET gate voltage. If you know anything about these waveforms then you know this one is a little bit of a mess. What is happening is that during the on-time (when the blue trace is low), the current in the inductor is building and the current in the output (the secondary) is blocked by the secondary diode (the output capacitor holds the voltage). When the MOSFET turns off, the voltage on the primary reverses/spikes to nearly 600V!. This starts the secondary current which build for about 1uSec, then decays for about 4.5uSec. When that ends, the controller goes into discontiguous mode (runs out of current) and it decays to the input voltage over the remainder of the cycle. To fix this, I need to adjust the controller so that is uses more of the switch period (closer to contiguous mode) and add a primary snubber circuit to clip off the 600V spike.	Yellow = Vds Voltage Blue = Gate Schematic A - No Snubbers	Yellow = Vds Voltage Blue = Gate Schematic C - With Snubbers
Here is a picture of the MOSFET source current as measured through the sense resistor. The sense resistor is 0.25 Ohms so dividing any voltage reading by 0.25 will yeild the current. The current ramps from near zero at -6.72uSec (-6.72uSec, -16mV) up to 576mV at -0.28uSec (-0.28uSec, 576mV). During this time, the voltage across the inductor is 150V (nearly. There is a drop across the switch because this switch has a fairly high Rds ~= 2.2Ohms). The voltage across the inductor is equat to the inductance times the change in the current divided by the time (v = L * di/dt). Using this equation, it follows that the inductance is 431uH (=150 * 6.4uSec / 2.24A). This is close to the inductance that was measured using an RLC circuit (=467uH) (at least, within the measurement capabilities of my equipment). Notice the ugly spikes of current at the start and the end of the ramp. They go well over 4Amps! These have to be cleaned up. This inject a lot of noise into the output.	Yellow = Ids Blue = Gate Schematic A - No Snubbers	Yellow = Ids Blue = Gate Schematic C - With Snubbers
+5VDC Output. Both of these pictures were taken with Schematic C (snubbers included). The left picture does not include the output inductor (L2 - 2.2uH). The right picture does.	Yellow = Vds Blue = +5VDC Output Schematic C - With Snubbers - Without Output Inductor	Yellow = Vds Blue = +5VDC Output Schematic C - With Snubbers - With Output Inductor

I am starting a new prototype. The new designation is 'Prototype VII' -- or 'p7' for short.

I thought I would try a 65W flyback switch mode power supply. The idea would be to put one of these into each DigiSpeaker. The flyback topology is compact, low part count and cheap while being relatively high in efficiency and performance.

Click here for the schematic.
Click here or here for the BOM. Q1 price is $22.35. Q1K price is $9.90. Both prices are without transformer, various connectors and so on.

The Design (procedure taken from the Power Supply Cookbook, Marty Brown):

So, Jon and I have been curious about how much of our system response is due to the electronics/speakers and how much is due to the room. In the previous post, you can see that there are a number of spikes and nulls in the response. The room correction filter helps out a lot. However, we were wondering if we could put our system in an anechoic chamber and see the same (nearly same) response.

I posted a question on the Digital Room Correction mailing list and a user named Gregory Maxwell said that most of the response was due to the room. I wanted to put this to the test so I took prototype VI out on my deck for a test.

Bottom Line: Greg was right, most of the nulls and spikes in the response seem to be caused by the room.

Here are a couple pictures of my setup and a screen capture of the responses in Audacity.

Setup. I live on a hill above a lake. My deck is about 12 feet off the ground. From its corner, there is an unobstructed view to the lake. The closest possible reflector is more than 50 feet away and even at that, there are numerous bushes and other 'diffusers' to cancel echoes. I brought my lab computer, bench power supply and the amplifier (TAS5504+TAS5142) to the deck. These are the same parts I use in my lab for previous measurements. Unfortunately, my neighborhood is not very quiet. They are building a house down the block from me (hammers, power tools, ..etc). Cars drive by all the time. The landing pattern for the local airport goes over my neighborhood. Finally, the city seems to just generate a dull/low hum all the time. I have left some of the ambient noise on the end of the traces below so you can get an idea of its magnitude
Setup from Below. This is a picture from the yard below my deck. It gives you a good prospective on how free/clear the area is in front of the speaker.
Microphone. I attached the Behringer ECM8000 microphone to the end of a broom handle. I then asked my wife to hold it about 1 meter directly in front of the speaker while I conducted the experiment (sorry, no pictures of her doing this. We were both too busy.). Of course, this is not very precise but I figured it would be good enough to get a gross sense of the response outdoors so I could compare it with the indoors response. She tried her best, but she was not able to hold the microphone perfectly still. So, as she 'wobbled' it back and forth (about a 2 inch movement), I am sure it effected the response. Next time we get a sunny day (no rain), I will take the time to build some fixed mount for the microphone.
Response. The top trace is the logsweep. The second and third traces are typical recordings done in my lab. The fourth trace is a typical trace done outside. As you can see, many of the nulls and spikes are gone. The spike at 3000Hz (about 33.5 seconds) is our midrange to tweeter crossover. Our woofer to midrange crossover is at 200Hz (at 17.5 seconds) and is really not visible. The 300Hz null (at 20 seconds) that has always been present in the recordings I did in my lab is gone. This is strong proof that the 300Hz null is just a natural dead spot in my basement lab. O... notice that the trace is very noisy. Not much I can do about the noise in my neighbourhood.

Jon and I have long planned on using the spare CPU cycles of the MPC5200 on Digital Room Correction (DRC). Every room in which DigiSpeaker will be deployed will have its own unique frequency response. This means that certain frequencies will resonate in the room while still others will attenuate into nulls. In addition, the imperfections in the electronics and the transducers also contribute to various frequencies being amplified or attenuated. This all combines to deliver music which is, in some cases, wildly different from what the musician intended.

To fix this, Jon and I planned on using the 'DRC: Digital Room Correction' software package written by Denis Sbragion. There is a lot to this package. I will leave the details to the reader. However, in short, to use this package you play a test signal through your system and record the results through a calibrated microphone. You then use the DRC software package to compute a digital FIR filter based on the recorded signal which 'counteracts' the effects introduced in the music by the imperfections in the room, electronics and speakers.

The FIR filters used for DRC are not short. You have to use filters that are 16k to 64k in length to get enough frequency resolution to correct the errors in the system yet not introduce new errors. As you might imagine, running three 64k tap filters (one each for tweeter, midrange and woofer. Convolved with the DRC filter) can seriously tax the CPU. However, by configuring brutefir for eight partitions of 8k each, I was able to run three 64k tap filters and still have 40%+ of the CPU left. At 16k tap filters (which would be good enough for most situations), I was able to obtain well over 50% of the CPU left idle.

To record the test signal from our system, I bought a Behringer ECM8000 microphone and powered it with a Behringer Xenyx 502 mixer. I fiddled around with the input and mixer gains (as well as the amplitude setting of my system) until I was able to record signals that were load (from 50% to 80% of full input) without clipping.

I am currently using Audacity as my sound editing and recording tool. This program is really amazing. It has lots of features and it pretty intuitive. I am running it on my lab computer which is a Dell Dimension 4700. The Dell Dimension has an AC'97 sound card based on the Analog Devices AD1980 codec.

Typically, people doing DRC measurements play and record the test signals using the same sound card. However, DigiSpeaker has no analog input so I play the test signal with DigiSpeaker and record the test signal with the sound card in my computer. The problem with this setup is that the recorded test signal is not synchronised with the playback. To fix this problem, I put three tones at the beginning of the test signal of known length and frequency. I then use audacity to align the signals in Audacity and to cut off the test signals and any trailing signal so the input and recorded signals are 'time aligned'. Once this is done, I use the DRC software to produce the correction filter.

So, how do you create the test signal? The test signal is a logarithmic frequency sweep from 10Hz to 21000Hz. It is generated with a tool that comes with the DRC software. That tools is called 'glsweep' and you invoke it like so:

glsweep 44100 0.5 10 2100 45 2 0.05 0.005 sweep.pcm inverse.pcm

This command tells glsweep to produce a sweep with 2 seconds of silence at the beginning and 45 seconds of sweep from 10Hz to 21000Hz and store it in a file called 'sweep.pcm". The amplitude of sweep should be a consistent 0.5 of full amplitude. The beginning amplitude should taper up for the first 2.25 seconds (= 45 * 0.05) and trail off for 0.225 seconds (=45 * 0.005) at the end. Finally, the inverse of this sweep should be stored in 'inverse.pcm' for use by later calculations. This sweep can be seen in the top trace in the Audacity screen shot below.

I download this signal in the form of a WAV file (Adacity can make on very easily) to Digispeaker. I use the following command to play the test sweep through the system:

brutefir triamp_test.txt sweep.wav

This brutefir configuration file will split the sweep into three frequency ranges (tweeter, midrange, woofer) using three 2k tap crossover filters. They three filters can be seen in the 'Filters' and 'Filters (zoomed)' pictures below. Notice that these are amazing filters. The crossovers are 300Hz and 3000Hz. They all drop off to -80dB in only 100Hz before/after the crossover point. More aggressive drop-offs are possible but shouldn't be necessary given the expected quality of the system. The brutefir script (triamp_test.txt) is attached.

The second trace in the Audacity screen shot below shows the recorded result. Remember that the sweep is a logarithmic sweep of frequencies from 10Hz to 21000Hz. You can compute the exact frequency as a function of time with this formula:

log(f) = (0.073827(t-2)) + 1

Where 'f' is the frequency and 't' is the time that can be read long the top of the image. For instance, the lower crossover (300Hz) can be found in the traces at
22 seconds. That is:

log(300) = 0.073827(22-2) + 1

Once the test signal has been recorded from the system, it is convolved with the inverse of the sweep to create the impulse response for the system. The DRC software comes with a package to do this. It is called 'lsconv' and is invoked like this:

lsconv recorded.pcm inverse.pcm impulse.pcm

To produce the DRC filter, you run the DRC software with a given configuration file. DRC can be applied at different levels from normal to insane. Normal DRC fixes most problems but generally avoids adding artefacts to the music. At the other extreme, the 'insane' levels of DRC will correct the system to produce great sound at one location, but will sound strange if you move away from that location. Various levels of DRC configurations have been attached in the file 'drcconfigs.tar.gz'. In the results below, I am using normal DRC. Here is how you generate the DRC filter:

drc normal_62k.drc

This will produce a 62k tap filter that corrects the imperfections of my system. You can see this filter in the DRC plots below. It is the 'teal' line that is 'floating' just above the corrected crossover plots. I moved the DRC filter up by 5dB so that it did not obscure the other plots. Why only 62k taps you might ask? Well, I wanted to run three 64k tap filters crossover filters in brutefir. To do this, I wanted to convolve my DRC filter with each of my crossover filters to produce three filters that both crossover the music and correct the imperfections in my system. Since my crossover filters are 2k taps each, I decided to make my DRC filter 62k taps so that I could convolve them together to produce 64k tap filters. The results of this convolution are shown in the DRC (and DRC (zoomed)) plots below.

Once I had this procedure down, I produced DRC filters for each of the different DRC levels (normal, strong, extreme, insane) of various lengths (6k, 14k, 30k, 62k). I then convolved my crossover filters in every combinations to produce tweeter, midrange, and woofer filters from 8k taps to 64k taps. For the sake of brevity, I have only included results for 64k tap filters below. Traces 3 through 6 in the Audacity screen shot show recorded results for 64k tap corrected crossover filters with DRC from normal to insane. You can clearly see that even normal DRC adds a lot more 'fullness' to the signal. Also, I can attest that using DRC make the system 'come alive'. When you flip from 'no DRC' to 'DRC' and then back again, the result is like night and day. The DRC music is rich and full while the none-DRC music sounds tinny and weak.

Notice that I do have a problem right at the 300Hz crossover. In all the DRC plots the response seems to go to zero for a short period. I believe this is an experimental mistake that I am still investigating. If you examine the plots carefully, you will notice that DRC attenuates the signal right at about 275Hz. I believe that attenuation is supposed to be at 300Hz where there is a 'bulge' in the none-corrected recorded response of the system. This is probably due to my 'manual alignment' technique described above. That technique clearly needs some work.

Finally, I did try to chain the DRC filter with the three uncorrected crossover filters in brutefir. That result is shown in the last trace in the Audacity screen shot. I did this to investigate the 300Hz null. Notice that is has gone away (a little). Again, I think this is due to DRC being misaligned. However, in this case, the DRC filter is not attenuated by the steep rolloff of the crossover filters which means that the error is not so prominent.

Audacity. This is an Audacity screen shot that shows the experimental result of my tests. The top trace is the test signal played through the system. The second signal is the recorded test signal played through the system without DRC. The third through the sixth traces are test signal played through the system with various levels of DRC (from normal to insane). The last signal is the test signal played through the system with DRC chained with the three crossover filters. Click on the picture to enlarge.
Filters. Here is the three crossover filters plotted from 0Hz to 22050Hz. Each filter has 2k taps. Notice how steeply the filters rolloff, how greatly they are attenuated and how flat they are on top. At 2k taps, these filters are overkill for the quality of our electronics downstream. Click on the picture to enlarge.
Filters (zoomed). Here I have zoomed into the first two crossover points (300Hz and 3000Hz) to show the detail of the filters. Click on the picture to enlarge.
DRC. This plot shows the three corrected crossover filters along with the entire DRC fitler. The DRC filter is the 'teal' line that 'floats' above the other traces. I added 5dB to the DRC line so that it would not obscure the tops of the other traces. Without that offset, the teal trace would exactly tack the tops of the other plots. Click on the picture to enlarge.
DRC (zoomed). Here I have zoomed into the first two crossover poitns (300Hz and 3000Hz) to show the detail of the corrected filters. Click on the picture to enlarge.

The amplifiers on the Prototype VI amp board are oscillating. According to the documentation, the amplifiers will oscillate if the amplifier bypass capacitors have too much inductance to ground. This is the case with the capacitors I purchase. Also, the ground and power traces to the amplifiers are way too narrow creating even more inductance. Ok.. lesson learned.

Instead of doing an entire new amplifier design and layout, I decided to splice-in some amplifiers that I could build from a kit. I decided to purchase this kit from AudioSector. This kit uses LM4780's which are a higher power version of the LM4765's on the amp board. Basically, it is the same design with better layout and higher quality parts.

Here is a picture of a fully constructed amplifier. You get two of these in a kit. These are non-inverting configurations with input DC blocking input capacitors. The gain is set to 9.15 on each amplifier. The DAC's peak output is 2.5V so the amplifiers put out a peak amplitude of 22.8V and deliver 65W per amplifier (I don't drive them this hard).
Here is a picture of the electronics. It looks like a bit of a mess (and it is!). However, it works well enough for Jon and I to experiment with tri-amping and digital room correction. Notice that I am not using the Prototype VI controller card. The controller cards are hard to build and we only have one of them. Since Jon is in Boston and i am in Seattle, we need two system, preferably identical, so we can work together. So, Jon and I are using our Phytec cards for now. The Prototype VI controller card and the Phytec card are functionally identical. Also notice the expansion card with all the red wirewrap connections. This is a major source of clock jitter that leads to distortion on the DAC output. Also, there is a audio clock (a MAX9485) buried under the expansion board that creates the mclk, bitclk and frameclk for both the MPC5200 and the DAC. Again, this goofy build-up leads to considerable noise in the system. Also notice that the amplifiers have been spliced in by connecting clip-wires from the output of the DAC filters to the input of the amplifiers. These wires sit under my fluorescent lights and pick ups several 10's of millivolts of noise. This too leads to considerable noise in the amplifier output.
Here is a picture of the entire system. There are four amplifiers in total (two per LM4780). One amplifier is connected directly to the tweeter (remember, our crossovers are in software). Another is connected to the midrange. Two are connected to the woofer in BTL fashion. The amplifiers are identical (non-inverting with 9.15 gain) but one of the signals has been inverted before it is sent to the DAC.

The process for playing music with this setup is as follows:

1. Booting Uboot. I boot the board by running picocom and then plugging in the 5V Phytec power supply. I hit a key within 5 seconds to get the UBoot prompt.
   

   picocom /dev/ttyS0 -b 115200
   

2. Boot Linux. At the Uboot prompt, I type the following command. This command has been setup on my Uboot environment to download the kernel via TFTP and then mount a file system on my development computer.
   

   run bcmd_net1
   

3. Set the Audio Clock. Before you can play any music, you have to setup the audio clock. I do this with the following command. This commands writes 0x22 to adress 0x68 on I2C bus 1.
   

   cd apps
   ./i2cset 1 0x68 0x22 0x00
   

4. Play an MP3. This has been documented before, but here it is again:
   

   madplay --output=wave:/dev/stdout some_mp3_file.mp3 | brutefir triamp.txt
   

5. Play Radio Paradise. Again, this has been documented before, but here it is again:
   

   route add default gw 192.168.1.1 eht0
   wget http://207.200.96.136:80/stream/1048 -O /dev/stdout | madplay --output=wave:/dev/stdout /dev/stdin | brutefir triamp.txt