标签: analyser

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.

A few weeks ago, my friend in Sweden, Sven Andersson, sent me an email. Sven is busy working on his Zynq Design From Scratch blog series. He informed me that he's already posted Part 43 , in which he talks about debugging his designs using various techniques, including simulation and virtual on-chip logic analyzers.   This is of particular interest to me because Sven devotes a large portion of this blog to the LogiScope logic analyzer from Oscium.   Oscium's LogiScope logic analyzer for iPods, iPhones, and iPads.   This little beauty transforms your iPod, iPhone, or iPad into a 16-channel 100MHz logic analyzer. "The LogiScope logic analyzer is very easy to set up and use," Sven wrote in his blog.   I'm so glad he likes it, because l love mine. It's the perfect complement to my iMSO-204 mixed-signal oscilloscope , which also comes from Oscium.   Oscium's iMSO-204 mixed-signal oscilloscope for iPods, iPhones, and iPads.   If you are planning on designing with a Zynq, or if you are interested in using your iPad as a logic analyzer, Sven's blog is the place to go.

My friend Sven Andersson in Sweden sent me an email several days ago. Sven is busy working on his Zynq Design From Scratch blog series. He informed me that he's already posted Part 43 , in which he talks about debugging his designs using various techniques, including simulation and virtual on-chip logic analyzers.   This is of particular interest to me because Sven devotes a large portion of this blog to the LogiScope logic analyzer from Oscium.   Oscium's LogiScope logic analyzer for iPods, iPhones, and iPads.   This little beauty transforms your iPod, iPhone, or iPad into a 16-channel 100MHz logic analyzer. "The LogiScope logic analyzer is very easy to set up and use," Sven wrote in his blog.   I'm so glad he likes it, because l love mine. It's the perfect complement to my iMSO-204 mixed-signal oscilloscope , which also comes from Oscium.   Oscium's iMSO-204 mixed-signal oscilloscope for iPods, iPhones, and iPads.   If you are planning on designing with a Zynq, or if you are interested in using your iPad as a logic analyzer, Sven's blog is the place to go.

For my 8th grade graduation  (in the Catholic school system that's a milestone like finishing middle school), my dad gave me a Devry scope and VTVM combination. He had assembled the unit a few years earlier as part of a mail-order course in electronics. VTVM stands for "vacuum tube voltmeter," a long defunct phrase that described a high-impedance VOM (volt-ohm meter). The device was about 19" wide and maybe 25" deep with quite a few tubes. There was no case, and it's amazing I never broke the exposed CRT. The scope didn't have a trigger; in that tube era, trigger circuits were expensive, so it, like many others, had a free-running time base one adjusted in an attempt to stabilise the on-screen image. The unit served me well till late high school when I managed to save enough to buy and build a transistorized (though still with CRT as TFT screens were decades away) Heathkit scope. Both of those are long gone, and there have been many more scopes in my life over the years. Favourites include Tektronix's 7000 series of modular scopes. The high-end units we used in the 70s were fantastically expensive, had tiny little push buttons, and for the time offered unbeatable performance. The old Tek 545 I had for a while was a monster. It probably weighed 100 pounds, used vacuum tubes, but just ran forever. No one wanted it when it was time to move on, and I regret having to send it to the dump. For the last 15 years my main instruments have been Agilent units; the MSO-X-3054A that now graces my bench is a fantastic unit they'll have to pry from my cold, dead hands. In recent years some low-cost alternatives have come out. Rigol and others offer what appear to be fairly decent models in the half-a-thousand dollar range and less. Even Tek has some low-end sub-$1k units. I've not played with these but am very impressed with the specs versus cost. A lot of money can be saved by using a PC for the front end, and I've reviewed quite a few of these very inexpensive USB-based devices. Some are scopes; some logic analysers, and some a combination of the two, often with other features as well. The folks at Embedded Artists (a great name for a company) in Sweden sent one of their LabTool products, a scope/logic analyser/protocol sniffer/waveform generator. It isn't boxed; it's just two stacked and exposed boards as in the following picture. The LabTool Logic analyser "probes" (a wiring harness) are supplied, sans clips, but no scope probes. This is all not surprising considering the price: just 99 €, or about $135 at November 2013 exchange rates. That's a fantastic price. This unit is a little different than most of the others I've reviewed. There's no fancy FPGA sucking in data at high rates of speed. Instead, the unit uses a fast LPC4370 MCU, which has a Cortex M4 and a pair of M0s. Digital and analogue data is just sampled by the processor. Here are the specs: * 11 channel logic analyser that can run at up to 100 Msps. * 2 channel oscilloscope that runs to 80Msps with a bandwidth that varies between 3 to 12MHz depending on the channel's gain setting. * The digital and analogue channels can be turned around to generate signals. * It will decode SPI, I 2 C, and UART signals. * The digital zero vs one limit is 3.3V. But you can connect an external voltage source to change it to any value between 2.4 and 5.5V. As with most of these products, the sample rates depend on a number of factors. It can be as low as 20 Msps if both analogue and digital data is being sampled. The 47 page user's manual, downloaded from their web site, is the most complete and well-prepared I have encountered for one of these USB instruments. It was written in Sweden, though, and the English is rather imperfect, but is understandable. You have to read the manual before using the instrument; the UI appears very simple, but there's a lot of hidden functionality. Triggering is not extensive: the unit supports normal analogue triggers, of course (we can say "of course" now, as it uses millions of transistors, not the 15 or twenty tubes of my Devry unit fifty years ago). Digital triggers are limited to edges (positive or negative) of any channel; if multiple channels are selected the trigger is the logical OR of them all. No patterns are supported. The user interface is simple and clean, and the screen updates very rapidly. It generally does a good job at issuing detailed prompts when an incorrect selection is made. The unit will generate two channels of analogue data. Triangle, sine, and square waves are supported. It is also possible to create quite complex digital patterns on all 11 channels, but I was not able to make either them or the analogue outputs work. No doubt there was some button I didn't press. Both the Windows code and the firmware is open source. I looked at some of the embedded code and it seems quite well-written. The schematic, too, is available, though one has to register the unit for access. One surprising feature is a calibrate mode for the scope. You'll need a good DVM. And there are a pair of variable capacitors for each analogue channel to compensate their input impedance. This is the first time I have seen this feature on one of these scopes. (Normally, one compensates the probes, so I wonder if this feature is for those using low-end probes, or maybe just hunks of coax.) The calibration is stored in EEPROM. The schematics show a very-well designed analogue front end. There were a couple of odd behaviours. I went into calibrate mode and then closed the window without performing a calibration. After that the unit would no longer capture data, issuing a cryptic CMD_STATUS_ERR dialogue box. The fix was to restart the Windows program. I got one error for overrunning the buffer while sampling at high speeds, but was not able to repeat that. Occasionally the USB connection would drop, requiring me to disconnect the cable and then reconnect; the UI would then recognise the instrument. There are a lot of other USB instruments that offer more functionality than available from the LabTool. Two features, though, make this a compelling choice. First, is the incredible price. Then there's the open-source code. One could enhance the product, change features, add more protocol analysers, and maybe even turn this into a data logger. Fiddling with the code would be a nice way to learn about working with embedded systems.  

Every day I am astounded at the versatility and uses of oscilloscopes ( aka cathode-ray oscilloscope or digital storage oscilloscope ) as well logic analysers and a range of ancillary tools such as logic analysers and function generators. Normally associated with hardware debug such tools are also in a variety of ways in software debugging as well. But the best way to understand the capabilities of any system – hardware or software – is to do a tear-down. Normally this is something developers do when they are tasked with building some device or system for some market or design need: find a similar device and take it apart and see that others did to make it work. I think a similar strategy is useful in evaluating and using the tools and better yet. Better yet, once you understand the principles at work from study and use: build one yourself. That is what the authors of " Create a DIY scope/logic analyser " have done: using a programmable SoC, they have built much of the functionality of a standard off the shelf oscilloscope into just a few components. Although they have squeezed a lot of capability out of just a few components, it would be interesting to see how it compares to traditional factory-made alternatives.