标签: spectrum

Over the last couple of weeks, I have been having a lot of fun implementing a simple audio spectrum analyser using a pair of MSGEQ7 chips (designed by Mixed Signal Integration and purchased from SparkFun ). For the digital processing and control portion of the system, I'm using a chipKIT MAX32 microcontroller platform featuring a 32-bit MIPS-based processor from Microchip Technology running at 80 MHz.   The columns on my project have received quite a few comments, including one from Sree Harsha Angara (a.k.a. Mithrandir), a senior applications engineer in Bangalore, India, for Cypress Semiconductor. "My interest is piqued now," he wrote. "I'll see if I can get the front-end filtering running on my PSoC 4 Pioneer kit. Weekend project, here I come :)"   Over the last few years, several of my friends have told me I should start playing with programmable SoC (PSoC) devices from Cypress. In particular, the PSoC 4 looks rather interesting, with its mixture of programmable analog fabric (opamps, 12-bit 1Msps SAR ADC, etc.), programmable digital fabric (four PLD-based logic blocks), and a 32-bit ARM Cortex-M0 processor running at up to 48 MHz. I particularly like the 1.7-5.5V operation.   Anyway, Sree and I ended up exchanging several emails. I learned that he "works mostly on power supervision designs and almost any other customer designs that come my way." He takes "a personal interest in control theory, digital filters, and power electronics." He's currently writing a series of columns on PID controllers on EEWeb. He's "always crawling around EE Times," and he reads my blogs in particular "because of the fun projects." Ooh, he knows how to get my attention (LOL).   Eventually, Sree sent me an email saying, "Hurray, I finally got my hands on an audio splitter. I also got some time to get to the filter design and I'm pretty satisfied with it. A quick peek of the characteristic curves is as shown below:"     When I asked Sree whether these curves were theoretical or empirically measured, he explained: "I create these curves the old-fashioned way using Excel. The curves I show here are theoretical, but I generally make it a habit to perform a simple Excel simulation in the digital domain once all the nasty transforms and fixed-point bit shifts are done."   A few days later, Sree sent me another email saying, "It's Alive!" It seems that he used his PSoC 4 to create "an exact replica of the MSGEQ7 chip with its seven band-pass filters and peak detectors." He also sent me a link to link to this video showing his PSoC 4 accepting an audio stream, emulating a MSGEQ7, and driving seven LEDs.     Do you recall my blog from a couple of months ago about the 32-bit PSoC 4 dev board ? Since then, I've ended up with 41xx and 42xx versions of these PSoC 4 Prototyping Kits, along with a PSoC 4 Pioneer Kit, so I asked Sree if I could implement his design on these boards. He replied: "This implementation just uses one SAR ADC and the whole filter runs through a single interrupt routine. That being said, you need seven PWMs to drive the LEDs -- I basically use four fixed-function PWMs and the other three are implemented using UDBs (Universal Digital Blocks)." He also provided the following block diagrams.   Block diagram showing the analog functions used in this PSoC 4 design.   Block diagram showing the digital functions used in this PSoC 4 design.   Sree says we still have about 50-55% of the processing power free. Also, it seems that he's run across another really interesting method called the Goertzel algorithm for frequency detection. In his last message to me, he said: "I'm still chugging along with the Goertzel algorithm, but on first sight it's a lot more complicated than simple band-passes and I'm having some difficulty wrapping my head around it."   I, for one, have every faith in Sree, and I look forward to reporting on his progress with the Goertzel algorithm in a future blog. In the meantime, what do you think about the PSoC 4 devices?

Good grief! I wonder where time goes. It seems like only a couple of days ago that I was waffling on about my MSGEQ7-Based DIY Audio Spectrum Analyser . However, the sands of time have wended their way through the hourglass, as is their wont; the days have turned into weeks; and thus we find ourselves in the "here-and-now."   What can I say? I'm too young for all of this excitement (LOL). As usual, just to set the scene before we leap headfirst into the fray with gusto and abandon, let's first take a look at this short video to remind ourselves as to just how cool this looks in the real world.     Now, in this column, I'd like to share a few extra tidbits of trivia and nuggets of knowledge that I've picked up along the way. With regard to accessing the spectrum data from the MSGEQ7s, let’s start by reminding ourselves of the official timing requirements from the data sheet, as illustrated below.     As we see, a positive-going pulse on the RESET signal kicks everything off. This pulse takes a copy of the current peak detector outputs and stores (latches) the values. We then apply seven negative-going pulses to the STROBE input. Every time the STROBE input goes low, we can read the value of one of the bands on the DATA_OUT signal, starting with 63 Hz and working our to 16,000 Hz.   The DATA_OUT is an analog value whose magnitude reflects the value from the corresponding peak detector. This value can be read using one of your microcontroller's analog inputs. (Observe that the DATA_OUT signal is clamped to 0V when the STROBE signal is HIGH.)   When I originally purchased the MSGEQ7 chips, I looked around on the Internet to see if there was any sample code to start me on my way. In fact, I found quite a few different examples, each doing things in slightly different ways, but a representative version of the function used to read the spectrum data values from the MSGEQ7s might be as shown below.     Note that the names I use for the RESET and STROBE signals in my code are "ctrlReset" and "ctrlStrobe," respectively. As we see, we start with a positive-going pulse on the ctrlReset signal, and then we enter a loop to read the seven data values. Observe that the only delay that is explicitly defined occurs after the ctrlStrobe signal is driven LOW. According to the data sheet, the minimum output settling time is 36 µs, and some of the examples I found used this exact value, but in my code I boosted this up to 40 µs, just to "make sure."   To be honest I feel like an old fool (but where are we going to find one at this time of the day? LOL). I know better than to simply use someone else's code without thinking about it, but that's what I did, and it worked, so I might have simply left it at that, but...   ...as I was driving into work one morning, I suddenly got a "niggly feeling" about the width of the positive-going pulse on the ctrlReset line. From the data sheet, we know that this pulse has a minimum width of 100 ns. It struck me that all of the code examples I'd seen had been for an 8-bit Arduino Uno or Arduino Mega running at 12 MHz, but I'm running this on a 32-bit chipKIT MAX32 running at 80 MHz. Could it be that my pulse was too narrow?   I started off under the misguided assumption that the compiler would optimize and/or convert the "digitalWrite (ctrlReset, HIGH);" and "digitalWrite (ctrlReset, LOW);" function calls into low-level instructions that would be executed in a single clock cycle. On this basis, the width of the positive-going pulse on the ctrlReset signal on my chipKIT would be 1/80,000,000 = 12.5 ns, which would be way too narrow. Even on an Arduino, this pulse width would be 1/12,000,000 = 83 ns, which would still be too narrow.   But my system was doggedly working, so what was going on? In order to see what was happening in the real world, we hooked everything up to an oscilloscope. The results were as illustrated below:     Imagine my surprise to discover that the positive-going pulse width of the ctrlReset signal on my chipKIT was actually 800 ns. What this means is that "digitalWrite (ctrlReset, HIGH);" and "digitalWrite (ctrlReset, LOW);" function calls aren’t being optimized into low-level instructions. Instead, they are being executed as full-blown function calls, which involve things like pushing stuff onto the stack. This means that each of these high-level statements is actually consuming 800ns/12.5ns = 64 instructions. On the one hand I thought "Wow! That is really inefficient." On the other hand, I thought, "Well, at least my pulse is wide enough."   But now look at the reset-to-strobe (trs) time. From the data sheet, this has a minimum value of 72 µs, but the measured value is only 800 ns, which is only approximately 1% of the required value. The MSGEQ7 is obviously a fairly robust little chappie; in fact, it's amazing that it worked at all. Even though it did work, however, I decided to add the appropriate delay as illustrated below (once again, I added a couple of microseconds for safety's sake).     At 49 µs, the low-going ctrlStrobe pulse width (ts) exceeds the minimum specified value of 36 µs. But look at the narrow high-going pulses on the ctrlStrobe signal. Since the minimum strobe-to-strobe time is specified as 72 µs, these high-going pulses should have a minimum value of 72 - 49 = 23 µs. However, their actual width was only 800 ns (the delay associated with the combination of the "digitalWrite (ctrlStrobe, HIGH);" statement at the end of the loop followed by the "digitalWrite (ctrlStrobe, LOW);" statement at the Beginning of the loop), which is only around 3.5% of the desired value. Once again, even though the original code did work, I decided to add another delay as illustrated below (as usual, I boosted this up somewhat to give myself some "breathing room").     The final code for the "readMSGEQ7s()" function I'm currently using is shown below. You will observe that this includes a simple noise filter in the form of the two instructions highlighted in yellow.     The thing is that even when no music is playing, you tend to get low-level noise when you read the DATA-OUT signal. In turn, this causes the LEDs to flicker, which you don’t really want between tracks. I played around a little and determined that removing anything below a value of 50 worked rather well, but then I changed this to a value of 42 (the answer to "life, the universe and everything") on a whim.   Last, but not least, speaking about noise, I was looking at some code created by my chum Steve Manley for use with his MSGEQ7-based system when I noticed that he'd read his DATA_OUT value twice and averaged the two values. In the context of my code, and just considering the left channel, this would look something like the following:     When I asked Steve why he'd done this, he said that he'd heard that this was a useful technique to mitigate against unwanted noise on the DATA_OUT signal. In fact, Steve said he's actually seen people averaging four samples (as shown below) and even eight samples (which seems to be overly enthusiastic, if you ask me).     Since I'm always "game for a laugh," I ran a few experiments comparing the results from using one, two, and four samples. I looked at both the LED displays and the corresponding numerical values -- and I really couldn’t see much difference, so I returned to using a single sample. However, I would be very interested to hear your thoughts on this. Have you seen this technique being used or used it yourself? Are there any situations when one really should make use of multiple samples in this manner? As always, I welcome any comments and questions.

Well, I'm pleased to say that things are bouncing along with regard to my Bodacious Acoustic Diagnostic Astoundingly Superior Spectromatic (BADASS) display project. As I discussed in this blog , the plan for my first-pass incarnation of this project is to use an Arduino Mega microcontroller platform to drive the display itself. One reason for this is that I'm using Adafruit's NeoPixel strips , and the folks at Adafruit provide a really nice NeoPixel software library for use the Arduino Uno and Mega. Meanwhile, a second device -- either a microcontroller or an FPGA -- is to be used to perform the digital signal processing (DSP) on the incoming audio stream to extract the spectrum data.   As part of my first-pass realization of this project, I opted to use a chipKIT MAX32 to process the audio data stream. This little beauty boasts a 32-bit processor running at 80MHz along with 512 Kbytes of Flash and 128 Kbytes of RAM. The illustration below provides a high-level view as to how this is all going to fit together.     My original plan was to implement some DSP algorithm like a Fast Fourier Transform (FFT) on the chipKIT, but then my chum Steve Manley -- a self-described lover of anything to do with flashing lights -- told me about the MSGEQ7 7-band graphic equalizer chips you can purchase for only $4.95 each from SparkFun.     This really is a very clever little device. Inside there are seven band-pass filters tuned to 63Hz, 160Hz, 400Hz, 1,000Hz, 2,500Hz, 6,250Hz, and 16,000Hz. Each of these filters has an associated peak detector. The clever thing is that the outputs from the seven peak detectors are multiplexed together, which explains how everything fits into an 8-pin package.     Everything is controlled by two digital signals: RESET and STROBE. As shown in the waveform diagram below, a positive-going pulse on the RESET signal kicks everything off. Although the datasheet doesn’t actually say so, my impression is that this pulse takes a copy of the current peak detector outputs and stores (latches) these values. We then apply seven negative-going pulses to the STROBE input. Every time the STROBE input goes low, we can read the value of one of the bands on the DATA_OUT signal, starting with the 63Hz value and working out way up to the 16,000Hz value.     The DATA_OUT is an analog value, whose magnitude reflects the value from the corresponding peak detector. This value can be read using one of the chipKIT MAX32's analog inputs.   Actually, I recreated the timing diagram shown above from the original datasheet. If you read the comments associated with my step-by-step construction guide , you will see a question by David Ashton. David points out that, as the minimum strobe pulse width of 18µs is less than the minimum output settling time of 36µs, this implies that you can read the data even after the STROBE signal has returned to its HIGH state. Based on this, David notes that you could actually read the data during the "purple times" in the above diagram.   If this were to prove to be correct, then -- based on the timing specifications in the datasheet -- a better representation of the timing relationships and waveforms would be as illustrated below.     Since it's not possible to make a definitive decision based on the existing datasheet, I talked to John Ambrose at Mixed Signal Integration -- the company that makes the MSGEQ7 (along with many other interesting products). John confirmed that applying a positive-going pulse to the RESET signal does indeed latch the current frequency values.   John went on to explain that the DATA_OUT signal is clamped to 0V when the STROBE signal is HIGH. This has several implications, including the fact that you cannot read the data when the STROBE signal is in its HIGH state. Also, this means that the minimum strobe pulse width ("ts") really isn't 18µs; instead, it's equal to the output settling time ("to") plus however long it takes for you to actually read the sample (let's call this "tsr" for "sample read time"). Based on this, the definitive timing diagram is actually as shown below.     With all that behind us, the following illustration reflects the additional components we need to make things work. In the original datasheet, the value of C2 is shown as being 0.01µF, but I ran across an application note somewhere that said it was better to use 0.1µF, so that's what I did.     I used two MSGEQ7s -- one for each (left and right) audio channel. If you wish to use a single device for both channels, you can employ the circuit variation shown at the bottom of the above illustration.   As soon as I'd wired everything up on a breadboard, my first experiment involved feeding music from my iPad into an external amplifier and into my breadboard. I created a simple program that looped around reading the outputs from the MSGEQ7s and writing their numerical equivalents to a serial I/O window on my notepad computer (a cheap-and-cheerful machine that I picked up from my local technology recycling store just to program my Arduinos and chipKITs).     Once I was confident that my MSGEQ7s were working as expected and that I could access their spectrum data, I added 14 LEDs (seven for each channel) to my breadboard as illustrated below.     Just to make things a bit more interesting, I associated red LEDs with the two lowest frequency bands, yellow LEDs with the two highest frequency bands, and orange LEDs with the three middle frequency bands.   All I'm doing at this stage is to use the numerical value (0 to 255) associated with each audio band to feed a PWM (pulse-width modulated) output that is used to drive the corresponding LED. You can see the result in this video , which I just uploaded to YouTube.   Actually, there are some interesting "gotchas" associated with all of this, but those are outside the scope of this brief overview.  

安立公司推出新型手持式频谱分析仪，其性能高达 43 GHz，史无前例.第 7 代 Spectrum Master 具有最佳的动态范围、DANL 、相位噪声和扫描速度，还配备有触摸屏和高达 20 GHz 的跟踪信号源. 安立公司 （Anritsu Company）推出了世界上性能最佳的手持式频谱分析仪 —— Spectrum Master MS2720T 系列。 MS2720T 具有触摸屏、高达 20 GHz 的全频段跟踪信号源以及动态范围、DANL（显示平均噪声电平）、相位噪声、扫描速度方面的最佳性能，从而为现场技术人员及工程师提供可与台式频谱分析仪匹敌的性能。而且，其频谱监视、隐藏信号检测、射频/微波信号测量以及微波回程测试和蜂窝信号测试性能达到了史无前例的水平。 安立推出新型手持式频谱分析仪 Spectrum Master MS2720T提供 9 kHz至 43 GHz 的连续频率范围。它具有更优的扫描模式，用户可将分辨率带宽设置成从 30 kHz 至 10 MHz之间的频率值，且对扫描速度的影响极小。由于 30 kHz RBW的扫描速度与 10 MHz RBW的扫描速度几乎是相同的，灵敏度则可以任意选择，而不需要很长的扫描时间。为实现最大的灵活度，可将扫描触发设置为自由运行或单次扫描。零频距下，扫描可自由运行，也可设置当信号符合或超过指定的功率时再触发，或者可被外部触发。 除了零频距之外，还可将频距范围设置为 10 Hz 至 9、13、20、32 或 43 GHz。 MS2720T 的动态范围大于 106 dB （在 1Hz RBW 时），DANL 为 -163 dBm（在1 Hz RBW 时）， 在1GHz 载波且偏置频率为10 kHz 时相位噪声为 -112 dBm。史无前例的测量能力为这些最佳的测量规格锦上添花。突发检测扫描模式每次可捕获周期短至 200 微秒的发射信号，从而可以轻松发现间歇性或突发性信号。Burst Detect 扫描模式在 15 MHz 频距范围内的扫描速度可提高 1000 倍以上。 此外，该产品系列还可提供覆盖范围从 100 kHz 到 9、13 或 20 GHz 的全频段跟踪信号源。该跟踪信号源可提供竞争对手的手持式分析仪所不具备的先进功能，包括功率步长为 0.1 dB、高达 100 dB宽动态范围及功率输出平坦度为 ±0.5 dB。跟踪信号源还包括一个用于测量固定频率组件的连续波 (CW) 发生器。 一个先进的 8.4 英寸的触摸屏用户界面已被整合至 Spectrum Master MS2720T。 有新触摸屏以后，用户可以为任何菜单按钮或文件添加快捷按钮。因此，只要一按触摸屏便可以重新调用安装文件。 MS2720T 拥有全面的干扰测量功能，包括能够显示历史事件的瀑布图，这样就可以轻而易举地定位间歇性干扰。信号强度测量结合定向天线便可以更轻松地找到恶意发射器。和所有的 Spectrum Master 手持式频谱分析仪一样，MS2720T 拥有对场强、信道功率、占用带宽、邻信道功率比 (ACPR) 及载波干扰比 (C/I) 进行测量的单键智能测量功能。 MS2720T提供了 6 种选项以针对世界上主要无线通信标准的测量，比如 LTE FDD/TDD、GSM/GPRS/EDGE、W-CDMA/HSPA+、TD-SCDMA/HSPA+、CDMA/EV-DO 及WiMAX 固定/移动。 其他能力包括针对 Electro-Magnetic Interference (EMI) 的测量，与 Anritsu 公司的 EMI 探测套件结合使用，可帮助工程师确诊 EMI 问题，这样就可以低成本方式“预检”很多问题，从而缩短产品上市时间。 为现场使用而设计的 Spectrum Master MS2720T 有耐用的外壳，能够经受户外的极端温度及环境。重量因型号而异，介于 4.4 kg (9.7 lbs.) 与4.9 kg (10.7 lbs.) 之间。所有型号的尺寸均为315 x 211 x 94 mm (12.4 x 8.3 x 3.7 in)。 Spectrum Master MS2720T可在接到订单后 4 至 6 周交货。 《电子设计技术》网站版权所有，谢绝转载