Suggestion:When choosing a new measurement (clicking on an existing one) there is one selected, that is already used. One would think that you actually could deselect this, or changing the sources would affect this very measurement. (see picuture).
It can be activated, if you select the one that you actually opened.
Suggested solution:Differentiate between measurments that are used for the particular channel/s, and the measurement that will be currently changed/activated.
Minor measurement issue:
In more or less extreme circumstances, the measurements become unreliable. How could one know, that he has gone to far?
As the gate cursors do really stick to the curve, it is quite confusing that they dont, when zooming pretty far in.
The measurements become wrong too, when zoomed out a fair bit!
As mentioned in the bug thread, I'm afraid the video is not helping me to understand the problem. It is also very blurry; I can't really see anything beyond the fact that you appear to be changing the timebase.
Could you please elaborate?
- What are you trying to measure?
- What settings are you changing?
- Which traces/cursors/values should I be looking at, at which timestamp?
- How is the behaviour of that trace/cursor/value different from what you expect?
A still screenshot or two are probably better to illustrate the issue, together with the above information. In those you can show the relevant time points (only), and the quality will be much better.
Thanks!
Thanks for the sharper video. I may still misunderstand what you are concerned about, but I believe it is about two separate issues:
(a) The position of the gate cursors is obviously limited to the time window shown on the screen. So when you zoom far in (100 µs/div and faster in your example), the cursor positions get "clipped" to the screen boundaries. This makes sense to me -- after all, you set the cursors because you want to measure in specific sections of the signal, based on your visual observation of the signal. So why should they be set somewhere out of sight?
(b) When you zoom far out (50 ms/div and slower), the "green" measurement values, i.e. the inter-channel delays, are no longer correct. At 50 ms/div they are not measured at all; at 100 and 200 ms/div they come back, but are incorrect. I find that unexpected too, since the scope supposedly makes all measurements in its full-resolution data buffer, so they should not change. (And the CH2 width measurements in fact don't change.)
In summary, I see no issue with (a), and an unexpected behaviour -- although not highly relevant in practice -- with (b). And I would love if you could describe such issues similar to what I tried for (b), rather than letting me stare at a video and take my best guess...
...
I have now 2 issues in my head. It might get confusing...
- I try to measure the last falling edge from the red to the last rising edge of the blue. There is no LFFR measurement. I though id be smart and use FRLF, and switch the sources, but that dont work.
- I dont change settings? How would you think?
- Video description: Measurements are wrong at zooming out (Keep your eye on value of FRLF), and gates do not stay as they appear otherwise, if you zoom in. Quite easy to miss.
(a) Because i might measure stuff, and look at details.
Your summary:
If one would assume, that those gates will not change, then he would get wrong values if this little detail gets missed. Yes its a case not many would experience, at least not those that are creative.
I do not really understand what you want me to describe.
New issue:
How can i measure last rising edge of blue to last falling edge of red?
New issue:
How can i measure last rising edge of blue to last falling edge of red?
Looking inside your gate window only: After the last rising edge of the blue trace, there is no more falling edge of the red, right? So what do you want to measure?
In general, since there are no delay measurements which start with a
last edge, I think you need to work with the trigger to grab the starting edge of interest for such measurements. Then position your measurement gate cursors relativ to the trigger point, such that the starting edge becomes the
first edge within the gate window.
(Pulse or Dropout triggers should work well with those signals which have short PWM pulses overlaid on the slower low/high transisitions. Set a ">=" time which lets the trigger ignore the short pulses, that will let you get hold of the longer-period transitions.)
Dunno if discussed earlier in other threads, i post my potential desires here :
1) There is a way to "embed" the small floating measure track window in the main display like a math trace ?
2) There is a way to export measure track window data ?
The track function works surprisingly good for the intrument price segment, but without above mentioned features its potential is heavily limited.
Suggestion:
When choosing a new measurement (clicking on an existing one) there is one selected, that is already used. One would think that you actually could deselect this, or changing the sources would affect this very measurement. (see picuture).
It can be activated, if you select the one that you actually opened.
Suggested solution:
Differentiate between measurments that are used for the particular channel/s, and the measurement that will be currently changed/activated.
When clicking "+", there is no need to display the previously all added measurement items.Edit: I try to understand the current strategy by clicking on an existing measurement item, Pop up measurement selection box will display all the measurement items for all channel. One benefit is to know which measurement items have been added.
The benefit of your suggestion is that it allows for modifications to the current measurement items.
1) There is a way to "embed" the small floating measure track window in the main display like a math trace ?
If displayed in full screen, the coordinate system needs to be modified, which is a good feature and the implementation looks a bit complicated. Added Wanted Feature No.32
2) There is a way to export measure track window data ?
Exporting data is a reasonable feature. Added Wanted Feature No.33
I think you need to work with the trigger to grab the starting edge of interest for such measurements. Then position your measurement gate cursors relativ to the trigger point, such that the starting edge becomes the first edge within the gate window.
The starting edge can not be measured, as there is no LFXX function. It is then of no matter how you would set up the trigger, is it?Now i understand...
Yes, the dropout would somehow work. But i dont know how well with those small pulses there. As in another post of mine, there are some measurement issues in some extreme cases. I think just changing the program would be the proper way to handle this.
Edit:But now i want to measure the same thing on other channels at the same time... what can i do now? (see pciture - yellow last falling edge to green first rising edge)
This is actually the "range" ?
This is actually the "range" ?
If the Min and Max values are correct, then yes, that appears to be their difference. Is there reason to assume it is incoprrect?
But now i want to measure the same thing on other channels at the same time... what can i do now? (see pciture - yellow last falling edge to green first rising edge)
Maybe you would be better off if you use a Math low-pass filter to get rid of the high-frequency PWM pulses, then measure the relative timings of the simplified signals? That's a more straightforward set of measurements which should be possible with a more generous gate window, or without any gating at all.
If the
absolute time delays between edges are relevant (and not just relative fluctuations or glitches), you should probably run
all channels through low-pass filters with the same settings, to make sure they all see the same filter delay.
If the Min and Max values are correct, then yes, that appears to be their difference. Is there reason to assume it is incoprrect?
In statistics google told me, that "range" would be the adequate term.
I dont see how i could measure "last rising edge". I can not set the gate differently, because i need to measure them at the same time. Why is there just no LFxx or LRxx measurement?
In statistics google told me, that "range" would be the adequate term.
Ah, your concern was about the
terminology -- I thought you were wondering about the suspiciously round value. Personally I would have called the entry "Max-Min", but it does not really matter, does it?
I dont see how i could measure "last rising edge". I can not set the gate differently, because i need to measure them at the same time. Why is there just no LFxx or LRxx measurement?
Have you tried the low-pass filter, and checked what the FFxx measures on the filtered signals give you? I think you should be alright.
Have you tried the low-pass filter, and checked what the FFxx measures on the filtered signals give you? I think you should be alright.
I have changed my program to test it. Still i dont know how i should capture that last falling edge, since i cant not move the gate there, wenn i want to measure both delays at the same time.
Still i dont know how i should capture that last falling edge, since i cant not move the gate there, wenn i want to measure both delays at the same time.
But why do you still need the gate cursors at all now?
With the fast PWM pulses gone, you can now measure the time between any CH1 falling edge and the next CH4 rising edge which follows that, right? And likewise for the other timing measurements you want to take in parallel. I think you can just disable the gating function entirely.
But why do you still need the gate cursors at all now?
With the fast PWM pulses gone, you can now measure the time between any CH1 falling edge and the next CH4 rising edge which follows that, right? And likewise for the other timing measurements you want to take in parallel. I think you can just disable the gating function entirely.
Didnt you tell me to use the gate to grasp the last falling edge? Yes it now works without some extendes setup.
Still i need the gate, or else it would just grasp the wrong edges, unless you would zoom right. But with the gate i can zoom all i want (to some extend).
See my setup in the pictures, with, and without gate.
Oh -- I did not realize that these delay measurements can also go backwards in time. I only played with them briefly and had not run into this situation.
Then the manual is wrong: "FRFF: The time between the first rising edge of source A and the following first falling edge of
source B", etc. for the other modes, see section 18.3.4.
Edit: Having thought this over a bit, I would actually prefer if the scope behaved as described in the manual.
In most use cases I can think of, it is clear which edge (in which channel) comes first, e.g. because there is a causal relationship between the signals in both channels. So I can always assign the channels such that a positive delay is to be measured. The scope should then only measure positive delays -- i.e. look for an edge in channel B which follows the edge in channel A. False measurements caused by the scope unintentionally "going back in time" when looking for the nearest edge would be avoided.
So I could argue that the present scope behaviour is a bug -- it's not what the manual says. What do others think? Which behaviour is more useful to you?
Oh -- I did not realize that these delay measurements can also go backwards in time. I only played with them briefly and had not run into this situation.
Yes, it is a complicated topic. There are many use cases.
Measuring to the
following edge would be undesired, if you would measure a delay that swing around the first edge. Then, the current behaviour would be desired.
What do others say?
What do others say?
There are so many changes coming that will impact on many things....I say you should wait until we have the new firmware.
The beta FW Release notes are a substantial list now and also added to a couple days back.
Only patience will reveal what is to be delivered.
I have another issue:
I set up a qualified trigger, but the edge trigger is not stable.
The deviation gets worse, if i set the trigger level lower.
