DSO firmware version 3.64

After having flexed this new firmware muscle, I must say I am very happy with these improvements. The User Guide didn’t specify so I tested to see if the “Pri Fast” used “Pri Equal” or “Pri Post”. I found that “Pri Fast” uses “Pri Equal”.

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!

I am a little confused about the new sampleDIV entry in the XML file. Other entries indicate some unit per DIV such as time, voltage, etc. This sampleDIV entry appears to be the reciprocal of the samples per division (200us as an example). Was this an oversight and it should be samples per DIV (5000 as an example)? Or is there some other use that I haven’t considered?

Thanks again BenF for all your excellent programming accomplishments with the Nano.

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.

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.

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.

Well unfortunately i cant pan the buffer in somewhat of milliseconds. 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.

Cheers
Toby

ohh my gosh ben you are the man- i cant thank you enough for what you did with the 3.6 software, amazing, the update rate on fast buffer<ohh yea the pulsewidth measurement for both positive and negative, the thing about that is so great is that the resolution on the pulsewidth is perfect and the accuracy is right on and its very fast to update…gotta say it again–> your the man!!!

Hi,

when i set 1v/div; 10s/div; vert -6 and gpos 70 i get the wrong voltage. I put on 12v but it shows somehwat of 4.5v :frowning:

Is it a bug or a feature? :smiley:

Is there a chance to get 25s/Div in the next version, this would equal 1pixel per second.

I would say neither.

You can read the paragraph on “Voltage Range and Sensitivity” for an explanation.

I have a constructive suggestion for this firmware release. After using this feature for some time, it seems bothersome for the REF waveform to follow the config changes that are applied to the primary capture buffer. This prevents moving one in relation to the other (vertically and horizontally) for closer examination.

Another negative aspect of this coupling of the two display signals is that it appears that the last one loaded, forces it’s capture settings onto the previous one loaded. When the two waveforms are synchronized to the same trigger point but not on the same time domain or amplitude domain, then this presents a problem for comparison purposes.

If possible, it might be better for the Ref waveform to retain its own XML configuration. I can see potential technical problems with this suggestion and it may not be possible, only you can determine that. It would require redrawing the two buffers at different T/Div, V/Div, Gnd Pos, and Vert Pos; and I don’t know if this is possible in the firmware.

I think that this would make this feature more powerful if it is possible.

Thanks for the consideration

Possibly yes, but I think this is what we want when trying to match two waveforms exactly. Say we set out to tune frequency, amplitude or both. When the live channel overlaps the reference completely, we know we’re good. One example would be checking ignition between different cylinders or between different engines of same make and model. Loading a reference will also configure the Nano appropriate for such measurements and this is a popular request from the past. With coupled waveforms we can also change V/Div and T/Div as we please and still compare.

I’m struggling with this one. Current behavior is so that both waveforms (irrespective of loading sequence) will honor the active choice of time and amplitude scaling at all times. Are you suggesting it is not or that you wish for it to be different?

I don’t see any implementation constraints related to this so not really an issue. In terms of independent vertical/horizontal positioning I think you may be on to something, but I don’t quite see a need for independent V/Div and T/Div adjustments. I’m however more than willing to listen, so perhaps you want to enlighten me as to why I would want this?

Yes, I understand that it is currently working as designed, and I would like it to be different.

When you compare a small amplitude signal with a large amplitude signal (with same timedomain), then the small signal gets much smaller to keep the larger signal within limits. If we could keep the Ref XML parameters then the small signal would be unaffected and would remain large enough for viewing and comparison.

From my perspective it is better to have a small offset (user created) so that both entire waveforms can be viewed and compared simultaneously, although I must also agree with your overlap perspective. Allowing the REF waveform to retain it’s XML parameters would provide both methods of viewing, in addition to retaining V/Div differences when they are largely different between the two waveforms.

Thanks

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.

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.

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.

we must drive benf crazy- he’s probably sitting at his computer saying “no no no, why do they have to do this to me” :laughing: im with lygra on the fast post trigger… good deal on the save and recall buffer where you can pull it up with the nano its self

Being critical is just fine as long as you’re prepared to get challenged back. I’m way too stubborn to take that personally, but I have a genuine interest in what users really want and for what purpose (this is what I learn from). It is always better as I see it to first focus on what we want to achieve (irrespective of constraints) and for what purpose rather than how. This also has the added benefit of creating an arena where anyone’s opinion counts irrespective of specific competence or lack thereof. When the objective is clear, the how’s will come naturally.

The fact that a feature has limited application in one context does not rule out other uses. As such both fast mode and scan mode offer distinct values. It is my understanding that tobey is looking for a way to detect missing pulses and if that is the case we should probably be discussing pulse triggers rather than forcing a possibly inferior solution to this problem.

In terms of what you agree to, it is my understanding that tobey wants the exact opposite – a very fast real-time scan mode.

Provided we also shift the trigger position left, this makes sense and so I will look into this.

As I see it, comparing for equality would be the typical usage for a reference waveform (with a live second channel, this is likely to be different). Being able to size and position the reference in both the time and voltage dimensions would add flexibility. I have no reservations with respect to this argument. This does come at the added expense of complexity however in that we need additional controls for T/Div (if you really want to change the time domain), V/Div, Trigger Pos and Vert Pos related to reference. We would also need to consider cursors (V1, V2, T1, T2 and Trigger Pos) as these can apply to only one set of domain parameters. Still I think there may be ways to solve all of these issues if there is consensus that this adds real value to real problems.

More important perhaps is that we should not change the default behavior in such a way that typical usage is obscured and this is where I struggle to see where you want to go with “retaining XML parameters”.

Don’t think for a second however that I do not appreciate the ideas however challenging they may be.

Does this pulse trigger work, when i have a signal that is not a squarewave and the freqency and voltage changes?

This is the tobey statement that I was referring to. tobey does have more than one agenda and I don’t quite understand some of it, but I was referring to the fast scan as being less than optimum for typical use of that scan feature. If the Scan mode honored the Fast option selection, then the user can decide how to use Scan. It is very difficult to communicate successfully in this one-way forum medium (without immediate feed-back to confirm understanding) and that is why these posts can get frustrating at times for all of us.

That statement caught me off guard. Now I think I understand what you were considering and that I was missing. It sounds like you are saying that in Fast Post, a portion of the left half of the display could be blank and I hadn’t considered that. I guess we have come to the cross-roads of user capability versus complex functionality. I would quickly realize that when Fast Post leaves the left side of the screen blank, then I would just use the trigger position to slide the whole display to the left as required. A user with less knowledge base might consider the blank screen area as a problem or bug. It sounds like you are considering sliding the trigger position to the left of the screen to protect the less qualified user and that certainly has it merit. Explaining this situation in the User Guide would be another option.

Maybe I can improve my communication here. My examples referred to a common time domain which has the T/Div the same so I don’t see a need to make the time bases independent. I may have indicated that in an earlier post but have since decided that it is unnecessary complexity.

As far as default program behavior is concerned we could never change the REF waveform before, so keeping the V/Div fixed to the loaded XML parameter is not a change in behavior of the Ref waveform. The Ref waveform following the T/Div would in fact be an advantage such that both waveforms could be stretched simultaneously for closer examination for differences.

As you have indicated, cursors for the Ref waveform would not be necessary for a common T/Div.

Vertical position offset is most useful whereas horizontal offset provides little if any advantage.

In summary, my suggestion is that we only need 3 changes; to preserve the XML V/Div of the Ref waveform to correct for the comparison of large signals and small signals, to keep the Ref waveform vertical offset disconnected from the primary waveform vertical offset so that the two waveforms can be separated in the vertical plane, and to isolate the Ref waveform from Gnd Pos changes to ensure that vertical separation can be maintained.

If you’re able to conclusively describe the difference between a good and bad waveform, there is a fair chance that fault finding/diagnostics can be automated. Perhaps you should explain what this is really about and include accurate examples of waveforms (good and bad).

If we leave trigger position centered then 50% of the screen will always be blank when in fast mode and using post priority. Still your idea has some merit if we stop acquisitions and use pan/zoom to look closer at the waveform. Typical usage for post priority however is likely to be digital waveforms where the user is attempting to decipher some communication protocol. In this context, fast mode is less relevant. Fast mode is appropriate when we need a “high definition” acquisition of a single complex signal.

If we agree that comparing for equality is the primary use for a reference wave then any feature that compromise this should not be default. In this context I think the current behavior is appropriate and so this implies additional controls are needed for the added features.

Again, I appreciate your input so will keep this in mind for future updates.

That is one application, another application of Fast Post is when looking at a complex pulse signal and the interest lies in any ringing, noise, or slope deterioration of the pulse edges. For example, the fuel injector current signal rise time can be expanded to see when the actual injector pintle opens up (due to counter EMF caused by the pintle motion). When the injector pintle closes a similar glitch can be seen on the waveform. In this application, you would want a Fast Post so the waveform can be expanded horizontally as much as possible (with fast refresh rate for real-time viewing) and use the Trig Pos to place all of the expanded pulse on the screen in real-time.

In the current firmware version I can slide the Trig Pos to the left and leave it there for real-time waveform viewing without having to stop acquisitions. Now I can view the expanded Fast Post waveform in great detail at real-time fast update rates.

Although I mentioned the automotive application, there are many other uses where Fast Post would enable more accurate pulse width adjustments and also provide for better viewing of complex pulse irregularities in real-time with a fast refresh rate.

For off-line viewing of the captured XML files, the Fast Post XML file will not waste buffer space (sequence numbers) on information that is not desired. Instead, twice as much desired information post trigger will be available for examination.

Hope this serves to demonstrate why I think the Fast Post feature is important.

As you mentioned in previous posts, for Fast Post, the firmware could pre-position the Trig Pos near the left side of the display and then the user could fine adjust as required.

something else that would be an awsome feature is positive and negative duty cycle measurement in the same way that the new awsome pulsewidth feature is set up by using trigger to select pos or neg …currently we only have positive…i would use this feature many times over and the same with other auto guys… and example would be you read pwm commands with positive duty and pwm actuators with negative duty… same with crank sensor and injector measurements so this feature and fast post buffer will make it perfect from a auto mechanics point of veiw

Yea I second that request …that would be a nice competetive edge feature over other dso makers also…You took the words right out of my mouth on this one Brandon… :smiley: