DSO firmware version 3.64

[lygra]

@BenF

@tobey

If i cannot see everything on the screen, then this feature is actually useless for me. If i had to use panning i would not choose fast buffer at all.

Check out the paragraph in the guide called “Panning the full sampling buffer” for info on how to view the full buffer. This applies to all buffer priority modes.

I am surprised at the amount of feed-back this new “Fast” mode has generated. We aren’t being critical here, we are just trying to help to refine this great new feature a little bit. I tend to agree with tobey in that you usually give up scan triggering capability in exchange for a very slow real-time sweep. The “Fast” default scan mode sort of kills the real-time slow sweep advantage.

@BenF

@lygra

Maybe you cold take this one step further and offer “FastEqu” and “FastPost” in your next update. Even without this addition, the software is simply amazing!

When using the standard modes (Post and Equal) we collect the equivalent of 13+ screens of data whereas in Fast mode we only collect the equivalent of 1.3+ screens. As such the distinction between Post and Equal is much less significant and the objective is to avoid leaving empty areas left and/or right on the display.

Although there is less distinction between Post and Equal in “Fast” mode, the Fast Post mode would enable nearly twice the on-screen viewing area after the trigger as compared to the default Fast Equal mode (ignoring blank screen areas). From this perspective it would be significant if you can’t see a portion of the waveform that is just beyond the right hand edge of the screen. Once again I am not complaining, I am just trying to point out suggestions that would enhance the present capability. I hope you take all these suggestions as being constructive and not as being critical. We really appreciate the Fast mode.

@BenF

@lygra

I am a little confused about the new sampleDIV entry in the XML file.

The sampleDiv entry is used by the XML import utility to distinguish between fast and standard buffer modes. timeDiv is as in previous versions the T/Div we select on the Nano (used for display scaling) whereas sampleDiv is the actual sampling rate used during acquisitions. They will be different when Fast mode is used, but have the same value for Post and Equal modes. If you import XML files from previous versions, equality is assumed so that backwards compatibility is assured.

Now that you have explained, it makes good sense to the firmware. I was just seeing it as the inverse of the Samples/Div as viewed by a user looking at the XML data.