But, untriggered refreshrate still is 4wfps...
And this is normal.
Without a signal it has no reason to trigger, it is just the auto-trigger rate.
oh, ok, I am a strange guy 
Could I ask why my other scopes have a higher refresh rate?
Maybe there are some problems with my other scopes?
You are not a strange guy as long as you're not an alien from another planet
You have a problem that you are facing and you are frustrated in the absence of a solution.
I saw in the datasheet that there is a trigger type mode called "Instant - Fast triggering without referencing the input signal".
I assumed that it is useful for FFT, in order to obtain maximum wfps without having a stable signal in the time-domain.
Have you tried this option? At least the unknown signal should appear on the screen. At slow timebase this setting could be useful to capture it.
I don't have the Magnova, so it's just a suggestion.
Ups, It seems I was a little behind in reading new messages
Every single step I am trying fails.
There's some truth to this. If you decide to try walking instead of getting on the boat, each step will likely fail when trying to cross an ocean.
We should listen to and learn from those with more understanding and experience than we have. We can learn much
with an open mind, and nothing otherwise.
Thanks,
Josh
Hardware counter operate independently on all ADC samples does mean on each channel ? Does this mean separate triggers, at least in theory?
A question for the Magnova team: Could it be used in the future for independent triggers for each channel?
For example, sometimes I need to visualize signals that are not correlated. The only solution seems to be to use two oscilloscopes.
But an entry-level oscilloscope from Uni-T has this option.
I have attached a picture in this regard.
Later edit
P.S. OK, I suppose the counters from the picture are software. Or not ...
I have added a second picture.
Every single step I am trying fails.
There's some truth to this. If you decide to try walking instead of getting on the boat, each step will likely fail when trying to cross an ocean.
We should listen to and learn from those with more understanding and experience than we have. We can learn much with an open mind, and nothing otherwise.
Thanks,
Josh
Dear Teacher, you skipped my last question/problem
I am ready to learn about this ''feature''
Dear Teacher, you skipped my last question/problem
I am ready to learn about this ''feature''
Are you referring to the screenshot that appears that you manually stopped the scope mid acquisition?
Every single step I am trying fails.
There's some truth to this. If you decide to try walking instead of getting on the boat, each step will likely fail when trying to cross an ocean.
We should listen to and learn from those with more understanding and experience than we have. We can learn much with an open mind, and nothing otherwise.
Thanks,
Josh
Dear Teacher, you skipped my last question/problem
I am ready to learn about this ''feature''
As for me, you really need to use the proper words when describing an issue instead of being sarcastic.
I guess I’m not the only one having a hard time to understand what you want to say.
Dear Teacher, you skipped my last question/problem
I am ready to learn about this ''feature''
Are you referring to the screenshot that appears that you manually stopped the scope mid acquisition?
Yes and no at the same time. Yes, right screenshot, yes, I stopped, but no - I assume the cause of this issue differs.
Dear Teacher, you skipped my last question/problem
I am ready to learn about this ''feature''
Are you referring to the screenshot that appears that you manually stopped the scope mid acquisition?
Yes and no at the same time. Yes, right screenshot, yes, I stopped, but no - I assume the cause of this issue differs.
You're actually making two assumptions. First, you're assuming it's an issue; Second, that the behavior is not caused by you stopping the scope arbitrarily.
Science/engineering is not founded on baseless assumptions. If you'd like to understand that behavior better, perhaps it would be better to phrase your statement about it in the form of a question so those that know better than us can educate us.
Perhaps you're correct and it is a bug, but that seems highly unlikely. This is a scope with a very fast acquisition system. I've seen it pick up weird things that no other scope I've had could begin to capture. I did think something was weird a couple times, and then I realized it was my previous scopes' lack of ability that made this new behavior look odd.
Thanks,
Josh
Perhaps you're correct and it is a bug, but that seems highly unlikely. This is a scope with a very fast acquisition system. I've seen it pick up weird things that no other scope I've had could begin to capture. I did think something was weird a couple times, and then I realized it was my previous scopes' lack of ability that made this new behavior look odd.
That's the intensity grading algorithm rendering the screen picture from several untriggered acquisitions. Again, something that every scope will do. But I guess also this this discussion will take the same turn as the one about aliasing.
Dear Teacher, you skipped my last question/problem
I am ready to learn about this ''feature''
Are you referring to the screenshot that appears that you manually stopped the scope mid acquisition?
Yes and no at the same time. Yes, right screenshot, yes, I stopped, but no - I assume the cause of this issue differs.
You're actually making two assumptions. First, you're assuming it's an issue; Second, that the behavior is not caused by you stopping the scope arbitrarily.
Science/engineering is not founded on baseless assumptions. If you'd like to understand that behavior better, perhaps it would be better to phrase your statement about it in the form of a question so those that know better than us can educate us.
Perhaps you're correct and it is a bug, but that seems highly unlikely. This is a scope with a very fast acquisition system. I've seen it pick up weird things that no other scope I've had could begin to capture. I did think something was weird a couple times, and then I realized it was my previous scopes' lack of ability that made this new behavior look odd.
Thanks,
Josh
What he shows could be two same pulses with different phases, untriggered, overlapped.
But, untriggered refreshrate still is 4wfps...
And this is normal.
Without a signal it has no reason to trigger, it is just the auto-trigger rate.
oh, ok, I am a strange guy
Could I ask why my other scopes have a higher refresh rate?
Maybe there are some problems with my other scopes?
You are not a strange guy as long as you're not an alien from another planet
You have a problem that you are facing and you are frustrated in the absence of a solution.
I saw in the datasheet that there is a trigger type mode called "Instant - Fast triggering without referencing the input signal".
I assumed that it is useful for FFT, in order to obtain maximum wfps without having a stable signal in the time-domain.
Have you tried this option? At least the unknown signal should appear on the screen. At slow timebase this setting could be useful to capture it.
I don't have the Magnova, so it's just a suggestion.
That is free running acquisitions, without any triggering, as fast as you can.
Picoscope has that. And you are right, good for FFT. Also good if you enable some measurements like RMS and use it as a high BW RMS AC voltmeter, for instance..
Just for fun, I switched my scope to Auto and attempted the same out-of-range triggering. The scope behaves exactly as expected; up to 5 wfms/s in auto with no trigger, and slightly faster than that with the trigger in range.
What he shows could be two same pulses with different phases, untriggered, overlapped.
Yes, exactly. The scope shows the intensity graded result of many acquisitions when running or when manually set to stop while in run mode. In this case untriggered, and therefore the waveforms overlap incoherently. He would get his proper square waveform that he seems to be expecting by pressing Single instead of just Stop.
And no, this is not a bug, this is again basic digital scope operation.
He would get his proper square waveform that he seems to be expecting by pressing Single instead of just Stop.
there is no need to use the single mode, just scroll through the history buffer after you stopped the measurement.
Here all the waveforms are showed as single capture events.
Here all the waveforms are showed as single capture events.
Try again with a 100 Hz square wave and choose a lower time scale setting like 200 µs/div, and instant trigger. Then you'll always get overlapping waveforms when you stop from run mode.
Sure, but all the data in the history buffer are not having this artefact...that I wanted to point out.
(and yes, I tried it by myself :-)
Sure, but all the data in the history buffer are not having this artefact...that I wanted to point out.
(and yes, I tried it by myself :-)
Yes, true, the overlap is only in the screen data. I missed the history buffer bit in your post, sorry. Time to go to bed.
building scopes with a glossy screen as insane and evidently not guided by engineering and rationality
Funny, I was just setting up a bunch of new cubicles today and spent the back half of the day (and will spend a decent part of tomorrow) dealing with a crisis caused by matte screens. The entire group of cubicles had to be rotated 90 degrees and this was a Big Deal for reasons you can imagine. None of it would have been necessary with glossy screens. We know because we had a few.
The engineering tradeoff is that matte screens blur the reflection while glossy screens don't. A matte screen does a brilliant job of hiding point lights compared to a glossy screen, at the cost of becoming irredeemably hopeless if you put it opposite a big bright window, which it will smudge over everything no matter how you angle it. A glossy screen just needs something dark and relatively bland to point at, while a matte screen needs the entire hemisphere behind it to be dark enough. Matte screens are like training wheels on a bike: they make easy things easier and hard things harder.
This is why phones are glossy: the sun is bright, the benefit of excluding it from the reflection rather than smearing it over the reflection is huge, and most people can figure it out. Even if they aren't self-declared rational pragmatic realists.
This is why phones are glossy: the sun is bright, the benefit of excluding it from the reflection rather than smearing it over the reflection is huge, and most people can figure it out. Even if they aren't self-declared rational pragmatic realists.
In the spirit of EEVblog-style pedantry, you'll find that phone screen protectors are available in both matte and glossy varieties. Though your point is still acceptable.
Just for fun, I switched my scope to Auto and attempted the same out-of-range triggering. The scope behaves exactly as expected; up to 5 wfms/s in auto with no trigger, and slightly faster than that with the trigger in range.
Dear KarateJohn,
please stop writing this BS
Dear Teacher, you skipped my last question/problem
I am ready to learn about this ''feature''
Are you referring to the screenshot that appears that you manually stopped the scope mid acquisition?
Yes and no at the same time. Yes, right screenshot, yes, I stopped, but no - I assume the cause of this issue differs.
You're actually making two assumptions. First, you're assuming it's an issue; Second, that the behavior is not caused by you stopping the scope arbitrarily.
Science/engineering is not founded on baseless assumptions. If you'd like to understand that behavior better, perhaps it would be better to phrase your statement about it in the form of a question so those that know better than us can educate us.
Perhaps you're correct and it is a bug, but that seems highly unlikely. This is a scope with a very fast acquisition system. I've seen it pick up weird things that no other scope I've had could begin to capture. I did think something was weird a couple times, and then I realized it was my previous scopes' lack of ability that made this new behavior look odd.
Thanks,
Josh
please, stop this BS.
A square wave was applied to the scope. If this is not a bug (without any additional monologs), then, please...
Hi everyone,
today we are releasing Magnova firmware version 1.8.1, introducing counter and DVM functionality, along with many other useful enhancements.
Thanks for all the feedback and suggestions here on EEVblog — several improvements in this release are directly based on your input.
New functionality:- Added high-precision frequency counter functionality, providing up to four independent and configurable counter instances, controllable via the measurements interface and based on various input sources. Supports frequency, period and totalizer measurements with statistics and trend chart functionality. Measurement interval (100 ms to 100000 s) and display resolution (up to 15 digits) are configurable, enabling accurate frequency measurements from below 1 mHz up to several hundred MHz.
- Added Digital Voltmeter (DVM) functionality, providing one configurable DVM instance per analog channel, controllable via the measurements interface. All DVM measurements are compatible with statistics and trend chart functionality.
- Increased the maximum number of concurrently active automatic measurements from 8 to 24. Added scrolling to the detailed view and multi-row support to the compact measurements view.
- Measurement annotations may now be activated/deactivated individually per measurement. To do so, tap on individual measurements in detailed view to open the context/quick menu and toggle the ruler icon as required.
- Waveform Color Grading types may now be specified individually per analog channel.
Optimizations:- Improved phase response determination for Bode diagram measurements. Phase can now be accurately measured even from heavily attenuated signals.
- Desired BMO-AWG arbitrary waveform types may now be selected via corresponding SCPI commands.
- Optimized label precision when working with decode tables.
- Changed mouse wheel scroll direction of decode table to become consistent with other system components.
- Added additional predefined probe attenuation ratios. The "Custom" field remains available for specifying custom attenuation factors.
- Magnova log file names now indicate date and time instead of date only.
- Various improvements and optimizations.
Bugfixes:- Fixed SPI decode table not functioning properly if only one of MOSI or MISO is selected.
- Fixed SCPI command related to FFT unit control not working properly.
- Fixed automatically measured edge count potentially providing reduced value due to unintentionally high signal constraints.
- Fixed device becoming unresponsive in case of missing but requested external reference clock.
- Fixed issue where disabling BMO-AWG would not suppress all signal output.
We’ve also put together a short video demonstrating the new features in action:
(Note: The audio track is available in both English and German.)