I don't think it is a matter of true/false but instead a preference. When talking about old oscilloscopes the more limited memory certainly adds weight to the case for peak detect. Modern oscilloscopes and their larger memory reduce the advantages.
If it was preference I had no problem with it. But it's not that. You can go into any discussion about slightly older scopes as in this thread and there is at least one person who constantly bring up peak detect as a necessity - not as a personal preference.
A similar case can be said about protocol decoding; although convenient to have it featured on an oscilloscope, the current offers for cheap and easily configurable PC-based logic analyzers greatly reduce the need to have it built into the scope - it certainly is not as worth as the option prices of the A-brands, where a few of the options can easily go beyond the price of a full featured Saleae or a ZeroPlus.
And still in those threads no-one complains that older scopes don't have protocol decoding or dismisses certain scopes because they don't have protocol decoding
A while ago I interjected a discussion where both Mike and Nico explained to me their preference for having a peak detect oscilloscope. Despite the explanation made sense to me and backed by two very experienced users,
I did read that, too, but so so far I haven't read anything beyond "I use it because I'm used to use it". I'm not saying it doesn't work for these users, but there's nothing in there showing how peak detect in a modern deep memory scope solves a problem that without it would be unsolvable or even just more difficult to solve.
Given the size of the posts on this page, I'd say we need a peak detect thread, then again, I'm a bit terrified at the prospects for such a thread ![Fighting :box:](https://www.eevblog.com/forum/Smileys/default/fighting0030.gif)
Many threads already tore this subject to shreds. Don't even go that route... ![Scared :scared:](https://www.eevblog.com/forum/Smileys/default/scared.gif)
https://www.eevblog.com/forum/testgear/lets-talk-about-lecroy-scopes-aka-the-wuerstchenhund-holds-court-thread/msg1026148/#msg1026148
https://www.eevblog.com/forum/testgear/a-possibly-dumb-q-on-digital-oscilloscopes/msg1257270/#msg1257270
https://www.eevblog.com/forum/testgear/want-faster-and-newer-oscilloscope/msg1884350/#msg1884350
...and many more!
Na, I'm not going there
![Scared :scared:](https://www.eevblog.com/forum/Smileys/default/scared.gif)
Aliasing sucks.
I'm sorry to say this but so does your way of attaching pictures because I can't see them.
Someone recommended to attach images to the post and then use the image link in the text to make sure other people can see them
![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)
Gambling that you aren't aliasing sucks. You'll win 9 times out of 10 but you'll have enough fun on that 10th time to make up for everything you missed out on the other 9 times.
Doing due diligence to make sure you aren't aliasing sucks. You have to ensure that mF+nFs for all expected input frequencies F and integer m,n is >> 1/Tfeature for all relevant features you want to see. Sure, you can do it, if you know which input frequencies to expect. If you're an RF guy you might even be good at this calculation, but is it really what you want to spend your brain cycles on? Peak-hold lets you invest those brain cycles in something more productive, like daydreaming, or thinking about the problem you are hunting.
Not sure what you want to say here. Of course there is aliasing in my screenshots. So what? Peak detect is even less true to the original signal, which is why proponents claim to use it only to see if there are pulses or if there are glitches
![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)
But as shown in my screenshots I don't need to select peak detect to see the 1PPS pulses, and the fact that the signal has some aliasing doesn't change the fact that the basic timing parameters of the waveform are correct, something that would not be the case with peak detect
![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)
See that scope above?
No, unless it looks like two blue blobs
![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)
It would have caused no harm had you at least stated brand and model
![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)
It has 800Mpt of memory and can draw 1 million Wfm/s. By default, it has a 10Mpt acquisition depth limit enabled in its settings. If you zoom to longer timebases, it will decimate to keep depth at 10Mpt (or whatever you configure the limit to). Why? Because one typically prefers fast updates and deep history [1] to full resolution long acquisitions.
That sounds like one of the new R&S scopes WH has told me about. I think they can only use a small part of their memory in normal mode and can only use the large memory for I believe history and other special modes. Is that right?
1 million waveforms per seconds sounds great but to me that's just marketing wank (others have done it before, too). Update rates are way overrated
I prefer fast updates and deep history and I also prefer not to calculate beat frequencies vs feature frequencies. Peak detect lets me have my cake and eat it too. Thank you, peak detect!
If you prefer that, who am I to tell you it's not OK?
![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)
I have no experience with R&S scopes but frankly if you need to use a lot of brain power just to use extended memory or do frequency calculations (what fo, btw?) then I would say the scope isn't very good
![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)
On the Agilent Infinum I created the screenshots with, using Peak Detect would need slighty more effort while giving me inferior results
![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)
good luck (or retry) finding 10MHz glitch (100ns pulse width) with that setup. (glitch = something we didnt program nor expect but circuit went haywired)
I would't do that with that setup, that's what advanced triggers are for
![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)
@Mr Nutts:
So basically you reason for this discussion is that you like riling people up and you like to be right at all cost.
We gave you plenty of reasons why peak detect is not evil and can be useful sometimes, but you chose to ignore it all, and basically concluded that we use peak detect because we are backwards, luddites and generally not smart enough to know that there is a better way, your way....
Now I'm gonna go to a dark place, sit in a corner, crying softly and reflect upon my life, deeply touched by this great revelation..
NOT.
![ThumbsUp :-+](https://www.eevblog.com/forum/Smileys/default/icon_smile_thumbsup.gif)
So in short, instead of answering my question you decide to go all drama queen on me (David Hess has at least given a real example I could replicate, kudos for that). Fair enough, although considering your clear and obvious misconceptions about peak detect and sampling theory it appears you're pretty butt hurt
![Sad :(](https://www.eevblog.com/forum/Smileys/default/sad.gif)
I think I slowly start to understand what Wurstunhund meant when he said "you'll find out yourself" when I asked him about the kick-out (he didn't tell me except that I'd find out myself if I hang around here). Clearly one shalt not ask too many questions if it touches established mantra it seems
![Sad :(](https://www.eevblog.com/forum/Smileys/default/sad.gif)
So I'll grant you your safe space and bow out of this thread
![Wink ;)](https://www.eevblog.com/forum/Smileys/default/wink.gif)