Dejan,
I appreciate your enthusiasm for the Nano and sharing of ideas, but you also display all the signs of someone a bit immature with loads of unsubstantiated assumptions and a naive approach to technologies you don’t fully understand yet. I have some 20+ years of experience with commercial product development using related technologies and managing teams of engineers spanning multiple disciplines. You would be a fresh breath as a new team member in one such project group, but I also know that new members (especially talented ones) tend to be lost in pursuing ever changing ideas and never produce anything worthy of release to customers unless properly mentored. You seem to fit that profile well.
Although it may be of interest to a number of aspiring professionals, I can not take on entertaining implementation discussions along the lines of your posts. For this to be productive, you need a detailed overall design, a thorough analysis of constraints and an in-depth understanding of the technologies involved and how they relate to your design goals. This is too much to ask from anyone and so my choice is to keep this at the user level (what you observe and what you want to accomplish). As users, anyone’s opinion is valued regardless of specific competences or lack thereof and so we create an arena more accessible to the majority of Nano owners.
As for some of your assumptions that may leave users confused:
- We will never loose triggers. Triggers are processed in real-time from a circular buffer with no samples skipped or lost between buffer cycles or otherwise.
- Using DMA is more efficient than interrupt driven acquisitions by a factor of about 100 (due to context switching overhead inherent in interrupt based designs) and is the main contributing factor towards getting optimal performance from our Nano’s.
- Display refresh rate is exactly where we want it to be. For T/Div’s 100ms and above, display is refreshed in real-time (scan mode) and for full screen modes we’re only limited by the display width time span. Refresh rate (for high frequency waveforms) is intentionally limited to 100ms so that consecutive acquisitions do not appear as if they blend together (this would otherwise distort the display and make it difficult to read).
- A blink-of-an-eye (as the expression goes) is about 300-400ms for a healthy individual. For every single blink during acquisitions, we will loose track of 3 to 4 full acquisition cycles (4k+ samples each). Proper use of triggers on the other hand, will never miss a single sample.
- Every frequency range supported by the Nano is treated with equal importance as frequency to sample rate is maintained across the full range. We also have the choice of 1x or 10x sampling rate as well as normal/post priority to tune buffer usage and frequency response to match a wide variety of real-life requirements.
- Claims of being able to process samples at a rate of 100Mhz using a microcontroller running at 72MHz lacks any touch with reality whatsoever.