NOTE: This post has been beat to death and has died. Reading this post will probably be a waste of your time. 13 Jan 2011
BenF
I have pondered this new feature for several weeks now, and have finally decided how to present this suggestion.
All DSO scopes have inherent noise and artifact issues that can be greatly reduced with averaging of repeating signals. With expensive DSOs, you can select the averaging rate (8, 16, 32, 64 …etc) and the screen refresh occurs at the end of each average cycle time with greatly improved signal to noise ratios.
One possible solution would include an additional resource requirement of a 300 byte alternate waveform screen buffer. This could probably be stolen from the capture buffer if necessary. I know this could get messy with binary numbers, so just steal 256 bytes and limit the screen updates to 256 pixels if necessary. The capture buffer would update the alternate screen buffer while in this mode. The CPU would sample the capture buffer, average that with the current value in the alternate screen buffer (using the cycle count), and then place the new result back into the alternate screen buffer. This would repeat for each new acquisition of a repeating signal. When the average cycle count is reached, then the CPU would move the alternate screen buffer contents into the display buffer to refresh the screen, and then clear the alternate screen buffer for the net go-around.
I don’t know; and it is quite possible that DMA is used to transfer the capture buffer to the screen buffer. If so, then that may be a show stopper, or the extra CPU time to byte transfer those 300 bytes may be insignificant.
By the way, this pretty much concludes my feature suggestions for the Nano.
If we take a step back and think of enhancements in terms of who will use it and for what purpose, we may have a better chance at getting it right. Is there a particular application you have in mind that is likely to benefit from the proposed enhancement?
My only goal here is to improve the Nano such that more applications can find it useful. This particular request has the potential to become a two-fer (two birds with one stone).
When there is a lot of noise on a small signal, then it is hard to measure the voltage levels of that waveform with a cursor. Such noise can be generated within the measured signal source or from the Nano circuitry itself, as has been discussed in previous posts. I considered this a general purpose feature that would increase the usefulness of the Nano and I felt that this feature deserved consideration on it’s own merit. If this is doable, then it also lays the groundwork for my final feature request, the ability to measure ripple on a large DC voltage. If this wasn’t doable, then my final request would never have seen the light of day. I don’t know which would get used more, the “averaging” or the “ripple on DC”, so I just started with the easier implementation request first.
As we all know, the Nano is incapable of measuring a small ripple on a large DC voltage, due to DC coupling. To do that well, the capabilities described for the averaging feature must also be incorporated. The difference would be that instead of just placing averaged results into the alternate display buffer, you would first offset and amplify the values and then average them and place this final result into the alternate display buffer. The offset could be created by taking the actual capture buffer value and subtracting a DC voltage value. Then multiply this resultant value with the positive gain factor (for each screen horizontal pixel such that it fills more of the vertical resolution of the display screen). If the alternate display buffer is not possible, then none of this can be done.
The offset DC voltage and gain could be user configured with menu options. When the user configured the gain factor, then the firmware would automatically adjust the display V/Div to match that gain factor while the signal input stage gain remains associated with the V/Div gain settings established before entering this mode. Exit of this mode would re-link the display V/Div with the proper input signal stage gain.
When measuring ripple on a DC voltage, there is usually an exact threshold of ripple tolerance that is involved. This averaging concept would increase the accuracy of the measured ripple which would better determine if the ripple is acceptable or not.
If anyone is capable of implementing these features, it would be you with your strong programming experience. The above is my only justification for this feature.
The following post (although I don’t understand all that is said) also describes an application of this feature in a way that I had not considered. Instead of just offsetting and amplifying a DC voltage, you could also offset and amplify any waveform including this squarewave signal to see that smaller signal riding on top, just as long as it doesn’t exceed hardware limits as you pointed out.
I’m not challenging you to justify the development (yet ), but rather consider a practical scenario we can verify ideas against.
Repeating waveforms may be the odd case rather than the norm and even when this is what we have, we’re likely to be more concerned with irregularities than the base waveform. Averaging will then smooth out irregularities and so may do just the opposite of what we need.
Bandwidth and sampling rate are obvious limiting factors and some form of improvement allowing us to lift or stretch this limitation is likely to be desired. As hardware goes we’re at max with 1Msa/s and using a real-time trigger. The other possibility we looked at was time-equivalent sampling, but the show stopper here is lack of a hardware trigger. That is, we can not precisely synchronize the cycles across multiple acquisitions.
Then what about software enhancements? A feature found on most high-end scopes is an implementation of the Whittaker–Shannon interpolation formula (or sin(x)/x). This algorithm will significantly improve the apparent signal quality (for repeating waveforms) with frequencies in the 100 kHz to 500 kHz range. I have a working implementation of this for the Nano, but as it is now it needs 70s to do the averaging/interpolation for every acquisition cycle. I’m sure this can be optimized significantly, but even if I get it to run 10 times faster (which may be unrealistic) it would still be 7s per acquisition and then it is more of an academic feature than a useful enhancement (this is typically supported through a special purpose DSP in DSO’s).
So what about plain averaging? We could do this with oversampling in a single acquisition cycle. Doing so however would come at the expense of sampling buffer depth (2x is ½, 4x is ¼ and so forth) and it would only apply to T/Div’s 100us (max 2x) and higher. If we want to do averaging across multiple cycles, we are again limited by the lack of hardware trigger for exact synchronization. This is not a complete show stopper when it comes to averaging, but it is a factor that would limit its usefulness. For numeric measurements we already do averaging across multiple cycles within an acquisition.
So is there nothing else we can do with the Nano’s then? I’m sure there is in a number of specific application areas, but probably less so for general purpose enhancements. For digital analysis there is a lot to be desired and a lot we can do. I’m not comfortable with dedicating time to this however, because I know the same effort would give 10 times the return on more suitable hardware. Audio is another area where we could do a lot more. Simple FFT analysis and dbV measurements are certainly within reach and possibly this is something that should be added. There is (was?) an ongoing interest for developing an audio firmware mutant, but with limited progress so far. A separate firmware might be preferred to take audio to its full potential and it may also be an option for other specific areas.
In a commercial competitive setting we would probably implement all of the above and then some. Buying decisions are often made on specifications alone (more is always better) and so arguing along the lines of what I do in this thread is really a waste of time. You have to give it to customers and let them see for themselves. For me this is my spare time and so priorities are different.
I failed to communicate that my term “averaging” should have been called “algebraic summation”. In my previous post I initially addressed your spare time as an issue, but then I withdrew it because I wasn’t sure if your-devoted-time was an issue or if potential-use-vs-difficulty-of-changes was the issue. I appreciate your concern-for and allocation-of personal spare time ownership.
Do you think the DC offset (without sampling) (to view a small signal riding on a larger DC voltage or waveform) would be a worthy and doable feature? If so, then I will create a new post topic for DC Offset, otherwise, it dies here and now.
Once again, we all owe you our respect and admiration for the many improvements you have already made.
Extracting a small signal from a DC offset would be easy to implement in software. Doing the same for any waveform (sinus, square …) is more of a challenge.
AC coupling is the preferred solution for eliminating a DC offset as we can then use the full ADC range for the ripple. With DC coupling (as is the only option on the DSO Nano) the full range includes the DC offset and so precision left for the ripple gets progressively less with an increase in DC offset. We can remove this offset in software, but not prevent it from limiting precision.
A good start may be to load an Xml export file into Excel, subtract the DC offset and then check to see if the remaining signal has sufficient precision. If it has, then adding a feature to aid with visualizing this ripple on the Nano would be useful.
Sounds good to me so I’ll get to that as soon as possible. I’ll present three separate runs of the data, one with just the XML data, another with just DC offset, and a third run with the DC offset results multiplied by a factor of 3. I will use Excel to create all three resulting waveforms.
If the results are significant, then I will post the results in a new topic. If the results are not significant, then I will post those results here.
Because we would be processing pixel values, I believe that the DC offset would not care if it is a sinewave, squareware or simple DC level; it only sees that data point’s value and not the entire waveform.
Subtracting a DC offset is OK, but if the ripple rides on top of a large amplitude sine wave (or square wave) it is more of a challenge to separate the ripple from the base waveform.
The Nano analog input conditioning circuit has 3 + 3 (3 for 1x and 3 for 10x) selections for base voltage range. These are mapped as 10mV-100mV, 200mV-1V and 2V-10V for the 1x probe. Tests are likely to be different (varying precision) across these base ranges, but similar/equal for T/Div’s in the same range.
), but rather consider a practical scenario we can verify ideas against.