electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel has joined #scopehal
<azonenberg>
bgamari_: "make install" doesnt actually work anywhere afaik
<azonenberg>
if it does work, it's never been tested :p
<bgamari_>
indeed
<azonenberg>
there is an open ticket to make it work
<bgamari_>
I ultimately concluded that
<bgamari_>
and started to fix it
<azonenberg>
any bits of installability are vestigial copy-pasted from other prjoects or something
<azonenberg>
it's not a regression, it never worked in the first place :)
<azonenberg>
Any such fixes for scopehal-apps should mention issue #142
<azonenberg>
i believe scopehal, graphwidget, and the other subsidiary libraries do not have tickets related to installation
<azonenberg>
But i will gladly take any PRs you have for them
<azonenberg>
miek: Your PR #390: does it fully implement usb 2.0 decoding? at least to the point of being usable?
<azonenberg>
i.e. does it close #43?
maartenBE has quit [Ping timeout: 265 seconds]
<_whitenotifier>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JLKJJ
<_whitenotifier>
[scopehal] miek ae9c0a3 - AgilentOscilloscope: request max points Previously, this would be left at some smaller default value and the scope would downsample the displayed points to hit that number. Instead, request all available points (but the scope will only return what is displayed).
<_whitenotifier>
[scopehal] azonenberg dc629af - Merge pull request #391 from miek/agilent_max_points AgilentOscilloscope: request max points
<azonenberg>
miek: also, what remaining to-dos are there getting the Agilent driver to "minimum viable functionality" level for at least your scope?
<azonenberg>
as in what's left before we can close #14?
<azonenberg>
bgamari_: if you want to work on installability, what i would love is for you to add CPack integration
<azonenberg>
(scopehal-apps:#141
<bgamari_>
sure
<bgamari_>
I'll add it to the list
<azonenberg>
Once "make install" works, adding CPack should just be a few dozen lines of code in the CMakeLists specifying package name, dependencies, etc. I think it probably makes sense to have one package "libscopehal" for scopehal/scopeprotocols and the related stuff
<azonenberg>
and "glscopeclient" for glscopeclient
<bgamari_>
I ended up getting a bit stuck on figuring out how to find data files at runtime
<azonenberg>
i was about to say, yes
<azonenberg>
We need to figure out a way to properly do that. That's probably the #1 blocker
<azonenberg>
right now we chdir to the glscopeclient binary directory and expect to find everything there
<bgamari_>
indeed
<azonenberg>
That is not a proper long term solution
<bgamari_>
clearly not the right solution
<bgamari_>
yeah
<azonenberg>
My suggestion is to have a function to find a data file, probably in libscopehal
<azonenberg>
which checks the following locations in order
<azonenberg>
that would bump you from e.g. /usr/bin to /usr/share or /usr/local/bin/ to /usr/local/share/
<bgamari_>
right
<bgamari_>
that sounds sane
<azonenberg>
With the bin dir being a fallback for development
<azonenberg>
it needs to be ahead so the local copy is preferentially used
<bgamari_>
sure
<azonenberg>
Let me actually make a separate ticket for that
<azonenberg>
Installation depends on it but they're really separate issues
maartenBE has joined #scopehal
<_whitenotifier>
[scopehal] azonenberg opened issue #392: Proper path resolution for data files - https://git.io/JLKUJ
<bgamari_>
thanks!
<_whitenotifier>
[scopehal-apps] azonenberg opened issue #302: Proper path resolution for data files - https://git.io/JLKUm
<_whitenotifier>
[scopehal-apps] azonenberg labeled issue #302: Proper path resolution for data files - https://git.io/JLKUm
<azonenberg>
And the complement issue on glscopeclient side
<azonenberg>
bgamari_: also once this is fixed we will be able to remove the chdir(glscopeclient bin dir) at startup
<azonenberg>
which means "glscopeclient foo.scopesession" will work with relative paths
<azonenberg>
right now you have to use absolute paths
<bgamari_>
indeed
<azonenberg>
or relative paths *relative to the install directory* rather than where you are now
<bgamari_>
after installation is taken care of I may have a look at R&S support
<azonenberg>
but hey, it beats the "chdir to /nfs4/home/azonenberg/code/scopehal-apps/release-build/src/glscopeclient/" that i had this time last year
<azonenberg>
yes, it was an absolute path on my nas
<bgamari_>
I'm curious to know how the RTB2004's SCPI support fares
<bgamari_>
heh
<azonenberg>
That's how far we've come in the past year or so
<azonenberg>
oh and i guess scopehal-docs would be sensible to have a package of its own
<azonenberg>
with the compiled pdf
<azonenberg>
I would love to have an alpha level set of linux binary packages in the not too distant future that we can start posting nightly/weekly builds of
<azonenberg>
Once we have that, and some more complete documentation coverage on documentation, we can start thinking about making decisions on what it will take for an official v0.1 release
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
<miek>
azonenberg: setting sample rate/depth - i'm still doing that on the front panel at the moment
<azonenberg>
OK. Is that the only thing missing?
<azonenberg>
(that you know of)
<miek>
that's the only thing i'd mark as minimum viable functionality. other stuff would be: digital channels, more triggers, etc.
<azonenberg>
yeah those are later
<azonenberg>
So in that case i guess that should be your next priority if you don't have something else more urgent to work on
<azonenberg>
as far as the USB stuff goes, is it at minimum viable functionality for usb 2.0?
<azonenberg>
(and have you tested your changes to not break usb 1.x?)
<miek>
the only thing missing there is that the sync logic won't pickup a short preamble (when going through a hub), otherwise i think it's good
<miek>
and yeah, full speed is working still here. i haven't got a low speed device to check, do we have any scopesessions for it?
<azonenberg>
miek: #361 has a CSV linked
<azonenberg>
you should be able to just run "glscopeclient file.csv"
<azonenberg>
then save as a scopesession
<azonenberg>
(I need to figure out the timing issue on that still, sorry codysseus. Might look at it in the next few days)
<azonenberg>
miek: actually if you want to look at it since you're doing stuff on the usb decodes
<azonenberg>
the gist of the bug is "some usb packets overlap"
<azonenberg>
as in they end after the next one starts
<azonenberg>
so duration is set wrong somewhere
<azonenberg>
He's got some test code that reproduces it
<azonenberg>
i found and fixed a few situations that could cause that but clearly didn't get em all
<_whitenotifier>
[scopehal] miek commented on pull request #390: USB high-speed decoding - https://git.io/JL6Ok
<azonenberg>
miek: i added glitch filtering a while back to fix the spurious SE0/SE1 states on slow edges
<azonenberg>
It might not have been aggressive enough?
<miek>
i modified it in that PR because it was too aggressive for high-speed, but maybe i screwed something up in the process - i'll have a look
<azonenberg>
Revert to what i had, confirm it works for low speed
<azonenberg>
There's a reason that the PMA decoder has to know what speed you're using
<azonenberg>
If you have to adjust glitch thresholds for each speed go ahead and do that
<miek>
oh, i'm dumb, i think i just had the speed set wrong when i tested
<azonenberg>
Lol
<_whitenotifier>
[scopehal] miek commented on pull request #390: USB high-speed decoding - https://git.io/JL6np
<azonenberg>
So do you think this is good to merge now?
<_whitenotifier>
[scopehal-apps] azonenberg 81fa6c6 - ProtocolAnalyzerWindow: Fixed bug where RemoveHistory() would trigger spurious clicks and mess up the cursor position
<miek>
azonenberg: done :)
<azonenberg>
miek: Any interest in doing usb3 some time? i can get you a few gigs of data from a pi4 easily enough
<azonenberg>
and we already have an 8b10b decode
<azonenberg>
you'd just have to do the glue that goes between 8b10b and the upper layers
<azonenberg>
(not sure how much the upper layers differ vs 2.0)
<miek>
maybe at some point, but i don't think it'd be any time soon
<azonenberg>
Yeah i dont have an immediate use case for it
<miek>
oh also, while i was working on the usb stuff i saw something interesting. one of my cables seems to be just starting to fail: https://imgur.com/a/LTEa8nm
<miek>
seems like it's attenuating higher frequencies on D-, not sure what would cause that. it'd be interesting to get it on the TDR at some point
<azonenberg>
interesting
<azonenberg>
damaged insulation maybe? pinch in the wire causing it to capacitively couple to ground?
<azonenberg>
miek: oh, when you get a chance
<azonenberg>
can you send me some benchmark numbers for WFM/s with glscopeclient on your scope? with no processing, just displaying waveform data
<azonenberg>
1, 2, and 4 channels at a few different memory depths
<azonenberg>
i'm trying to build out a database of how different scope/driver combos stack up
<azonenberg>
S ofar lecroy is winning by a landslide. i have high hopes for pico though
<azonenberg>
And obviously there is room to optimize drivers as well potentially
<agg>
i guess this conversation has already happened, but any reason the agilent driver isn't named keysight? maybe it could be aliased? it's been a long time since agilent have made oscilloscopes
<azonenberg>
agg: Because all currently supported models are originally agilent made
<azonenberg>
Some of them have since been rebranded keysight
<azonenberg>
but they're still agilent designs
<agg>
agilent designed, maybe, but keysight made these days
<azonenberg>
I wanted to hold off on renaming the driver until i had tried some more recent designs
<agg>
fair enough
<azonenberg>
i have no idea how much the protocol has changed over time
<azonenberg>
lecroy in particular has an extremely stable API going back to at least 2005
<azonenberg>
one driver works with everything. no quirks
<azonenberg>
some have special features others lack, and we still have to hard code a table of legal memory depths and sample rates because we haven't found any way of getting that info programmatically
<azonenberg>
but no special cases where you need different syntax for setting a trigger on one model vs another etc
<agg>
all I have to offer is an mso3k which is also originally aglient designed so not much help there
<azonenberg>
Rigol, on the other hand, seems to use a new protocol for each family :p there's some commonality but lots of quirks handling
<azonenberg>
I also have a Tek MSO64 on loan for the holidays. so i've been doing some performance tweaking on it
<agg>
though on the bright side the DSOX/MSOX 1/2/3/4/6k are all the same protocol aiui and also haven't really changed in a decade+
<agg>
yea, I've been following your ethernet woes
<azonenberg>
but so far it's not looking good. the scope firmware is just not very stable, if you do anything the slightest bit off what it expects it will hang for several seconds, discarding all inbound commands
<agg>
it sounds kind of hideous
<azonenberg>
and it can't accept command queueing at all
<azonenberg>
i got a lot of performance out of the lecroy driver by sending it several commands, not waiting for round trips, then reading responses
<azonenberg>
the tek thinks it's still on GPIB or something
<agg>
i've had much better experiences with ethernet on other keysight equipment (counter/timer, PSU, dmm) but haven't needed to do more than grab screenshots from the msox yet
<azonenberg>
if you send it a command while it's still sending you the results from the last one you know what it does?
<azonenberg>
it aborts, sends a "command interrupted" message to the event log
<agg>
helpful of it
<azonenberg>
then hangs for several seconds without accepting any commands
<azonenberg>
yeah :p
<agg>
you can tell they really designed it for automated use huh
<azonenberg>
Yeeeah
<azonenberg>
I'm extremely glad i didn't buy one of these. because they look absolutely awesome if all you do is use the front panel interface
<azonenberg>
but the automation friendliness is awful
<agg>
admittedly I have mostly used my scope via the front panel whereas dmm and counter are almost entirely automated
<azonenberg>
what's sad is, the scpi protocol they have is quite nice
<azonenberg>
it's very orthogonal compared to lecroy's
<agg>
just very poorly implemented tcp/ip handling?
<azonenberg>
the commands are cleaner, there's no tunneling vbscript inside scpi to set com automation variables
<azonenberg>
i wish i was kidding
<azonenberg>
also tek's logic analyzer just gives you sample data
<azonenberg>
lecroy gives you an XML dump with a <BinaryData> tag containing base64 coded samples
<agg>
fantastic
<azonenberg>
But despite their awkwardness, lecroy's stuff *works*
<azonenberg>
and it's fast
<azonenberg>
6+ times faster than the mso6 under the same channel config and memory depth
<azonenberg>
So the MSO6 is getting 500K * 4 = 2M points @ 3.85 Hz = 7.7 Mpts/s
<azonenberg>
the waverunner is getting 8M*2 = 16M points @ 3.15 Hz = 50.4 Mpts/s
<azonenberg>
that's just one data point but the difference is staggering
<azonenberg>
Sample rate on th escope doesnt matter as long as it's high enouhg you spend most of your time downloading the data rather than capturing it
<azonenberg>
For high speed do relatively few points, a few thousand, on one channel
<azonenberg>
then turn on all channels with a few points
<azonenberg>
then one channel with a lot of points, all channels with a lot
<azonenberg>
maybe a few other data points in between
<azonenberg>
also mention which interface you were using, some scopes may have different performance for say usb vs ethernet
<azonenberg>
turn off all measurements, decodes, etc on both the scope and glscopeclient to avoid CPU overhead that might slow it down
<agg>
1ch x 2.5kS: 3.3WFM/s, 1ch x 2.5Ms: 1.0WFM/s, 4ch x 2.5kS: 2.5WFM/s, over ethernet inside glscopeclient, hmm
<azonenberg>
what scope?
<agg>
MSOX3104T
<azonenberg>
and that's an agilent?
<agg>
yes (well, this unit was always keysight, but yes)
<azonenberg>
Can you do a 2.5M /4ch test too?
<agg>
4ch, 2
<agg>
uh, I mean, no, because it's 4M samples per two channels total memory
<azonenberg>
ah ok
<azonenberg>
Max memory on 4 channels then?
<agg>
but at 4ch 2Ms each it's 0.5WFM/s
<azonenberg>
Interesting. That's not tooooo slow considering it's 8M points total
<azonenberg>
but i'm amazed at how little it speeds up with shallow memory
<azonenberg>
seems there's a huge constant overhead
<agg>
receiving about 23Mbps average
<_whitenotifier>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JL6HL
<_whitenotifier>
[scopehal-docs] azonenberg 07176e0 - Added performance benchmarks from MSOX3104T
<agg>
wonder if the limit is how fast you can turn around arm, check if triggered, re-arm, rather than scooping up the data itself
<azonenberg>
Possibly
<azonenberg>
I also dont know how well the agilent driver is optimized
<azonenberg>
having a look at a packet capture might shed some light on that
<agg>
yea, I might have a quick play at talking to it directly and see how fast I can turn around
<azonenberg>
well i mean specifically latency from request to response to next request etc
<agg>
I had a brief look but wasn't enlightened, lots of polling for instrument state
<azonenberg>
I can say i tried many of the optimizations i did with lecroy on the tek mso64
<azonenberg>
and every single one crashed it :p
<miek>
mine does around 25WFM/s with 1ch x 4kS btw
<azonenberg>
miek: what scope is that
<miek>
mso6034a
<agg>
huh, I thought they were somewhat similar hardware
<agg>
maybe 3k/4k are and 6k is not
<azonenberg>
OK. If you have a chance to get me more complete benchmark data for 1 and 4 channels at short and maxed-out or at least reasonably deep memory
<azonenberg>
that would be helpful
<miek>
(not x-series)
<agg>
ah, yea
<miek>
have you got something fairly quick to trigger on? auto trigger adds some delay for me
<azonenberg>
Auto trigger AFAIK is normally implemented as a normal trigger with a timeout
<azonenberg>
so that would make sense
<agg>
I currently have trigger set to edge, rising, 0v, normal, dc, no NR/HF, 40ns holdoff, and ch1 is being fed with a 10MHz sine wave from the onboard generator
<azonenberg>
yeah sounds like just a slow scope
<azonenberg>
miek: anyway yeah i'd love more performance data when you get a chance
<miek>
yeah, will do
<miek>
there's a few odd results on mine, like cases where adding a channel or increasing depth increases WFM/s
<_whitenotifier>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JL65Y
<_whitenotifier>
[scopehal-docs] azonenberg 3797b5e - Added MSO6034A performance data
<azonenberg>
Any Rigol users want to submit some performance stats while you're at it? MSO5000 specifically
<azonenberg>
So i'm benchmarking my lecroy scopes and yeeesh
<azonenberg>
the HDO9204 is sloooow at 4 chans * 64M points lol
<azonenberg>
Althoguh honestly 0.12 WFM/s for that much data is not too bad
Degi has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
<azonenberg>
That's 256 Mpoints * 0.125 WFM/s = 32M points/sec. And the HDO is reading 16 bit samples (I should optimize this at some point because when HD mode is off I only need 8 bit)
<azonenberg>
So it's pushing 512 Mbps plus protocol overhead. which is respectable
<azonenberg>
My GPU isn't thrilled at me rapidly scrolling and zooming 256M points of waveform either lol. I should probably try and optimize some of the rendering code paths at some point too
<azonenberg>
the shaders are likely not nearly as fast as they could be
<_whitenotifier>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JL6ja
<_whitenotifier>
[scopehal-docs] azonenberg 668f0f0 - Added lots more performance data
<_whitenotifier>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JLifb
<_whitenotifier>
[scopehal-docs] azonenberg 9e8fae8 - Reformatted performance data for Tek MSO6
<agg>
azonenberg: compared to about 3.3WFM/s in glscopeclient, I can get about 5.3WFM/s in a tight loop with queueing asking the scope to acquire/download/repeat, so it doesn't look like there's that much room for improvement
<agg>
(1ch x 5kpt)
<agg>
I say "digitize now", 0.2 seconds later it TCP ACK's and I can go ahead and download data, which is quickish, I ask it to digitize again, another 0.2s before the next ACK
<agg>
if I don't actually download the data it's pretty steady 5.3WFM/s just triggering it as fast as it can digitize and become ready
<azonenberg>
So that's just polling, not even downloading data?
<azonenberg>
the 5.3
<agg>
yea
<agg>
not even polling
<azonenberg>
sounds like most of the delay is the cpu being saturated scope side then
<agg>
there's a blocking command "digitize" which arms, triggers, acquires, then becomes ready to process the next command
<agg>
so I run digitize and then *OPC? and wait for the single byte response
<agg>
if you send anything while it's running a blocking command like :DIG it queues it and responds afterwards
<agg>
the manual suggests this is the best command to use to remotely grab some data and look at it, but I'll see if single triggering is any better
<azonenberg>
meanwhile if you send anything to a tek mso6 while it's running a command
<azonenberg>
Bad Things (tm) happen :p
<agg>
on this scope only autoscale, digitize, fetching waveform data, and saving waveform to memory are blocking and other commands queue behind them, everything else you can just send commands and it will process them in-order as fast as it can
<azonenberg>
Yes, that's how sane scopes work
<azonenberg>
the tek seems to have no input buffer
<agg>
question is whether there's a good way to :SINGLE and check if it's triggered and download the data and repeat and be any faster than the convenient :DIG
<azonenberg>
it even sometimes fails if you send two *set* commands back to back if they get merged into the same tcp segment
<azonenberg>
lol
<miek>
btw, the reason i don't use :DIG in the driver is that it will just block forever if it's in a state where it can't trigger
<agg>
unhelpful
<agg>
you can abort it, right? but a bit of a chore
<agg>
using :SINGLE and then checking :AER? in a loop is very marginally slower, 5.0WFM/s
<agg>
so probably there's not much scope for improving WFM/s here
<agg>
depending on the objective you could do a segmented capture, take 10 acqusitions, transfer them all in one block, might be quicker
<agg>
but wouldn't help responsiveness, just means more waveforms if you want to build up an eye diagram or something... probably better to just do one longer capture
Degi has joined #scopehal
bvernoux has joined #scopehal
<bvernoux>
hello
<azonenberg>
o/ bvernoux
<bvernoux>
I have just received the amazing LambdaConcept ECPIX-5 45F (I'm waiting the big version 85F soon)
<bvernoux>
very nice dev board to test tons of fast peripherals with nMigen ...
<miek>
nice
<bvernoux>
azonenberg, I was ultra busy last week so I was not able to work on scopehal-apps/glscopeclient ...
<bvernoux>
I just saw there is USB HS decoder now
<bvernoux>
it is very nice to check the limit of my Rigol MSO5000 BW ;)
<bvernoux>
In theory it reach more than 500MHz BW so it shall be able to capture and decode correctly USB 2.0 HS stuff ;)
<miek>
yeah, should work as long as you've got some good probes. i'm using it on my 300MHz scope (measured at ~450MHz -3dB iirc)
<bvernoux>
I think my default scope probe shall be enough even if they have about 10pF at 10x
<azonenberg>
bvernoux: also i would love some performance data from your MSO5000 with the current rigol driver
<azonenberg>
set to different memory depths and number of channels
<azonenberg>
and let me know WFM/s you get
<bvernoux>
azonenberg, ha yes
<bvernoux>
azonenberg, I have updated my test code with such benchmarks too
<bvernoux>
to have full details
<bvernoux>
which shall be the same with glscopeclient
<bvernoux>
as code is very similar except glscopeclient does not have my robustness code to recover in case data are missed (especially for 1Mpoints or more)
<bvernoux>
that features requires raw bsd socket access
<bvernoux>
as I'm using a hint to catch that without waiting for a timeout ...
<bvernoux>
the fun is I have found a workaround to do not miss any waveform data ;)
<bvernoux>
just use FFT and that prevent any missing data especially for chan1
<bvernoux>
that help to synchronize internally between oscilloscope and SCPI ...
<bvernoux>
especially for 1Mpoints, 10MPoints, 25Mpoints even tested 100Mpoints (on 1 chan)
<bvernoux>
stats with 100Mpts 8GSPS => Acq Time min=16.3900s, max=17.1300s, avg=16.6266s(5.736 MBytes/s), nb_waveform_cnt=20, nb_total_acq_failed=0
<bvernoux>
so the scope is limited to about 5.7MBytes/s ...
<bvernoux>
ha yes clearly better and the data can be decoded with such signal I think
<bvernoux>
there is 20mV margin to distinguish 1 vs 0
<bvernoux>
200mV
<bvernoux>
so it means main issue is towards ground which requires spring ground to have acceptable USB 2.0 HS signal with a "normal" 10x passive probe
<bvernoux>
what is strange is signal on top vs bottom seems to be not the same
<bvernoux>
I was expecting D+ & D- ?
<bvernoux>
or maybe you probe different USB 2.0 HS bus ?
<miek>
yeah, it is D+ and D- on the same bus. there's a bit of skew between them
<bvernoux>
2GS/s seems the low limit to capture correctly 480MHz too (you have just a div/4 to recover 480MHz)
<miek>
it's 480Mbit DDR, so 240MHz fundamental
<bvernoux>
does your driver work with only D+ or D- ?
<bvernoux>
or does it need differential ?
<miek>
it needs differential
<bvernoux>
with a not too bad signal just D+ or D- shall be enough to decode correctly anyway diff is a must of course
<bvernoux>
azonenberg, does you have tested the USB 2.0 HS with your scopes ?
<bvernoux>
azonenberg, the shame for Rigol MSO5000 is 10kpts is as slow as 100kpts and 1Mpts is not far ...
<d1b2>
<TiltMeSenpai> it's interesting that the mbytes/s is going up even though the capture times are getting longer
<d1b2>
<TiltMeSenpai> wtf is their scpi stack doing
<bvernoux>
yes their SCPI stack is ridiculous ;)
<bvernoux>
we see it is coherent anyway between 25Mpts 4Chan vs 100Mpts 1Chan with pratically same time for the acquisition ...
<bvernoux>
the same for 50Mpts 2chan
<bvernoux>
what is crazy slow is 10kpts vs 100kpts or 1Mpts
<bvernoux>
we should expect at least 10WFM/s for 10kpts
<bvernoux>
and we have only 1 !!
<azonenberg>
TiltMeSenpai: not like Tek's is much better
<azonenberg>
So far the scopes i've seen that perform at what i would consider a usable level with glscopeclient are miek's agilent and my lecroys
<azonenberg>
the tek mso6 can get to acceptable framerates on really shallow waveforms but if you make remotely large it chokes
<azonenberg>
and at *best* it gets about 10 WFM/s on really tiny waveforms
<bvernoux>
Rigol SCPI management is clearly wrong as such performances cannot be explained because the Zynq7020 is too slow ...
<bvernoux>
azonenberg, ha interesting I was thinking latest MSO64 was clearly better like 25WFM/s ...
<bvernoux>
so it is clearly disappointing for such high end new scope
<bvernoux>
which are sold because they are intended to be "very" fast even remotely ....
<bvernoux>
will be interesting to check high end KeySight scope
<bvernoux>
as they are top of the art for GSPS and technology ...
<miek>
i think it's just dumb luck as to what works well. it doesn't matter how good or new the scope is when they're not aiming for realtime streaming over SCPI
<miek>
i think the manufacturers only intend for people to export a one-shot to excel or matlab
<bvernoux>
yes when it is not deisgned to be fast over SCPI it is not but KeySight are very high end so it will be interesting to know if SCPI is fast with >20WFM/s ...
<bvernoux>
I think the best so far are PiscoScope with USB 3.x ;)
<bvernoux>
to be confirmed when noopwafel will have pushed the picoscope beta driver for test
<bvernoux>
I have done my own C code using Pico3000 API and we can push the scope in realtime to 200Mpts/s
<bvernoux>
which is clearly very far from any "normal" scope available today
<bvernoux>
in theory Picoscope3000 can push data at 500Mpts/s
<d1b2>
<noopwafel> yeah uh very happy I chose to buy a picoscope atm, given lecroy is way out of my budget