LeCroy Wavepro HD 8GHz Bw - / 20GS/s 12bit ADC - Page 1
Forum section: electronics / testgear

author: Eric_S
author_rank: Regular Contributor
timestamp: May 10, 2018, 03:21:28 pm
content: So LeCroy's released a new entry in their HD/12bit ADC range:8GHz Bw - / 20GS/s 12bit ADC, 5Gpoint memory.http://teledynelecroy.com/waveprohd/http://teledynelecroy.com/pressreleases/document.aspx?news_id=2049&capid=107&mid=554(I haven't looked at the spec sheets in detail yet regarding ENOBS, etc)

author: srce
author_rank: Regular Contributor
timestamp: May 10, 2018, 05:34:18 pm
content: Looks pretty good. Shame it wasn't available last month when I bought a keysight s series. Looks like it is better in a few areas

author: DaJMasta
author_rank: Super Contributor
timestamp: May 10, 2018, 06:52:13 pm
content: I like that there are some really high bandwidth options well over 8 bits now and I very much like that there are some sample memories that measure in gigapoints now. It's a nice direction to be going, now maybe in 10 years one will fall into my pricerange

author: Eric_S
author_rank: Regular Contributor
timestamp: May 13, 2018, 06:59:25 pm
content: ... After briefly reading the spec sheet.It's got a lot of good and some that is "bad" (which I'll post since that's more interesting)It's full BW/samplerate in interlaced mode, and full sample memory only appiles in said interlaced mode (so 2.5 for 4 channels vs 5 in 2 channel mode).The digital mem is 125Mpoints vs the 2.5/5Gpoints of the analog channels.And the "analysis memory" is 0.5Gpoints?

author: Fungus
author_rank: Super Contributor
timestamp: May 13, 2018, 07:36:33 pm
content: Price?

author: iMo
author_rank: Super Contributor
timestamp: May 13, 2018, 07:53:37 pm
content: QuotePress Release: Chestnut Ridge, N.Y., May 8, 2018

author: madmax96
author_rank: Contributor
timestamp: June 20, 2018, 08:47:04 pm
content: Really good oscilloscope from the banner specs. 8Ghz and 12 bit are really top performance . Also noise and Enob seem good

author: Scratch.HTF
author_rank: Regular Contributor
timestamp: June 23, 2018, 07:58:18 am
content: Does LeCroy (or anyone else) offer FFT analysis for 1G+ points?

author: madmax96
author_rank: Contributor
timestamp: June 26, 2018, 06:36:33 pm
content: LeCroy can do FFt on 500M points, none else should be able to manage so much samples.

author: DaJMasta
author_rank: Super Contributor
timestamp: June 26, 2018, 08:52:23 pm
content: For more points in an FFT, can you just use persistence mode? If that's what you mean by points, at least. If you mean bins.... I don't know of a scope that offers that, but it would take an immense amount of calculation to do...

author: rx8pilot
author_rank: Super Contributor
timestamp: June 26, 2018, 09:12:14 pm
content: The 20GS/s sample rate seems slow for 8Ghz BW. Within Nyquist, but barely.

author: Eric_S
author_rank: Regular Contributor
timestamp: June 27, 2018, 05:30:39 am
content: If I'm not mistaken, LeCroy's position on the matter is that 2.5 oversamples is ok, as long as your filters are sharp enough and you use a correct interpolation.

author: Berni
author_rank: Super Contributor
timestamp: June 27, 2018, 06:18:03 am
content: The Keysight Infiniium scopes do FFT on 1Gpts (If you have the pricey option installed to unlock that much memory). Tho it can take it quite a while to crunch the numbers on something like that. Especially on the models that still use the older slow CPUs

author: Eric_S
author_rank: Regular Contributor
timestamp: June 28, 2018, 05:50:10 am
content: Quote from: Berni on June 27, 2018, 06:18:03 amWhat sort of time are we talking about (for the modern scopes)?

author: Berni
author_rank: Super Contributor
timestamp: June 28, 2018, 06:20:48 am
content: I haven't tested it but i would assume the time is measured in minutes.In general FFT on the infiniium scopes becomes a slideshow once you get past 10 Mpts. Its not hardware accelerated in any way, the older CPUs don't have great floating point performance and the software is not very multi threaded in most tasks.I rarely find massive memory depths useful. As soon as you start putting any automated measurements or math on these long waveforms things slow down to a crawl. Here and there they might be useful for capturing long events in detail or with protocol decoders to just snap a big chunk of time and move trough the data at your own pace.

author: bson
author_rank: Unknown
timestamp: June 28, 2018, 07:32:51 am
content: Quote from: Berni on June 28, 2018, 06:20:48 amI have to agree with this. Deep memory is nice for multiple segmented captures. But for just a single transaction, not that important. As an example, a 64 byte page write to an I2C EEPROM is about 70 bytes (a little less), each with 10 clocks, giving 700 clocks. Capturing 10 samples per clock requires a whopping 7k pts. With 20k pts there's lots of leeway for imperfect trigger delays, inter-byte clock delays, clock stretching here and there, etc. 20000 points! Typically when working I'll stay at 50k pts. That's really plenty, while with such a short record any half decent scope is snappy. The exception of course is FFTs, but even then capturing at 2x the max frequency for something basic like audio (at 50kSPS) getting even 512k pts takes ten seconds - just to capture the data. Against this backdrop it doesn't matter how fast the FFT itself is - 10ms, 100ms, 1000ms... doesn't matter since the update time is dominated by the acquisition. And this is even worse when looking at anti-imaging filters with cutoffs at e.g. 100Hz to say monitor a voltage level. 512k pts at 200SPS is hopeless. (This where my HP 3577A VNA really shines as it can get down this low to sweep a filter in 10-20 seconds at SNRs that are totally unrealistic with an FFT based approach. Never mind it will also do log sweeps! Not to mention also gives me a phase trace, which for some reason is uncommon in scopes.)

author: srce
author_rank: Regular Contributor
timestamp: June 28, 2018, 08:22:19 am
content: Quote from: Berni on June 28, 2018, 06:20:48 amI've seen an FFT on the MSO S take > 20 minutes. Their support didn't think this was a problem.

author: Berni
author_rank: Super Contributor
timestamp: June 28, 2018, 09:42:47 am
content: For low frequency and audio stuff i have a HP 89410A (DC-10MHz Vector Signal Analyzer). Its workings are a bit strange in that it works like a spectrum analyzer but even the mixing is done in the digital domain while it still does some FFT in the end. It lets you have a RBW of 0.03Hz and includes a general purpose signal generator that can be used as a tracking generator. The high dynamic range lets you even measure the low THD of audio stuff.But regarding FFT in infiniium scopes its still pretty nice. The scope is smart enough to set up all of its acquisition settings from the desired FFT settings. So if you want you can simply fullscreen the FFT window and just change the Start Stop RBW parameters on your FFT. It can do wide spans on few KHz RBW pretty fast. Makes it feel like you are suddenly using a real spectrum analyzer, but as long as you keep in mind the limitations of a scope signal chain. It doesn't have a massive dynamic range and it has some spurs that come from the scopes internal noise.On most other scopes i found the FFT pretty crap (Never had the chance to use a high end LeCroy tho).

author: Mechatrommer
author_rank: Super Contributor
timestamp: June 28, 2018, 12:35:42 pm
content: Quote from: srce on June 28, 2018, 08:22:19 amI've seen (and think i owned) a real SA that takes sweep about that time for particular (manual) setting (lowest RBW, full span) anyway FFT is a FFT regardless of any device, its not a real sweep SA, if you have immense reading you'll know the difference (things like leakage)... fwiw..

author: David Hess
author_rank: Super Contributor
timestamp: June 28, 2018, 01:36:55 pm
content: Quote from: Fungus on May 13, 2018, 07:36:33 pmIf you have to ask, then you cannot afford it.Quote from: madmax96 on June 20, 2018, 08:47:04 pmI wonder what its 12 bit settling time is. Higher resolution non-sampling oscilloscopes usually fail in this regard and the EOB of less than 8 bits is not promising.Embedded Windows 10? What fun!

author: darkstar49
author_rank: Frequent Contributor
timestamp: June 29, 2018, 09:45:43 pm
content: Quote from: David Hess on June 28, 2018, 01:36:55 pmwhere the heck did you see Windows Embedded...?With an I7 6th Gen and 16GB of RAM (32GB as an option), that doesn't sound like a winning couple...And some of the options are to my knowledge not compatible with embedded Windows versions.

author: Berni
author_rank: Super Contributor
timestamp: June 29, 2018, 11:09:08 pm
content: Test equipment that has a PC inside often uses the Embeded version of Windows. This is not to be confused with Windows CE, Windows IoT or Windows RT. Basically the embedded version is a more "no bullshit" version of the normal desktop version of windows where they let the OEM strip away anything they don't need. The licensing also works differently as you can't buy this version of windows on your own (Likely involves a contract and buying it in bulk). So anything that is compatible with the regular Win 10 versions should be compatible with this (As long as the OEM has not stripped out some essential module).They had the embedded version since Windows XP, but i would imagine in Windows 10 it brings more drastic changes due to all the extra crap in it. Pretty sure things like Cortana, forceful updates, forceful reboots, ads in the start menu, nagging to log you into microsofts services etc... are all removed in the embeded version. It might actually be the best version of Win 10 to run on your PC.Id still rather have Windows 7, but hey maybe they did a good job of cleaning the nonsense out of Win 10. Microsoft is already starting to wind down support for 7 so i guess they had to go to 10 to avoid having to transition to the new OS later down the scopes lifecycle.

author: rx8pilot
author_rank: Super Contributor
timestamp: June 29, 2018, 11:52:45 pm
content: I just finished a design job that used Win10 embedded. That choice that was well outside my part of the project, but I was able to see how it worked from the inside. Overall, it is pretty good. The end user has no idea and it allowed us to put more effort into custom hardware compared to most other options. The software developers liked it and the end result was very good - no complaints from anyone.

author: David Hess
author_rank: Super Contributor
timestamp: June 30, 2018, 08:25:25 am
content: Quote from: darkstar49 on June 29, 2018, 09:45:43 pmThe datasheet as shown below.Quote from: rx8pilot on June 29, 2018, 11:52:45 pmIf you are good, then the complaints come later. If you are Tektronix, then the complaints come immediately.

author: darkstar49
author_rank: Frequent Contributor
timestamp: June 30, 2018, 12:45:01 pm
content: still can't see the word 'embedded' in there...And honestly, with Lecroy, that doesn't matter... ALL x86 Windows Embedded scopes can run a 'full' Windows as well... (at least until now), so I wouldn't care too much about that... and while the scope is 'new' as such, their PCIe interface card was very probably not changed since the HDO series (why should they ?), there's shouldn't be any driver issues...

author: Berni
author_rank: Super Contributor
timestamp: June 30, 2018, 01:01:36 pm
content: Or did you mean to make a point that its using Windows on a PC as opposed to using for example VxWorks, Linux ,Windows CE, Android etc.. running on a CPU that's not x86.Still almost all high end scopes have a embedded PC running Windows. It makes sense to do so too. It does carry a cost penalty as a PC is more expensive than a ARM SoC and Microsoft wants a good bit of money for that Windows license, but these scopes already cost over $10 000 a piece so its not that big of a factor. Yet using windows brings a lot of other benefits both during development and to the end user. During hardware development they don't need to waste work on the computer part, just buy a motherboard and plug it into the fancy pile of FPGAs and ASICs that make the actual scope part where you focus your development efforts. Then the software department doesn't need to waste time putting together a custom Linux image, just install windows from a CD and it magically works. For the actual scope part they just need to write a tiny driver involving PCIe or whatever else they use to hook up the fancy scope guts. Then when they write the software they can use the very rich set of tools available to windows developers like .Net framework and easy hardware accelerated graphics. The software developers don't need to have prototype hardware on there desk, they just use a normal PC. It all just worksThen as the user the engineers get the familiar windows environment that they already know how to use and they can run existing tools on it like MATLAB, LabView etc or get extra software from the scope manufacturer (Such as Keysights VSA software). The installation that comes on the scope comes with a hidden backup partition that can be used to revive the scope in case the OS breaks for some reason. And you can use all standard peripherals with the scope such as a mouse, keyboard, external monitor etc.And no, most engineers don't use Linux. We usually don't have time to dick around with getting stuff to work.

author: darkstar49
author_rank: Frequent Contributor
timestamp: June 30, 2018, 01:51:47 pm
content: Quote from: Berni on June 30, 2018, 01:01:36 pmIf that's the point... well...just like ANY other scope from Lecroy (not talking about rebranded Siglent stuff, aka WaveSurfer 3K) since more than 15 years !!!!And also like ANY other brand for their higher-end scopes... (just the latest Tek MSO5x than can have both, i.e. Linux or Windows...), Keysight, Tek, R&S, Lecroy,...

author: David Hess
author_rank: Super Contributor
timestamp: July 01, 2018, 06:26:47 pm
content: I was not impressed with Windows 7 used in the Tektronix MDO5000 series. There were various interface glitches, a poorly designed user interface, freezing requiring reboots, poor interface performance, etc. And that was a $20,000 instrument!And then I read about problems with oscilloscopes that use Windows when Microsoft support ends. This loses importance if networking is not used (1) but is this considered a time limited feature?(1) And I would not care because I am vary familiar with network security at a low level but what about in a corporate environment where network security is considered overhead?

author: nctnico
author_rank: Super Contributor
timestamp: July 01, 2018, 07:22:43 pm
content: Quote from: David Hess on July 01, 2018, 06:26:47 pmThat is more likely a problem of Tektronix' programmers skills than Windows itself. The software for their logic analysers is painfully slow as well. It runs equally fast on a Pentium 1 and a Pentium 5.BTW The MDO5000 series runs on Linux unless you specifically order the Windows option.

author: Berni
author_rank: Super Contributor
timestamp: July 02, 2018, 06:05:03 am
content: Oh these new 8 channel scopes from Tek are buggy? I was pretty impressed by the well designed UI on these scopes from what i saw in the reviews. They really did a big improvement in comparison to the previous scope.The software on the Keysight infiniium scopes was pretty solid in my experience. Never crashed or glitched out in a weird way, the speed of it might not be exactly lighting fast but its almost never annoyingly slow (Apart from >100Mpts captures).The networking thing is not only for windows. Having old linux based devices on a network can also have security risks as various exploits for routers, modems, IP cameras etc.. show, just that scopes are not common enough for people to target, while windows desktops sure as hell are. But if your scope runs Win XP yeah keep it off the network or fortify it behind a strict firewall on the network.The scopes are still upgradable tho. When windows 7 started becoming a thing, Agilent made a windows 7 upgrade kit for infiniium scopes. The software they run on is common for all infiniium scopes so it gets ported onto new windows (Untill the scope is very old and they drop support such as the 8000 series, those run win 98). For a lot of scopes it was just a CD with software and a win7 license, but some scopes also included a new motherboard in the kit to bring them up to recommended win 7 specs.

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 02, 2018, 07:07:19 am
content: I just bought a Infinum 8064 scope and it runs XP, and I don't believe any 8000 ever run Win98. I think the only Infinum scopes that ran Win98 were very early ones, and I guess the PC part in them would have been too weak to run anything else anyways.Apparently some people converted their old Infinum scopes from XP to Win7, but really what's the point? It doesn't give you more speed (the performance is still decided by the ASICs), it's not like you can run the newer software for Win7 scopes, and it doesn't give you more security. And I don't think it matters a lot for test instruments like scopes, unless you connect it to the open internet which would be plain stupid anyways.I recently watched a Youtube video about the Tek MSO5. The scope looks nice but the GUI appears to be very old fashioned, and some things looked outright stupid (i.e. disable a channel by dragging it to the recycle bin???)My 8064 is old but the GUI is much nicer and more logical than the one of this Tek scope. And god I really hope it's not as slow as the Tek scopes we had at college

author: Berni
author_rank: Super Contributor
timestamp: July 02, 2018, 07:33:29 am
content: Ah sorry i must have confused it with the older infiniiums that still had the old HP style model numbers. But i do know that the 8000 series is not supported anymore in the latest infiniium software release. I think the support was dropped a bit before the UI redesign with the all black theme.Sometimes it does help to have a faster PC inside of it. These infiniium scopes do a lot of processing on the PC side, including rendering the waveform and zone trigger.Oh and upon checking it i noticed that that the latest 6.2 infiniium software does officially support windows 10 now. But is also still officially supported on win7. Perhaps the brand new scopes rolling off the Keysight production line are now also coming with win 10 installed on them.

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 02, 2018, 07:51:54 am
content: I'm not an expert but from what I've read it appears the PC part in the older Infinum scopes doesn't actually do a lot as Agilent built all the scope functionality via ASICs. There are reports from people who upgraded the CPU and RAM in their 8000 scope and didn't see any speed improvement. And rendering the waveform isn't a very demanding task even for those older processors.This appears to be in contrast to lecroy which (again from what I've read) does everything on the scope's CPU. There are reports where scopes were upgraded with faster CPU and RAM and the scope's performance increased as well.I don't believe it matters what OS a scope runs on, as long as it does what it says on the tin. What I do like on non-Windows scopes like my LT374M is that they boot very fast compared to my new 8064 which takes like 3 minutes. But it may well be the hard drive which doesn't sound too healthy. Probably time to replace it with a SSD.

author: srce
author_rank: Regular Contributor
timestamp: July 03, 2018, 02:21:49 pm
content: Windows can be very handy at times

author: Berni
author_rank: Super Contributor
timestamp: July 03, 2018, 06:53:15 pm
content: Yes at some point you can run into limitations of the FPGA or the interface to the PC. On the old infiniium scopes that interface has to go trough a oldschool PCI slot and those are pretty sluggish by todays standards, but it does seam to have some hardware help for drawing the waveform.Later on the 9000 series has stepped up to using PCIe 1x to give it significantly more bandwidth, later on the S series has stepped it up PCIe 4x (And likely Gen 2).At the same time the new infiniium software has moved to .net framework and has started drawing the waveforms completely in the PC, all math channels(including FFT) are also calculated by the CPU. But it does seam to use DirectX graphics acceleration to draw it. You can show this because the software can be installed on a regular windows PC and i had pretty similar performance and responsiveness when i ran the software inside a virtual machine without any of the scope hardware attached.Oh and the reason why it can draw a 1Gpts waveform in software at a responsive speed is that they cheat and start skipping samples once you zoom out on a very large waveform, as a result you don't get quite as good intensity gradation on long waveforms, its still there, but its not quite as detailed as it could have been.

author: nctnico
author_rank: Super Contributor
timestamp: July 03, 2018, 06:57:33 pm
content: Quote from: Berni on July 03, 2018, 06:53:15 pmIn my experience all DSOs do that. See my RTM3004 review for some typical (aliasing) effects. You can get the same results on any DSO.

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 03, 2018, 08:35:29 pm
content: From what I read, the early Infinums (those with the model numbers that start with 548) had a second graphics card with a very old GPU to draw the waveforms, all connected over PCI.My Infinum 8064 doesn’t have this additional graphics card, also it has PCIe not PCI.I understand that the very old Infinums also had no intensity grading, well my 8064 has intensity grading.I read that the Infinum 8000 is much closer to the Infinum 9000 than to these early Infinums, despite using the same housing.You are probably right that the Infinum scopes skip samples when you zoom out but I really don’t know, it appears it only uses the full sample memory for the last acquisition before it gets stopped. I only read (and also was told) that lecroy scopes use some kind of binning process when you zoom out so that every sample is represented on the monitor.

author: nctnico
author_rank: Super Contributor
timestamp: July 03, 2018, 09:35:24 pm
content: I hacked my Infiniium 54845A with a faster processor and that does increase the waveform update rate. Someone else put a way more modern CPU in it and he got 20 times the original waveform update rate. Still not stellar for today's standards but quite interesting none the less.

author: David Hess
author_rank: Super Contributor
timestamp: July 03, 2018, 11:28:06 pm
content: Quote from: Berni on July 03, 2018, 06:53:15 pmThat makes perfect sense just for performance.Last year I worked out the details for translating a continuous acquisition record to a display record and memory bandwidth is a severe limitation. Even the L1 cache bandwidth of the fastest processors made is too slow to generate the display record from the entire acquisition record. That leaves some type of ASIC or FPGA which interleaves the acquisition record to divide up the work and I doubt anybody is doing that. If they are, their application notes and specifications do not reflect it.The simple solution is to decimate as required. The solution I arrived at was to decimate into multiple histograms which have different depths so the lowest depth histogram (1 bit is effectively peak detection) captures the entire acquisition record while higher depth histograms only capture a decimated fraction of the acquisition record as limited by memory bandwidth. That is when I ran across an application note from Rohde and Schwarz who apparently do something like this with their RTO series of DSOs as shown below.

author: Berni
author_rank: Super Contributor
timestamp: July 04, 2018, 05:26:43 am
content: Ah that's a nice way of doing it.I never noticed any aliasing issues with the infiniium scopes, but perhaps i just haven't found just the right combination of settings and waveforms to get it to show up.But even the new infiniium scopes don't get you stellar waveform updates due to it all being done in software. A few 1000s wfm/s is all you get. High waveform update rates are in there MegaZoom ASIC scopes and i do like the speedy UI on those. When i mentioned a DSO9000 at a Keysight booth on a tradeshow the guy quickly tried to sell me on a DSOX6000 and shown off its milti-zone trigger at full waveform update rate. I don't really see many people buying these X6000 scopes as they don't make a lot of sense. Sure its a nice scope with 20GS/s 6GHz, but apart from that its essentially a MSOX3000T that is WAY cheaper, but the applications of such a high performance scope usually mean lots of probing setup so the quick nature of the MegaZoom scopes is not that important. Yet if you go for an PC based infiniium you can get them for a better price, but also get the much more powerful software (And also way more sample memory than only 4Mpts). Really the list of math/analysis features can fill an entire A4 page and the list of protocol decoders another A4 page.

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 04, 2018, 07:02:45 am
content: Didn't the early infinums have something like a Socket 7 AMD K6? Who knows maybe the CPU was causing a bottleneck.Besides, the additional graphics card seemed to have an Chips & Technology 65000 series GPU. From what I found this GPU is really antique, it came from the days of 386 processors and ISA bus. I can't imagine that this wasn't a bottleneck even for the early Infinum scopes.But it appears that putting a massively faster CPU in a Infinum 8000 has barely any effect on performance. So the Pentium 4 with PCIe that is in these scopes is probably the sweet spot for the architecture.I just had a look at the Agilent 54845A spec sheet:https://literature.cdn.keysight.com/litweb/pdf/5980-2397EN.pdf?id=1000070291:epsg:dowIt says the 54845A update rate is >2100 waveforms per second.Then I looked at the Infinum 8000 datasheet:https://literature.cdn.keysight.com/litweb/pdf/5989-4271EN.pdf?id=763880It says the Infinum 8000 max update rate is >2000.And you say that just by changing the mainboard and CPU someone got more than 42'000 waveforms per second from a 54845A with slow PCI bus?

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 04, 2018, 07:26:45 am
content: Quote from: David Hess on July 03, 2018, 11:28:06 pmMaybe I understand this wrong but how is this special? My LT574 which is now old enough to vote can do that

author: David Hess
author_rank: Super Contributor
timestamp: July 04, 2018, 03:06:20 pm
content: Quote from: Mr Nutts on July 04, 2018, 07:26:45 amI would need to see some documentation which I was not able to find for the LeCroy Waverunner2 LT574 series but I have been told very specifically that LeCroy does what I discussed first where the entire acquisition record is transferred to the processor without decimation leading to the performance issue I described. That would be only the "sample" mode shown in the R&S documentation.There is nothing wrong with using brute force on the processor side as LeCroy apparently does but I was looking for something more efficient and less costly to implement with the added goal of zero blind time.

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 05, 2018, 12:44:41 pm
content: I have no idea what lecroy is doing but I searched a bit and found very little information about these older scopes. The only information I found is from this Mr Wurstunhund and is spread over lots of different threads.One document that was referenced is this which describes how lecroy's current scopes work:http://teledynelecroy.com/doc/xstream-ii-technical-briefWhat I picked out from the many discussions I read is that the older scopes like my LT574M work basically after the same principle, minus some features like the lossless compression and the preview function and much slower of course.I'd be lying if I said that I understand everything in that documentIt's fascinating stuff nevertheless.

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 05, 2018, 01:05:59 pm
content: Quote from: Berni on July 04, 2018, 05:26:43 amMy Infinum 8064 has MegaZoom ASICs but the update rate is still slow at 2000 waveforms per second.And the Infinum 9000 spec sheet say it, too, has MegaZoom.So not all MegaZoom scopes are fast.

author: David Hess
author_rank: Super Contributor
timestamp: July 05, 2018, 01:11:36 pm
content: That LeCroy document agrees with what I wrote and the various posts from Wurstunhund but I wonder if they did it differently in the past. I did not get into that much detail but breaking the acquisition record up into cache sized chunks is an obvious thing to do to maximize processor throughput which is very important if the processor is doing the heavy lifting which is LeCroy's thing.It makes good sense because fast processors have benefited the most from increasing integration. The alternatives are expensive ASICs like HP/Agilent/Keysight did with their Megazoom thing or an FPGA as a lower performance alternative. FPGAs are not inexpensive but the non-recurring engineering and manufacturing costs of an ASIC make them uneconomical unless the part volume is high or you absolutely need the extra performance and can pay for it.As Wurstunhund has pointed out, The LeCroy way has the advantage of always working with the entire acquisition record but I am not convinced the trade off is worth it.Quote from: Mr Nutts on July 05, 2018, 01:05:59 pmI got the feeling that HP/Agilent/Keysight uses the same MegaZoom ASIC in different models but limits performance to enforce market segmentation.

author: Berni
author_rank: Super Contributor
timestamp: July 05, 2018, 04:36:11 pm
content: I was referring to the other non PC scopes, i forgot they used the MegaZoom branding on the PC ones too.I don't think they use the same kind of MegaZoom ASIC in the PC based scopes. The ones that don't have PCs inside, 6000, 7000, X2000, X3000, X4000, X6000 etc that have the super fast update rate are a highly integrated solution where basically everything is done in a single chip. The ADC feeds the ASIC and that spits out the image to the screen while the CPU sits on the side doing its thing with the menus and i/o interfaces.The PC based scopes on the other hand are not all that highly integrated. There are many large chips with heatsinks doing various tasks and all the sample memory is external in the form of a large bank of dynamic RAM with a really wide bus to the acquisition ASICs. There are also always huge FPGAs to be frond on the board that ties all of it together and shovels the data back out to the PC.Considering they probably don't sell a whole lot of these high end scopes likely means they have a separate ASIC for the fast update scopes while the ASIC used on the PC based one is mostly just a fairly dumb shovel data from the ADC to RAM and then back out to the FPGA. Saving on R&D cost on that ASIC by making something simple that doesn't need revisions to get right while putting most of the smarts into the FPGA where they can update and patch it since these scopes are expensive so they can swallow the cost of a beefy FPGA. Those 20GS/s ADCs likely cost quite a bit more than the FPGA anyway.Oh and those 2000 waveforms/s is only under very specific conditions like 4 K sample memory, no measurements and single channel. As soon as you start turning on more features the update rate drops lower. But that's what you tend to get with PC based scopes, if you can afford a high end scope you can likely also afford a more midrange scope where you get the updates and works nicer for just quick poking around.

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 05, 2018, 06:53:23 pm
content: Quote from: David Hess on July 05, 2018, 01:11:36 pmFrom what I read it appears the principle is the same for all lecroy scopes, even the very old ones from the 1980s. They seem to be a bit like a separate acquisition box that connects to a PC, i.e. the box does one thing which is aquiring the signal and writing the sample data into its sample memory, and it's up to the PC to do something with the data. While other scopes appear to manipulate the data in the sample memory.QuoteI don't know. On college we had those Tek scopes (the ones with the built-in spectrum analyzer) and when we searched for problems we switched them into a special persistence mode (Fastac?) to look for anomalies, and when we found something we used trigger to pin it down (so we could measure it and see when the problem was gone). My first own scope was a DS1054z and I used it the same way. Then I wanted more bandwidth and bought the LT264, mostly because it was cheap. At first I couldn't get on with it so I googled around to see if I find a manual, and I found Mr Wurstunhund's messages. He seemed quite adamant that a better way to find problem in the signal than persistence mode is setting up the scope so it 'knows' what your signal is supposed to look like, and have it trigger on the anomalies. Which sounded way too difficult but I tried (I did find a manual eventually), and now most of the times I get by without persistence mode, just setup the scope with the signal parameter, and let it trigger on the anomalies. With sequence mode and history I even get a table that gives me a timestamp of each occurrence. I can also add measurements so I can see immediately what each anomaly looks like. And because it works through the trigger there's no blind time like on persistence mode.If I use the LT264 (or my 'new' LT574M) like those Tektronix scopes then I don't get very far if the anomaly is rare.If I use it the way Mr W has suggested I'm very sure I could find any anomaly in my signal no matter what right the first time it occurs.Is it's worth it, I don't know. For me it was because now I can make better use of the functionality in my scopes, and get better results faster. But it's only a some years when I left college so I have used the standard method only for a modest period of time which probably makes it easier to switch to a different method.There's obviously a learning curve. I'm good for static signals but still learning how to setup the scope for signals that are changing but I'm slowly getting there. It's amazing what these old scopes can do.I also like that I can apply some function and then try another function without the need to reacquire the signal because the original waveform is always in the sample memory.My 'new' Infinum 8064 has different acquisition modes, like the Tek scopes from college or my DS1054z. If I use anything else than normal mode then I won't get the original waveform data in sample memory.Quote from: Berni on July 05, 2018, 04:36:11 pmFrom what I've read the MegaZoom in Infinums and Infinivision(?) scopes is practically the same, the difference is that the Infinums have much more memory (up to 128M) compared to the 4M in the Infinivision scopes. I think Mr Keysight_DanielBoganoff has explained that in another thread but I can't remember which one.But based on what I read in those old Infinum scopes the waveforms are created by an ASIC and overlayed onto the Windows app. It appears the early scopes used some hardware method while newer Infinums like the 8000 use software overlays.But it appears for scopes of this class waveform rates are mostly irrelevant because they have much better tools to get the information you want.

author: David Hess
author_rank: Super Contributor
timestamp: July 05, 2018, 10:49:07 pm
content: Quote from: Mr Nutts on July 05, 2018, 06:53:23 pmFrom what I remember, LeCroy's largest market was originally in what other companies would have called digitizers or transient data recorders for applications like high energy physics where every sampled data point must be made available for processing. Maybe by the time Tektronix and HP were building DPO style DSOs, there was a patent thicket keeping LeCroy out of the market for DPO type oscilloscopes.LeCroy's method might be considered FastFrame or segmented memory on steroids and like I said, it makes a lot of sense for some applications and from a semiconductor integration point of view. I do not think it makes as much sense for design, development, and diagnostic applications.QuoteFastAcq? That is pretty recent.Originally Tektronix had FastFrame which is just their name for segmented memory and then InstaView (DPO or digital phosphor oscilloscope mode) which generates a histogram directly into the display's frame buffer. FastAcqapparently generates a histogram with a depth of 4 bitsand transfers that to the processor which gets back to my idea of generating multiple histograms with different bit depths and decimation ratios to make the most of limited memory bandwidth.QuoteThe problem is what if I do not know what I am looking for? It is not enough to trigger on everything which is not the expected signal when I do not necessarily even know what the expected signal is in enough detail. And what if I am looking for more than one thing?Tektronix actually agrees with LeCroy's view; use DPO mode until you know what to trigger on and then setup the trigger to capture exactly what you need.QuoteThat makes sense because the LeCroy has much greater blind time if it cannot trigger on the signal; at least I assume that is the case based on the LeCroy documentation that I checked. These two styles of DSO have different strengths and weaknesses so they must be used in different ways to make the most of their capabilities.QuoteI concluded that memory bandwidth will always be the limiting factor. If level 1 cache bandwidth is not sufficient, then it does not matter how fast the external memory is. If the FPGA's memory blocks are too slow, then so is the external memory bus. Note that this is trading processing required in the processor for processing at an earlier stage. The processor already has enough to do producing the display.So I wanted to find out what design could make the best use of limited memory bandwidth, whether inside of an FPGA or processor, for the least blind time and best display fidelity and designed backwards from there. I ended up with something like the Rohde & Schwarz example that I posted earlier with hardware and memory duplication for parallel decimation streams. I was thinking of implementing it on a Texas Instruments AM3358 (BealgeBone Black) which is obviously going to be pretty slow but I have to start somewhere.

author: bson
author_rank: Unknown
timestamp: July 05, 2018, 11:42:54 pm
content: Quote from: David Hess on July 05, 2018, 01:11:36 pmIt seems they make Intel CPUs use a portion of the L1 or possibly L2 cache as fast SRAM and break the acquisition record into chunks intended to fit a portion of the cache. They then apply the entire processing chain to each chunk as it sits in the cache before flushing it back out to memory. I don't know if there are any special cache controls on Intel CPUs that makes this particularly easy, but it can always be accomplished with very careful data layout (assuming code has a separate L1 cache) based on the same underlying principles as cache coloring to avoid cache contention.

author: David Hess
author_rank: Super Contributor
timestamp: July 06, 2018, 12:08:15 am
content: Quote from: bson on July 05, 2018, 11:42:54 pmDuring startup, CPUs use their cache as memory until the external memory is configured and available. I do not know if Intel supports it but some CPUs allow cache lines to be locked in place which can be used to ensure real time performance.As a practical matter, I do not think it is required in this case. The cache has enough association to avoid evictions if the programming is done correctly. Processing in cache sized blocks is standard practice for best performance for the reason LeCroy outlined; minimizing excessive access to main memory is important for maximum performance.

author: bson
author_rank: Unknown
timestamp: July 06, 2018, 12:16:55 am
content: X-Stream definitely relies on a GPU to render the actual trace, so the CPU itself is mainly used for record processing. This can be disabled, forcing a software trace render, with a rather dramatic drop in the display update rate. So it's a bit of a myth that "everything is done in software."Any x86/x64 desktop processor is going to have an L1 cache bandwidth that runs circles around FPGA internal memory blocks. I mean, as in the cheapest desktop or even mobile x64 processor is going to outperform the ballsiest FPGA out there on internal memory bandwidth. This is not surprising really since the desktop processor isn't burdened with a general-purpose signal routing fabric.So, going only on the observation that LeCroy's scheme does not generally outperform FPGAs other than at price point, it has to be about more than memory bandwidth. The fact that you can build really high tap count filters and other large discrete processing elements in an FPGA has to be an advantage. You can make most if not all measurements at full bandwidth in parallel, and I'd venture to suggest the high degree of computational concurrency to a large extent makes up for the deficiency in memory bandwidth.It also wouldn't surprise me if a run of the mill mobile or desktop processor also doesn't effectively have a faster DDR bus but I guess it depends heavily on what IP you license for the FPGA. (Again moving the price point.)

author: Berni
author_rank: Super Contributor
timestamp: July 06, 2018, 05:24:12 am
content: Well FPGA memory blocks on large chips can be very fast. Each individual memory block is usually not very fast at all, and if it was fast the FPGA fabric usually doesn't handle signals above 300MHz all that well unless you have a fancy chip. Where they get the speed is that there is a lot of them. A midrange FPGA might have 100 of these blocks and each can usually do a simultaneous write and read of 36bit at around 300MHz so that is about 1200MB/s per port or 2400MB/s for both ports combined. So when you put together 100 of those you get 240 GB/s of memory throughput. All of this throughput is random access with 1 clock cycle latency.But the kicker is that this only works when the memory is used in a distributed way where each block is connected to its own processing logic that hammers it with traffic. If you combined them into a single large block of memory where you can write and read anywhere you want then it would slow down to pretty much the slow performance of a single memory block.DDR3 memory also generally does not run very fast on FPGAs. The circuitry in the IO pins has limits to how fast it can go. Chips with hardcore IP memory controllers can go faster, but they still don't run at the ridiculous speeds that DDR3 sticks in PCs can go.Oh and CPU cache memory is often configured to be just RAM on startup even in a lot of ARMs or DSPs. Some can even be then reconfigured to only use half of it as actual cache and keep using the other half as RAM (Useful for time critical interrupt routines). But a lot of speed optimization on x86 is avoiding cache misses, the code gets designed in a way that forces the CPU to keep as little in cache as possible and data structures might be designed to fit in to cache pages neatly. You don't need to keep all your work in L1 cache for it to be fast, you just need to flush the cache rarely enough that the slow memory downstream of it can finish the operation before you need the next flush. Hyperthreading can also help by keeping the CPU busy with the other thread while this one waits for the cache miss data to get there.

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 06, 2018, 12:12:58 pm
content: Wow, this is very interesting stuff and I'm learning a lot! This is so cool!Quote from: David Hess on July 05, 2018, 10:49:07 pmAs long as I know what my signal is supposed to be and its repetitive then that's easy. I set up the triggers for glitches and runts and sequence mode and wait if the scope triggers on it. I tend to leave it alone for a while and do something else, and when I come back I can look at the history to see when each anomaly occurred. It's like a slide show.I could also use parameter masks but I haven't tried this yet.If the signal isn't repetitive then I can still trigger for anomalies but it's more complicated (and I haven't completely figured out how to do that correctly yet).If I don't know the signal then I just poke it with the scope probe to see what it is, but that would be the same with any scope. Of course I first have to find out what the signal is supposed to be before I can look for anomalies.I'm still learning how to use all those functions in these old lecroy scopes. And these scopes are old, I would bet that newer lecroy scopes have even more functions to capture stuff. But I think my Agilent 8064 could do a lot of this as well if I can get the lost options to work.QuoteThat works for anomalies that are frequent, but if it's very rare then it would take a very long time to capture it in persistence mode. And if I see it on persistence eventually I still have to setup the trigger and capture it again to get any time resolution, i.e. what is the interval of occurrence.But there are many ways to skin the dog I guess.QuoteThe update rate of my LT574M is in the region of a few hundred to a thousand updates per second. But if I go to RIS mode it jumps up to 20'000 updates per second which is a bit weird. Maybe I should try to capture a rare anomaly in RIS mode?I have no idea how that compares with contemporary scopes from the same era.Quote from: bson on July 06, 2018, 12:16:55 amIs X-Stream what they use on Windows scopes?Both my LT264 and my LT574M do have a GPU (C&T 65545 I think, very old) and from what I read it's used for display processing as well.

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 06, 2018, 12:24:24 pm
content: Has anyone seen this?https://youtu.be/Mv2QNxv3C2kHoly cow, 1.5 million waveforms per second!This lecroy scope appears to be one of the newer ones with Windows, in the description it says 2005. This is still 13 years old.But text says CPU and memory have been upgraded so this is cheatingHe's showing the results on the same scope I have (Infinum 8064), but his appears to be in much better condition (mine looks rather beaten down).

author: darkstar49
author_rank: Frequent Contributor
timestamp: July 06, 2018, 01:57:02 pm
content: Quote from: Mr Nutts on July 06, 2018, 12:24:24 pmThe Xi can't be upgraded much... Lecroy had opted for a motherboard with a PC/104-PLUS connector, tailor-made for them by BCM. These boards ever existed only with 855 and 945GME chipset, and were equipped with BGA CPU's for the 855 version, PGA for the 945.The Xi's were all delivered with Celereon M320 CPU's, the Xi-A's with Celeron's M440... (but the 945 board supported up to Core 2 Duo CPU's), anyway, lightyears away from modern CPU's...

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 06, 2018, 02:02:41 pm
content: Just imagine how fast such a scope could be with a modern CPU

author: darkstar49
author_rank: Frequent Contributor
timestamp: July 06, 2018, 04:52:51 pm
content: There's still the PCI bus which is a serious limitation at typical sampling rates... newer design, entirely based on PCIe, are orders of magnitude faster (from HDO series onwards...)

author: David Hess
author_rank: Super Contributor
timestamp: July 06, 2018, 07:58:18 pm
content: Quote from: bson on July 06, 2018, 12:16:55 amThe cache in a CPU and memory block in an FPGA essentially have the same latency; there is nothing magical about a SRAM cell on a CPU which makes it faster than a SRAM cell on an FPGA. The difference is that a CPU has an instruction pipeline load-to-use latency greater than 1 allowing pipelining of the cache accesses to increase bandwidth.So in a practical design it makes no difference; the FPGA can replicate the memory and logic blocks for increased parallelism to equal the thread and instruction level parallelism that an out of order CPU design with massive pipelined cache bandwidth has.Quote from: Mr Nutts on July 06, 2018, 12:12:58 pmThose kind of update rates are typical now for low cost designs including LeCroy's lower end models and the Rigol DS1000Z series and they all work the same way. Basic decimation is supported in hardware for things like peak detection and high resolution and then the processor is fast enough to process and display a few thousand acquisition records per second under optimal conditions.The much faster "DPO" style DSOs instead produce a histogram of what should be displayed and that is processed to produce a display.RIS (random interleaved sampling) is just another name for random ETS (random equivalent time sampling) and there is no particular reason it should have a faster waveform acquisition rate. My guess is that your LeCroy LT574M is capturing multiple RIS acquisitions into the acquisition record before transferring it for processing which is a nice way to improve performance. Most other DSOs transfer the random ETS acquisitions as they are captured and combine them using the processor which is slower unless they are operating like a DPO style DSO.Quote from: Mr Nutts on July 06, 2018, 12:24:24 pmIt looks like 1.2 million to me.I think that is with a 50 kSample record length at 5 nanoseconds/division so 100 divisions or 500 nanoseconds (only 50 nanoseconds or 10 divisions are displayed) which could support up to 2 million acquisitions per second so it is blind 40% of the time which is consistent with the trigger out duty cycle displayed on the Agilent. That is excellent performance.I would like to know more about the operating mode though. Is that with segmented memory or something else?

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 06, 2018, 08:49:06 pm
content: The average is 1.19 million but the max is 1.5 million (and everyone seems to care for max values only).As to what mode this is I think I'll send him a message on the other forumI also think I'll see what update rate I can squeeze out of my LT574M

author: Mr Nutts
author_rank: Regular Contributor
timestamp: July 09, 2018, 08:46:46 pm
content: I got a reply from Wurstunhund:Regarding the mode of the scope in my YT video, the WR64Xi was in 'WaveStream' mode. WaveStream is a mode where the scope shows an analog-style persistence screen, a bit like Tek's DPO mode but without its drawbacks. In WaveStream mode, the scope gives priority to the update rate at the cost of processing, although it runs at full sample rate and (selected) memory depth, and you can use measurements as math as on a normal acquisition.WaveStream is pretty much LeCroy's nod to Agilent who by then started to make the waveform rate a marketing argument. It also made life a bit easier for those that came from analog scopes I guess.WaveStream is an optional mode and doesn't replace the standard analog persistence, color persistence and 3D persistence modes that were already in previous LeCroy X-Stream scopes. While the latter modes are highly configurable, WaveStream is pretty simple in that it has it's own single knob (pushable encoder) which conrols on/off (by pushing) and brightness (by rotating) and that's it, like on an analog scope.My WR64Xi was 'doped' with a faster CPU with more and faster L2 cache and more RAM as stated in the video's description. The frequency counter on the Agilent scope shows a peak rate of 1.51 million waveforms per second which is incredible, especially for a scope that was made in 2005 (I guess that puts the >1M waveforms per second claims from Agilent/Keysight and R&S for their RTO in a new perspective). It's also a lot more than even the fastest analog scopes could do (which top out at around 750k wfms/s).I never checked the update rate with the standard piss-poor Celeron the scope came with. The specified update rate in WaveStream mode was specified much lower (I think the original spec was 8000 wfms/s if I remember right) but that wasn't a realistic number. It shows that LeCroy wasn't really interested in update rates.I long sold the scope (and at least partially regret it, although the WRXi wasn't the most reliable scope and of pretty poor build quality) so I can't shoot the video in better quality unfortunately, which means this is all there is. I only shot it to show it a friend, but back then there was Someone in the forum who claimed that a normal x86 architecture can't possibly reach high update rates so I put it on YT. Appears he was wrong, like on so many other things. Ah, the old times!Hope that answers your question.Good luck with the EEV forum. Just be careful, you might get banned if you mention LeCroy too often :DD

author: Berni
author_rank: Super Contributor
timestamp: July 10, 2018, 05:03:32 am
content: Interesting stuff.I wonder how this high update rate mode works under the hood as that is quite the boost to update rates from the standard mode.