The DSO Nano obviously has a very limited bandwidth/sample rate compared to a desktop oscilloscope. Still I think most would agree that it serves us well for a range of practical measurement challenges (not to mention the form factor and cost). Then what if we double the sampling rate, would it really make a difference and is it practical to do so?
Current max sampling frequency for the DSO Nano is 857 kHz (not 1MHz as most people seem to think). The issue here is with the uC running at 72 MHz. Max speed for the ADC clock is stated in the uC datasheet as 14 MHz and the fastest ADC clock we can select (staying within specifications) is then 12 Mhz (= 857 kHz sampling rate). Reducing system clock to 48 MHz would allow for 1 Ms/s, but this would reduce overall performance accordingly and we may run into a number of timing issues. For most practical purposes I would argue that we need at least 10 samples per cycle, so with the current configuration we’re good to about 85 kHz only.
The uC supports a feature referred to as “dual fast interleave mode” which would allow us to double the sampling rate. That is, the two independent ADC cores will overlap one another and so effectively double the conversion rate. In V2 hardware, two GPIO’s pins are connected (PA0 and PA1) to allow for this. According to the uC datasheet however there is no real need for this as it is perfectly capable of sourcing ADC input from the same pin. Using the second pin (PA1) would limit this feature to V2 owners, but I don’t see any obvious reason (besides market differentiation) why we should do so (perhaps others do?). Implementing this in firmware would then increase bandwidth up to about 170 kHz.
Another choice might be to exceed datasheet recommendations and bump the ADC clock up to 18MHz. This should give us 2.57 Ms/s and a usable bandwidth up towards 257 kHz.
So back to the questions, are there any good examples of things we can (and need to measure) at 170k Hz or 257 kHz or are there issues with or alternatives to the above we should consider?
I would argue for the 170 kHz version, as exceeding the specifications may lead to degradation of the signal quality (I guess). I do not need to measure something particular with 200 kHz, but I would appreciate the higher time-resolution also for ‘slower’ signals.
The major limiting factor for using the DSONano at higher frequencies or faster rise and fall signals is the connector, probe, and the varying input impedance. The 3.5 mm connector and probe wiring is the main issue. Adding an adapter to a BNC and a standard scope probe only makes the impedance mismatch worse. This distorts the high frequency components of the signal being measured. Simply changing the input connector to a known impedance coaxial one does not change the impedance of the input circuit, which includes the PCB layout. The appx 100 to 200 kHz usable bandwidth is good for many applications. The main use of higher bandwidth would be for switching power supplies which have high harmonics of very short duration even at 50 kHz. One should used a scope (and probes) with >50 mHz bandwidth for analyzing these signals.
The DSONano is a great tool for many applications. The two most attractive features are the size and price. Trying to make the DSONano into a high performance oscilloscope will negatively affect these two features.
For those who really need, and know how to use, a higher performance scope, check out a Hantek DSO 1060. These are about $500-$600 on eBay and have all the features you could want in a small portable scope.
If the sample rate can be doubled without affecting performance (speed of navigation, etc) then by all means do it. Users need to be reminded that what they see on the scope at higher frequencies are greatly limited by the input probe and exactly how it is connected to the circuit being examined. Tektronix, Agilent, LeCroy and others have a large number of notes about this and all of them also apply to the DSONano.
As I write this, I am in Shanghai at a large manufacturing company’s Test Laboratories overseeing EMI testing of one of my employer’s products. I brought the original and V2 DSONanos and used them to verify the audio test signals. Almost immediately most of the test engineers and technicians crowded into the small test cell to look and try the DSONano. All wanted to know what mysterious American or European company it came from so they could buy one (they simply don’t believe the price I told them). I laughed and pointed to the writing on the back of the DSONano.
Perhaps a little viral marketing would help spread the word (along with mentioning that there are copies, which are not quite the same and are not supported or updated at all).
And last, but not least, as everyone has said already, Ben has done a remarkably excellent job of updating the firmware for this great product.
The 125KHz RFID industry is fairly big. I haven’t tested the latest BenF code yet but if it works as well as I expect, I know about a half dozen guys who will be ordering one within the week. If the Nano caught on in my industry, the sales would be huge. I’m not talking about the few hundred engineers who would want one in case they were ever away from their real scope. I’m talking about the thousands of semi-technical field install guys who could use a pre-configured one with a custom probe to work out where the best tag placement spot is by looking for the max field strength.
I’m not absolutely sure that doubling the sample rate is essential for this. It might be fine the way it is, but there’s no question that we’re hanging on right at the end of the usable sample rate now.
The comment made on RAM looks about right, but is for V3.11 and now we have an extra buffer for SD card IO (+512 bytes in APP) so there is even less. Also, a doubling would require an additional full 6k RAM which is far off. The DSO Nano is already stretched capacity wise and we can’t really afford such luxury as oversampling. Higher sampling speed would be useful for “high” frequency input, but offer no benefit to lower frequency input signals (for the Nano that is).
Also thanks to shazam for sharing his perspective on using the Nano.
I spent some time with the ARM Cortex uC datasheet and tested a few options for higher sampling speeds. The”dual fast interleave” mode turned out to be less useful than expected. To control sampling speed, I use a timer to trigger sampling at the optimal frequency for the chosen T/Div. This ensures a uniform distribution of sampling points along the time axis. In “dual fast interleave” mode however, sampling is no longer symmetrical. We get two samples close in time, then a delay, another two samples and so forth. Not really what we need.
To work around this issue, I opted to use two synchronized timer pulses with a half cycle overlap to trigger the two analog-to-digital converters (ADC1 and ADC2) independently. This worked fine and gave me the desired 2Ms/s rate. The actual quality improvement however was quite modest as it appears that other bandwidth limiting issues such as probes, connectors and analog conditioning circuitry come into play (see relevant comments made by shazam). To push it further still, I also tested with 4Ms/s (exceeding ADC datasheet recommendations for the Arm uC). ADC sampling accuracy didn’t degrade as much as one might expect, but it turned out that the uC would draw excessive power (significantly so) in this configuration. So not really useful and back to 2Ms/s with externally synchronized triggers again.
Quite happy with the 2Ms/s version I went on to test it further. In this configuration we use 32-bit DMA to transfer the samples from the ADC peripherals (two adjacent 16-bit registers) to RAM. At this speed however, it turns out that there are simply not enough bus cycles left to search for a trigger. That is, no issues with sampling at 2Ms/s, but not being able to search for a trigger at the same time. To see if optimizing the code further would allow for this, I tested with just trigger search (no house keeping or anything else running) and DMA transfer in a bare minimal configuration, but still no success. Also I tried to gradually reduce sampling speed, but even at 1.2Ms/s there were issues with the occasional lost trigger. Apparently, 32-bit peripheral DMA is not well implemented in this particular Arm uC. Doing alternate sampling and trigger search is for me not a relevant option (this is going back to the 2.5e way of sampling) so I decided to give up interleaved sampling at this stage.
In summary, I don’t really think we miss out on much as the quality improvement of the displayed waveform was very modest (a factor of 10 is probably needed to make a real difference). Also I’m assured that a claim of 2Ms/s being achievable with just a simple firmware upgrade is not well founded.
I’ve since tuned sampling speed up from 857ks/s to 1Ms/s. This is a modest improvement (16% or so), but then at least we get what the Seeed product pages claim. I will release this 1Ms/s update shortly along with a couple other improvements.
There’s nothing like the old “suck it and see” and I (we) appreciate not just the work but the detailed report.
I, for one, would be extremely loath to lose the current “on-line” trigger detection system. If that’s the limiting factor then so be it.
FWIW I’ve spent a fair bit of time playing with my Nano at 125KHz since 3.32 came out. The bottom line is that 857ks/s is enough to do most jobs fine and not even close to enough to solve other problems. A ‘leap’ to 2Ms/s in some kind of “grab buffer mode” wouldn’t gain much. Even keeping the current trigger detection system while moving to 1Ms/s is an “evolution” not a “revolution”.
The software for the PWM with the sweep is awesome but the biggest problem I’ve had is that the probe’s capacitance mucks up the measurements on tags with high inductances and high Q factors. It works great on antennas though. With a little experience I might be able to compensate for the detuning on the tags.
Why is another 6k RAM far off? I counted altogether around 10k, which leaves us 10k unused.
Thanks for testing out all this. Sounds like there is not much to hunt for in terms of performance. So we should rather come up with more features Personally I would prefer the current, reliable triggering to higher sampler rates.
BTW, what kind of development tools (sw & hw) are you using? Do you for instance use JTAG or emulators, serial printf etc?
RAM usage in 3.11 is about 17.2k. Current RAM usage is 5168 bytes in LIB and 12554 bytes in APP. This adds up to 17.3k out of 20k which doesn’t leave us with much to play with.
I’ve just used the Nano display for debugging. There is a Display_Info function that will put a string and a numeric value anywhere on the display and a WaitForKey function to pause.
I too really appreciate all the effort you have expended on this topic. Perhaps a good compromise (if compatible with the above improvement) would be the use of both ADCs in a single sweep acquisition mode (high speed scan) that requires no trigger (if that is possible). This would allow subsequent scrolling thru the capture buffer to see what is there even if no repeatable trigger stability is available. When not in this mode, then things would revert back to normal using the improvement cited in the quote above.
Now I’m confused:
Ben’s explanation regarding 2Msps does sound very plausible - but could it be, that “Paul” (or someone other) will get it running?
Does anybody own such a DSO (with connected AD-Inputs)?
Because I’m very impressed regarding Ben’s DSO explanations and programming knowledges (excellent job Ben!), I would wonder if somebody else will get it runnig properly.
What’s in your opinion: Maybe “relaeased later” does relate to the standard opensource firmware?
I don’t know.
You would need to hack the connection yourself, please understand the risk of doing so.
DSO Nano v2 is what we are selling. On ebay people might name it anything and we don’t want to check and stop them. You may buy from our distributors or online store, they are authorized products with our full support.
Personally I would prefer the current, reliable triggering to higher sampler rates.