This was where I really started the project. It’s also the most fun part. :-)
The front panel: what you see is what you interact with
The first sketch of the front panel already gave a good idea of what I had thought the analyzer should do.
The audio XLR and TRS connectors for plugging in the device-under-test would be on the front-left, since those need to be easily accessible. There also has to be an “auto” button to measure everything in one go. (What exactly should that do, you ask? Details… to be decided later on. ;-)
The box will get an IP address, so some menus are for sure necessary to at least read the status and perhaps configure the Ethernet link. One button for that.
Most of the controls will be for the signal generator, as it will be hugely convenient to be able to dial in a specific setting and then debug the device receiving the signal. The analyzer is synchronized with the generator and is therefore quite automatic. The signal generator’s output is most likely going to be just a sine wave, so level and a frequency controls are in order, and sufficient. A frequency dial alone can be inconvenient for scrolling a long way, so two buttons next to it for going up and down whole octaves at a time will make it more accessible.
The signal generator’s output level setting should be straight-forward: decibels relative to some reference level. It just happens that there are a few different ways to define the reference level. There are at least two different yet common scales used for defining signal levels, the dBu standard and the dBV standard. dBu is used in “professional” gear, where signal levels are overall hotter to make use of the extra dynamic range afforded by it, and also because such devices have higher voltage power rails and therefore more headroom to work with. dBV on the other hand is used for cheaper devices that may even be battery-powered. The whole business of such reference level smells a bit old-fashioned, but since these are still commonly used, it should be possible to switch between them. I also found a handy web tool for converting signel levels from one scale to another.
It could also be very handy to be able to set a different custom level as the reference and measure everything relative to that; even better if you could use the current input level as measured by the analyzer as the reference, and it should only take a single button press to do it. Some way to quickly skip through common preset levels is also needed, for the same reasons as the frequency control needs buttons, and that gives the third button for the level controls.
On the right-hand of the panel is a rocker power switch on the bottom, and a wide-levered output enable switch in the same style as on the constant current loads I built earlier (and now I realized that I forgot to write a post about those.)
At this point I still had an empty spot on the panel, and could only think of spending the space for two less critical switches: a balanced/unbalanced I/O button and a bandwidth limit control. The idea with the bandwidth limit switch was to force the analyzer to use the lower 48 kHz sampling rate, with higher dynamic range and improved THD. To measure the distortion of >5 kHz signals it would still be necessary to enable the 96 kHz or 192 kHz sampling rates, but it could be useful to disable such automatic reconfigurations.
The balanced/unbalanced switch takes care of the level adjustments needed with the two different interconnects: simply grounding or muting one side of a balanced cable would reduce the signal level by half, causing a significant measurement error! This can be automatically compensated for by switching the analyzer to unbalanced mode.
At this stage I was sure enough of the practicality of the project, that I designed the PCBs and ordered and built them. I will write more about those in later posts. After verifying the general concept in hardware, it was time to decide on the final design.
Making it tangible
Again I went for Protocase to manufacture the enclosure, just because of the simplicity of their own cad design tool and the handy templates. With a little bit of good advice from Sebastian (check out his site for some really cool art!) I hacked together a more realistic design. The most important tip I got from Sebastian was: keep it simple. Even very simplified designs look awesome when they’re made into tangible objects. Typography should be simple but elegant (heh, maybe that’s still not my cup of tea) and emphasis should be on legibility and usability. So I kept it minimal.
Colors are hard; somehow I have no intuition of which colors or tones work well together, but I knew the LCD screen would be blue, and inverse colors often work well together. But should it be orange, or should it be yellow, light or dark, saturated or not… choices, choices!
This is also where the projects gets expensive – it’s much cheaper to make your own boxes out of wood or plexiglas, but these enclosures are really high quality and have a seriously professional feel! Even better, they’re very low-effort if your wallet can take the hit.
But when the postman arrives, it’s like Christmas all over again ;-)
That is definitely not the end of the process, but since you read it all the way here, have a treat. I really like it how the whole design turned out!
I think I spent weeks just selecting the right components for the front panel. Connectors were easy, I’m used to Neutrik jacks. Likewise the LCD display is a common part, it pays off to keep a good supply of those, and the prices are very acceptable when buying in bulk.
I must have pored over tens of shops just looking for knobs. It was so difficult to find good ones that we even considered making our own molds with Stijn. I don’t think I’m quite ready for that yet, but it would definitely be an option for larger production runs. Those that I used on the Protosynth I found first at Conrad, and later in different sizes at Das Musikding. The bigger sizes felt just right for this project. I covered them thoroughly with Plasti Dip, also to improve the plasticy feel of the plain knobs. The rubber paint gives them a very nice grip. The encoders are not both the same; I envisioned that the level knob would also be used to make a selection in the menus, so it should have a good stepped feel. After trying a bunch of different ones, I decided to go for Alps. The frequency dial is a smooth encoder from TT Electronics, and it requires medium force to turn, so that precise frequency adjustment is easy.
The buttons are Marquardt 6450-series from Mouser. I think Clavia also uses them in their synthesizers. The leds next to them are just 0603 SMD leds placed directly on the PCB behind the front panel, but I found out that Toby has a good selection of light pipes in practical sizes, and got a bunch of those. The light pipes carry the light so that it looks like the light is emitted from them, and they are also flush with the panel. This way the front panel PCB can be inserted in place very quickly without having to worry about the placement or spacers of the LEDs. The light pipes are short enough to stay in place by just pushing them through the panel.
On the back of the enclosure there’s just an Ethernet jack, USB jack (I still don’t know what to use it for – USB audio? In mono? Not very useful…) and a power jack. I also added a MIDI jack but it’s also an option for later use.
The insides of the enclosure are spiked with standoffs for attaching the PCBs. Sadly here Protocase made a small mistake and left out two standoffs on the front panel. I had to replace them with screws and spacers. Pity for the screws are now visible on the outside… I also still have to find some black self tapping screws for the XLR connectors.
The rubber feet keep the box steady on the desk when buttons are pressed, and even when the small but sturdy power switch is operated. The box is made of just two parts, the base and the cover, and the base is very thick and heavy; it’s 2.3 mm thick steel! The box is too heavy to lug around, but it feels very robust and reliable, which is definitely a plus.
Interfacing with a DAC and an ADC is not too exciting, but to make a complete device some other “small” features are necessary. The analyzer will need some serious DSP power to run reliably at 192 kHz and to calculate the long FFT needed for the spectrum analysis, and at the same time it would be nice to have sufficient connectivity for remote control of the system. It would be especially nice to be able to download the recorded and/or processed data, and to use the analyzer device as a high-quality but mono audio interface.
I’ve had good experience with the LPC series of microcontrollers, and the NXP LPC43xx was the obvious candidate for this purpose. It’s a dual-core design, with one ARM Cortex-M4F core with hardware 32-bit floating point support, and the other core is a Cortex-M0 that still runs at the same maximum clock frequency of 204 MHz. That’s a lot of MIPS/FLOPS to burn! The M4F could do the signal processing and interfacing with codecs, and the M0 core would take care of everything else.
I really like Ethernet and TCP/IP as an ubiquitous way to connect computers, and the LPC4333 has a built-in Ethernet MAC. It requires an external PHY (Ethernet line transceiver IC), and the PHYs seem to be only available in tiny QFN packages that take some skill to solder. Gotta learn that sometime, so why not now. The Microchip LAN8720A is again an obvious choice.
This application is going to need a lot of memory, much more than is available on the LPC MCU. The LPC4333 has a memory controller, and it should be easy to connect some SDRAM to it. The memory will be accessible by both cores, so the DSP core can write to it and the controller core can read the contents and send to the remote controller over Ethernet. Is the memory bus fast enough for that, and does the sharing between the two cores cause problems? We’ll have to see… The memory bus on this particular CPU is 16 bits wide, and a 192 kHz 32-bit audio stream will require about 1.5 MB/s of bandwidth to transfer to memory and back. Probably I will want to store more than that at the same time, but in any case the bandwidth of even just a 100 MHz (half the CPU clock frequency) 16-bit memory bus should be way more than sufficient. SDRAM requires some overhead for setting up the transfers and for refreshing the memory, but there should be so much extra headroom on the bus, that this should not be a problem at all.
The device should be capable of standalone operation (and I like having dedicated physical controls) so a frontpanel is a must. The 16 character, two row LCD display is a little bit small, but it’s easy to read and easy to program. After making some sketches of the data to be shown on the display it was clear that it could still work for this purpose. The most economical approach (in terms of saving design time) would be to use a dedicated MCU for the front panel controls, and drive the LCD directly from the main CPU.
USB and MIDI ports could be added too, the LPC is very flexible. But this application doesn’t really need those.
But look at the picture above! Even though the THD analyzer device is relying heavily on its DSP and analog performance, these parts appear as a very small part of the overall system. This seems to be a common theme in devices intended for hands-on use. Interfacing with external systems, and especially with humans, is quite expensive.
Having discussed the purpose and construction of an audio distortion analyzer with my friend Janne, the question he posed was clear: why couldn’t you build one simply with a high-quality DAC and ADC?
The main usage I could foresee for such a tool would be to measure other codecs, and perhaps some simple analog circuits. Most of the reasonably priced audio codecs are specified with a dynamic range of some 100-110 dB, and a THD figure of about -100 dB. The analyzer would have to be quieter and more linear than that, preferably with a dynamic range and THD of at least -110 dB. Are there any such codecs available?
Even then, would the analyzer be accurate? Would it be possible to say anything about the reliability of the meter circuit without any special (very expensive) calibration tools?
The above figure shows the major parts of the setup. A probe signal is first produced by software running in the THD analyzer, converted to an analog signal, and sent to the DUT. The DUT does its job, and the analyzer section records the result. Once enough data has been collected, the software filters the recorded signal with a notch filter to cancel the original probe signal, calculates the power spectrum of the residue, and finds the distortion peaks in the power spectrum. Easy.
Since both the generated and the recorded signals are known, it is easy to estimate the frequency response of the analyzer itself with a simple loopback connection. On the other hand it’s not so simple to tell if the amplitude of the generated signal is correct, but it can be calibrated to a sufficiently high accuracy even with just a cheap oscilloscope or multimeter. As a bonus it’s relatively easy to measure the total delay of the signal through the full signal chain, and also here the analyzer’s inherent delays can be measured with the loopback. Many audio codecs can run at 192 kHz sampling rates, which would allow measuring even high (audio) frequency distortion.
I’m only interested in measuring low-voltage electric circuits, not power amplifiers, so the codecs must be interfaced with analog circuits on the normal line levels. The analyzer hardware itself turns out to be just a simple audio interface without many thrills. But with which codecs?
The major high-end codec manufacturers are Analog, Cirrus Logic, AKM, and Texas Instruments, and after comparing their offerings two chips stood out.
Burr-Brown’s PCM1792A boasts an insane -132 dB dynamic range and THD+N of 0.0004%. Analog’s AD1955 was another option, but the PCM1792 datasheet has a nice-looking schematic for the output line amplifier.
The ADC would have to be either AK5388AEQ, which is a very high quality 4-channel ADC, or PCM4220 with a slightly lower spec. The AKM chip looked much more interesting, as it also came with nice schematics (that turned out to have errors in them) and the whole idea of using a 4-channel ADC to sample a mono input seemed sufficiently overkill to me.
Wait, what was that about feeding one input channel to a 4-channel ADC?
Since the DAC has two channels, these can drive the positive and negative lines of a balanced audio interconnect separately, doubling the maximum output voltage. Theoretically this also gives an easy way to double the dynamic range of the output. Each DAC channel is also balanced to maximize the dynamic range of the codec, but it seems that the best use for these is to drive a preamplifier.
The ADC circuit is only slightly different, but since the input amplifier is actually reducing the input signal level (from +-13V!) to a range the codec can work with, it is possible that the preamplifier opamps may contribute significant amounts of noise. To avoid this, two sets of opamps are placed in parallel. The noise from the opamps will be uncorrelated, which can be exploited to increase the dynamic range theoretically by -3 dB. The opamps on the positive and negative sides of the balanced interconnect also mix the same way, reducing the noise floor by another -3 dB. To make use of the 4 ADC input channels, the output of each opamp pair is fed to two channels, allowing the software to sum the inputs to reduce the codec’s noise floor (if it’s uncorrelated between the channels) by -3 dB. This looks too good to be true; it can’t be this easy.
In principle an unbalanced output can be produced by sending a zero signal on the negative output. And the input should be able to deal with unbalanced inputs too, as the negative side will just be grounded. Well, that may not work so well due to many reasons, but balanced lines are good enough to start with.
The software is trivial.
Let’s build it!
Audio effects and synthesizers are noisy beasts. In addition to the music signal itself, all electric circuits add their own touch in the way of characteristic distortion and noise floor. Sometimes you can hear the distortion when you wouldn’t want to, sometimes it’s exactly what you’re looking for. And if you just amplify the signal coming from an electric device enough, you can hear the quiet background hiss even when it’s otherwise silent.
Digital algorithms share the exact same limitations, just in a slightly different form. The achievable noise floor and distortion characteristic depend on the choice of algorithm and data format, which is why we keep pushing for higher bit depths and bit rates. 24 bits is better than 16 bits, 192 kHz is better than 48 kHz, right?
Sometimes it matters
Distortion is a measure of unwanted contamination in a signal. It’s usually measured as a ratio of the amount of error in the signal versus the signal strength. For example, 1% of distortion would mean that the signal differs by one hundredth from some “undistorted” reference signal. The human ear is a very sensitive instrument, and with a little bit of practice it’s easy to hear such differences.
It’s often easier to think about audio signal levels, sound volume, and sound pressure on the logarithmic decibel scale. The ear has a dynamic range of about 120 dB, meaning that the loudest sound the ear can take is 120 dB, a million times, louder than the most quiet sound that can be heard. 1%, or 1:100, is a relative difference of 40 dB. That’s roughly the difference between the sound of a jackhammer and your TV at home.
Now, certainly some kinds of “errors” in sounds are more annoying than others. Much of the sound processing industry is built around acceptable, or even preferred forms of introduced distortions (ever heard a distorted electric guitar, by any chance?). But regardless, usually it’s a good starting point to have a clean signal with the minimum of unwanted noises.
Since engineering is what it is, you always end up trying to get the most out of your circuits, so you have to know what you’re looking at. The device intended for measuring these characteristics of a device is called a “THD analyzer”, because it measures the Total Harmonic Distortion.
The THD analyzer consists of a signal generator and a signal analyzer. The basic scheme is that the analyzer produces a measurement signal, which is fed to the device-under-test (DUT), and the output of the DUT is passed back to the analyzer. The analyzer is designed to produce certain signals with very high accuracy, and it can also identify these signals very accurately in the input to the analyzer.
The combination of a signal generator and analyzer can be used to measure how the signal is changed by the DUT. The noise floor can be found by measuring the background hiss coming from the tested device. Distortion can be found and measured by looking for additional signals produced by the DUT in frequency bands where the original signal had nothing.
The figure above shows a generated audio signal at a frequency of 440 Hz on the left, and the result of passing this signal through an external device on the right. The upper row shows the signal waveform itself, but the naked eye cannot distinguish any difference in them. With the help of some FFT analysis, the more delicate details of the signal can be visualized, and the result is plotted in the form of a spectral analysis on the bottom row. The main signal appears as a tall peak (due to how FFT works, the peak has a wide “tail” on both sides of it, called the side lobes) and in the processed signal on the right two additional peaks appear.
In this case the peaks are located at 880 Hz (2*440 Hz) and 1760 Hz (4*440 Hz), so they are the second and fourth harmonics of the 440 Hz sinusoid. A THD meter measures the total harmonic distortion, so the THD figure is a sum of the strengths of these added harmonics.
The noise floor also appears in the bottom-right figure, and it defines the available dynamic range of the DUT by covering and hiding all quieter signals under it.
Since the signal generator and signal analyzer are really one and the same device, it is possible to remove the original signal from the processed signal. The residue consists of just the added distortion and the noise floor.
So technically what the THD analyzer really does is that it filters the signal coming from the DUT to recover this residue, and measures its amount.
Since these are the limiting characteristics of any audio circuit, measuring them will give a good indication of the quality and performance of such a circuit, in addition to making any kinds of issues visible and debuggable.