After completing the Tutorial on “Band Pass and Sample Rate” (link shown below) it is obvious that the real-time sample rate of the Nano is much more limiting than it’s analog bandwidth capability. Having this equivalent sampling function would greatly expand the oscilloscope capabilities for repeating waveforms.
The “B&K Precision Oscilloscope Guide”, listed below, pages 22 & 23 explains (in high level) the equivalent sampling process. This reference explains the use of a sweep ramp for the sample delay, but microprocessor timing delays could be easily implemented for this application.
I see two obstacles for implementation; memory storage for the equivalent samples, and incremental time delays smaller than 1us.
I would guess that the current memory sample buffer could be broken into two sections (and/or possibly expanded), with the real-time samples using one section and the equivalent time sample results using the other section. The screen display would use the equivalent buffer section. The incremental sample time-delay would be controlled by the microprocessor.
This is just food for thought for DSO Nano enhancement through firmware. Those intimate with the hardware and software can explain if this is possible or not.
Thanks for the reference. Here are some thoughts on how I think this would apply to the DSO Nano.
Hardware as explained in the document is quite old-school and somewhat of a hybrid. The DSO model uses digital circuitry for data acquisition with output to an analog CRT display. DSO’s today (including the Nano) use an LCD and so is digital all the way. Despite the design difference however, equivalent time sampling as a signal enhancement methodology would still apply.
The analog digital converter (ADC) used by the Nano Cortex uC is of the successive approximation type. Each sample point is converted to a digital voltage equivalent in 14 steps. One step is used for sample and hold (a capacitor is charged from the ADC input) and then another 12 steps is used to compare this to a reference voltage for a successively higher resolution value (12 bits). The remaining step is needed for housekeeping (prepare for next sample, move data to registers, trigger interrupts, trigger DMA and so forth).
The actual sample and hold time would represent the smallest sweep delay we could use. This suggests that we should be able to increase (equivalent) sampling rate to at least 14 times the current rate (14Ms/s) for repetitive waveforms. A complete sampling cycle would then be assembled from 14 separate, sequential acquisitions successively phase delayed by 1/14 of the actual sampling frequency. I don’t see and blocking issues in terms of time-keeping or RAM to do this and thus so far so good.
Unfortunately there is a show stopper. We need to synchronize the sweep to a fixed point of the waveform cycle (such as a rising edge). For this we would need the equivalent of a hardware trigger (e.g. an analog comparator) and this is missing from the Nano design. Without this synchronization, we will not be able to correlate the delayed sweep (the 14 stubs) to a position within the actual waveform cycle.
A related methodology used for signal enhancement is the Nyquist sampling theorem.
If we apply this technique, usable bandwidth could be increased up towards half the sampling frequency. This suggests that we could synthesize an accurate representation of input waveforms up towards 500 kHz. Implementing this however is a non-trivial exercise and it is still a somewhat modest enhancement. For someone interested in exploring the underlying potential however it may be a worthy case.
Thanks for your detailed response. The collection of sequential acquisitions was my major concern and that does not appear to be a show stopper.
Maybe this will help to clarify what I failed to communicate in my previous post:
The sequential acquisitions used to collect equivalent-time samples (14 in a row) would be delayed acquisitions of just one sample point and without display updates plus an equivalent-time-sample buffer write of that one sample point. The equivalent-time-sample acquisition itself (15th acquisition interval) would be another separate acquisition in all it’s own right but it would be missing the sample-hold-measure-store process of a normal acquisition. Instead this equivalent-time-sample acquisition would create a virtual edge trigger in the center of the equivalent-time-sample buffer and use the sequential acquisition’s sample-hold-measure-store collected data points located within the equivalent-time-sample buffer to complete that acquisition’s screen update.
My assumption was to use the sequential acquisition results to build an equivalent-time-sample buffer one acquisition sample point at a time, and then to display that equivalent-time-sample buffer after complete assembly of all the equivalent-time-sample data points. The real-time display updates would be disabled during the equivalent-time-sampling mode, and the display would instead be updated from the equivalent-time-sampling buffer much the same as if it were the real-time buffer; with associated trigger modes, centered trigger and trigger offsets to move the displayed equivalent-time sample waveform horizontally as required. If you can’t determine a trigger from this equivalent-time-sample buffer, then a virtual edge trigger could be created at the center of the equivalent-time-sample buffer to allow horizontal positioning of the waveform. The trigger mode could be forced to “Single” to prevent display jitter. When the operator presses “RUN” it would force the required 15 acquisitions to update the display.
I don’t completely understand how the software builds a real-time sample buffer with trigger features and maybe the trigger stability for repeating waveforms will be lost using this concept. But this is what I meant to communicate.
By the way, on a lighter note, how do you get the quoted author’s name in the quote banner header? I have struggled with no success.
Collecting the time shifted samples is not so much of an issue as we could run the acquisition for the total buffer capacity (14 chunks) and just insert a delay between chunks. This would time shift the samples incrementally and leave us with the data we need. We would then grab one point from each chunk and use this for the first 14 points on the display (no need for a 15th buffer). Then the next 14 points and so forth until we fill the screen (300 points).
Now lets pick the center point in the first chunk (this could be anywhere within the waveform cycle) as a reference point. The problem then is to find which point in the next chunk is the time-shifted successor to this point. We know it will be there, because each chunk is large enough to hold at least two or three full waveform cycles and we also know that all points within this second chunk will be time-shifted relative to the first chunk. We can not assume however that the center point of the second chunk is at the same (time-shifted) position within the waveform. This is where we need the hardware trigger. With this we could add a synchronization step so that each and every chunk is time shifted relative to the waveform cycle rather than just being time-shifted relative to the previous chunk.
P.S. If you use the Quote button rather than Reply, you will see the syntax for a named quote.
