azonenberg_work has quit [Ping timeout: 252 seconds]
azonenberg_work has joined #scopehal
<azonenberg_work>
miek: just finished looking through your agilent driver
<azonenberg_work>
a few comments before i merge... first, do a length check on the model number before indexing into it. Just in case we get a short one back
<azonenberg_work>
Second, it looks like there's separate settings for DC/AC and 1M/50 coupling on your scope
<azonenberg_work>
Does that mean there is an AC 50 ohm option?
<azonenberg_work>
is that something i need to start thinking about adding to my API?
<azonenberg_work>
There's a bunch of comments referring to R&S scopes, those should be fixed to refer to Agilent scopes (after confirming the things they talk about are still true)
<azonenberg_work>
Copyright dates should be updated to 2020
<azonenberg_work>
i.e. 2012 - 2020
azonenberg_work has quit [Ping timeout: 240 seconds]
maartenBE has quit [Ping timeout: 260 seconds]
maartenBE has joined #scopehal
_whitelogger has joined #scopehal
m4ssi has joined #scopehal
<tnt>
azonenberg: At least on mine AC 50R is not an option. If you switch to AC it goes back to 1M
<tnt>
And with 4M points per channels, here it's more counted in seconds/waveforms than waveforms/second ...
_whitelogger has joined #scopehal
bluezinc has joined #scopehal
<miek>
yeah, mine's the same wrt AC 50R/1M
<miek>
azonenberg: on the length check, i can do that but is there a correct way to fail in that constructor?
<_whitenotifier-3>
[scopehal] miek synchronize pull request #91: Initial Agilent 5/6/7000 series support - https://git.io/JvEus
<_whitenotifier-3>
[scopehal-apps] antikerneldev pushed 1 commit to opengl_version_check [+0/-0/±2] https://git.io/JvExM
<_whitenotifier-3>
[scopehal-apps] antikerneldev bea1a89 - Incomplete change to address OpenGL version checking, ref Issue #66
<_whitenotifier-3>
[scopehal-apps] antikerneldev created branch opengl_version_check - https://git.io/JvExD
<tnt>
miek: Why not change the string instead of adding a fixme telling what to change ...
<tnt>
miek: Also, I didn't check the perf, but if you're not in highres mode, the data is 8bit only so it might be significantly faster to download as byte instead of word ?
<miek>
tnt: i'm just not set up to test it right now so didn't want to forget :p
<miek>
tnt: yeah, good point. i should try that out
<tnt>
I'm not sure how the 6000 is but the 3000x is definitely painfully slow at downloading data :p
<_whitenotifier-3>
[scopehal-apps] antikerneldev commented on issue #66: Check Minimum System Requirements on glscopeclient startup - https://git.io/JvExN
<miek>
yeah, same. may want the option to reduce the number of points downloaded too
<_whitenotifier-3>
[scopehal] miek synchronize pull request #91: Initial Agilent 5/6/7000 series support - https://git.io/JvEus
<_whitenotifier-3>
[scopehal] miek synchronize pull request #91: Initial Agilent 5/6/7000 series support - https://git.io/JvEus
<miek>
tnt: that fixes channel disabling ^ which helps a bit more with the slowness :)
<tnt>
Ah nice :)
<tnt>
I'll give it a shot later tonigh see if I can make a quick patch to accept the 3000X that doesn't break the other models :)
<tnt>
Did the 8 bit help the download speed ?
<miek>
cool, cheers
<miek>
yep!
<azonenberg>
yeah you should use 8 bit mode unless the scope actually has a >8 bit ADC
<azonenberg>
i do the same in the lecroy driver
<azonenberg>
A lot of older scopes especially are slow for downloading, this isnt really avoidable unfortunately until we start building custom hardware
<azonenberg>
Which as you know has always been my endgame
<azonenberg>
re length check, for now just call that a fatal error and exit() after printing a message w/ LogError
<azonenberg>
we only connect to scopes early on as the app is starting up so there's not yet any state we're worried about the user losing
<azonenberg>
crashing once you start collecting data is to be avoided but early-outs seem relatively harmless
<tnt>
Only time I used 16b download was when doing a DPA attack and I was using hi-res mode (where the scope internally averages samples when going from 4Gsps to lower sample rates).
<azonenberg>
Down the road we can print a nice pop-up dialog with a full error message etc
<azonenberg>
I don't plan to support that mode for the foreseeable future
<azonenberg>
i'd rather sample full rate then do a bandwidth limiting filter in scopehal
<azonenberg>
16-bit mode makes sense for true HD scopes with a 12 bit ADC
<azonenberg>
but doing postprocessing on a scope's slow CPU seems silly when you could do it on your beefy x86 workstation
<azonenberg>
or better yet, your GPU
<tnt>
Well the advantage is you can get much longer captures which some times is needed ... at 4 Gsps I only get 1 ms at best :)
<azonenberg>
oh i see. So you're actually decimating on the scope to get a lower sample rate, you're not actually getting 4 Gsps of filtered waveform
<tnt>
yes exactly.
<azonenberg>
ok yeah that is potentially useful
<azonenberg>
But if you set the scope to sample at say 1 Gsps does it actually downclock the ADC?
<azonenberg>
does it use a wider sampling window / front end bandwidth limit?
<azonenberg>
this isnt something i've looked into
<tnt>
I have no idea what it does ... it might be jus dropping samples or downclocking ...
<azonenberg>
Something to think about when we build a scope for sure
<tnt>
but in highres mode because of increased bit depth I only have half the memory points so it's obviously different internally.
<azonenberg>
One thing i definitely want to support in my scopes is having different channels use different ADC/sample rate configs
<azonenberg>
and trigger offsets
<azonenberg>
So you can do a long, slow capture of a serial bus then full rate capture of i/o from whatever that bus configures
<azonenberg>
But rather than actually downclocking the ADC, one option is to make it so that lower rate sampling actually averages on the FPGA after sampling full rate, to prevent aliasing issues
<azonenberg>
another option would be to have some kind of variable bandwidth analog filter in the front end but that seems like it would be hard
<tnt>
yeah, fpga filtering sounds easier than variable analog magic.
<tnt>
especially with the potentially very different bandwidht involved.
<azonenberg>
So the ADC will always run at full rate in that case
<azonenberg>
no idea if that's how "real" scopes do it
<azonenberg>
i havent actually done any testing with e.g. a 100 Msps sample rate on a 2 GHz scope sampling a 1 GHz sinewave
azonenberg_work has joined #scopehal
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvuUl
<_whitenotifier-3>
[scopehal-apps] azonenberg 408330b - WaveformArea: now explicitly request GL 4.3 context with alpha, no depth, no stencil
m4ssi has quit [Remote host closed the connection]
<azonenberg>
miek: do your agilent scopes not support ground coupling?
<azonenberg>
i'm not entirely sure why lecroy has that or what it's for, the best understanding i have is that it ties the input to ground and disconnects from the AFE
<azonenberg>
it seems like something you'd only use during calibration
<azonenberg>
so supporting it via private cal commands makes sense, not so much during normal operation
<tnt>
3000X definitely doesn't have that.
<miek>
azonenberg: nope, no ground coupling option that i can see
<azonenberg>
at some point i need to add a new API for querying what coupling options a scope supports
<azonenberg>
so i can hide menu options for nonexistent modes
<azonenberg>
like DC50 on cheap rigols, or ground on your agilent
<_whitenotifier-3>
[scopehal] azonenberg commented on issue #67: Add API for querying supported input coupling modes - https://git.io/JvuUQ
<_whitenotifier-3>
[scopehal] azonenberg edited issue #67: Add API for querying supported input coupling modes - https://git.io/fjlMF
<_whitenotifier-3>
[scopehal] azonenberg pushed 21 commits to master [+4/-0/±23] https://git.io/JvuU5
<_whitenotifier-3>
[scopehal] miek 8a22aaf - agilent: Correct y offsets
<_whitenotifier-3>
[scopehal] miek 0a6a3de - agilent: Query status byte for trigger state
<_whitenotifier-3>
[scopehal] ... and 18 more commits.
<azonenberg>
miek: ok i merged your patch to scopehal core. To reach minimum usability we still need code in glscopeclient main.cpp for creating the scope object, and documentation for arguments and supported scopes
<_whitenotifier-3>
[scopehal] azonenberg commented on issue #67: Add API for querying supported input coupling modes - https://git.io/JvuUA
<miek>
thanks! you should have a PR for the first one, i'll get the docs done soon
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JvuTf
<_whitenotifier-3>
[scopehal-apps] miek 042f1aa - Add Agilent support
<_whitenotifier-3>
[scopehal-apps] azonenberg 3392c96 - Merge pull request #67 from miek/agilent Add Agilent support
<_whitenotifier-3>
[scopehal] azonenberg closed pull request #91: Initial Agilent 5/6/7000 series support - https://git.io/JvEus
<_whitenotifier-3>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JvuTk
<_whitenotifier-3>
[scopehal-cmake] azonenberg 8c3868d - Updated submodules with initial Agilent support plus various other recent fixes
<_whitenotifier-3>
[scopehal-apps] azonenberg commented on issue #66: Check Minimum System Requirements on glscopeclient startup - https://git.io/JvuTs
<_whitenotifier-3>
[scopehal-docs] azonenberg pushed 1 commit to master [+9/-0/±1] https://git.io/JvuTz
<_whitenotifier-3>
[scopehal-docs] azonenberg c7477c5 - Refactoring: split manual up into one file per section. Fixes #1.
<_whitenotifier-3>
[scopehal-docs] azonenberg closed issue #1: Split glscopeclient-manual.tex up into multiple files - https://git.io/JvE0m
<azonenberg>
miek: please pull latest docs before doing your edits, i just rearranged the file structure (see above)
alexhw has quit [Ping timeout: 255 seconds]
<tnt>
azonenberg: btw, not sure if it's my system or not, but the cmake variable LIBFFTS_INCLUDE_DIR includes the "ffts/" subdir and so I need to use #include <ffts.h> and not #include <ffts/ffts.h>
alexhw has joined #scopehal
<azonenberg>
tnt: make a ticket on scopehal-cmake, we should unify that for sure
<azonenberg>
I have /usr/include/ffts as my ffts_include_dir
<azonenberg>
so ffts.h should work
<azonenberg>
interesting
<azonenberg>
ok let me look into this
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-1/±0] https://git.io/Jvuk7
<_whitenotifier-3>
[scopehal] azonenberg 77af237 - Removed a bunch of bitrotted Cairo rendering code that's no longer being used and caused problems with new warning mode
<_whitenotifier-3>
[scopehal] smunaut forked the repository - https://git.io/JvEmZ
<_whitenotifier-3>
[scopehal-cmake] azonenberg pushed 3 commits to master [+0/-0/±6] https://git.io/JvuLz
<_whitenotifier-3>
[scopehal-cmake] azonenberg 1b11c4c - Updated to latest submodules
<_whitenotifier-3>
[scopehal-cmake] azonenberg be88109 - Updated to latest submodules
<_whitenotifier-3>
[scopehal-cmake] azonenberg e856371 - Now split build flags for debug (no optimizations, ASAN) and release. Enabled a bunch of new warnings, please try to make sure new code builds cleanly with them
<azonenberg>
Note that at the moment if you run the debug build with asan enabled, there's some new-delete type mismatch errors that cause it to abort. I haven't investigated them yet as asan has an environment variable you can set to ignore them
<azonenberg>
i believe this is a GTK issue and not something i can fix, but FYI
<azonenberg>
(since the stack trace seemed to point to some gtk code... but gtk stack traces can be somewhat complex and it's possible some of my code is in that path)
<tnt>
A few patches that make stuff work on my scope. If you could check it doesn't break yours :p
<azonenberg>
tnt: if it works on miek's scope too then let's mainline it
<azonenberg>
So at this point, what scopes do we have active users/developers working on?
<azonenberg>
we have my lecroy waverunner 8104 and hdo9204, lain/monochroma's older lecroy dda 5005, miek's mso6034a, your (whatever it is)
<azonenberg>
Does anybody have a Rigol handy? that's been a popular request but i don't have one to work on
<tnt>
MSOX 3000 series
<azonenberg>
whitequark gave me a ds1000z scope remotely some months ago and i wrote an initial test driver but it's sat there ever since as i haven't done more dev
<tnt>
the 3000-T and 2000-X should be the same (just the 2000X has less options, like no 50ohm etc ... but same protocol)
<azonenberg>
and i no longer have access to that scope
<azonenberg>
Error_404: ping, what siglent do you have? and have you tried to build current scopehal with your patches?
<azonenberg>
One priority for the mid term is getting lecroy's entry level stuff, mostly rebadged siglents, to work
<azonenberg>
they do not use VICP, it's raw SCPI over TCP, but the command set is fairly similar to that of the MAUI scopes
<azonenberg>
not quite the same so some quirks modes are needed
<azonenberg>
But i don't have access to one for testing right now
<azonenberg>
Someone on linkedin has a T3DSO which i think is basically the same platform
<lain>
I have a DSOX2024A
<tnt>
lain: you can try the tree I posted, above, should work.
<azonenberg>
lain: yours doesnt have the ethernet card though right?
<lain>
tnt: don't have the ethernet card for it yet. when that comes in I'll test
<azonenberg>
we should make SCPITransport classes for USBTMC and RS232 at some point
<lain>
I think I actually have test code for that on my workstation
<lain>
USBTMC, that is
<lain>
I could test that with tnt's tree
<azonenberg>
Great, go ahead and do that. If it works, push your USBTMC SCPITransport and close scopehal:84
<azonenberg>
then add code to glscopeclient main for parsing the "agilent_usb" driver string appropriately
<tnt>
I'm wondering if USB is any faster than ethernet for download.
<tnt>
Takes ~ 3.5s here to download 1 channel.
<lain>
oof
<tnt>
lain: well ... you have only 100kpoint memory in the 2000X so hopefully that'll be faster :) I have 4M points to download.
<azonenberg>
tnt: i assume it's a lot faster with shallower memory?
<azonenberg>
you dont have to enable full depth all the time
<tnt>
azonenberg: there is not really any UI options for that.
<azonenberg>
o_O are there scpi commands for it?
<tnt>
in SCPI you can control it though
<miek>
i just got to the hackspace, let's see if i can tunnel home & test :p
<azonenberg>
Controlling sample rate and capture depth are something i need to create an API for soon
<azonenberg>
i have ideas, it's next on my TODO once i knock out some infrastructure around file saving
<azonenberg>
once i can save files i'll probably work on that before i do loading, as loading will require some other refactoring
<tnt>
I'm not actually sure if you can control the sample rate.
<tnt>
You can change the horizontal timescale and that will indirectly affect it.
<azonenberg>
Yeah that's what i'm talking about
<azonenberg>
I think in scopehal the concept of time/div is kind of archaic and should be largely ignored
<azonenberg>
sample rate and memory depth should be the primary things you configure
<azonenberg>
then you get whatever screen config that makes on the scope front panel
<tnt>
The problem is it's not trivial to derive one from another. Basically I'd have to configure the horiz scale, run an acquisition and see what sample rate I got.
<tnt>
Acquisition at lower memory depth is definitely faster, but it's also very inconsistent. https://imgur.com/a/2aT5CIE
<azonenberg>
You're going to need to make a table somewhere of supported memory depths and sample rates
<azonenberg>
i've started doing this on the lecroy driver but i don't use it anywhere yet
<miek>
mine seems to consistently hit ~35Mbit across the wire whatever the memory depth
<azonenberg>
Since the SCPI commands usually reflect the front panel config
<azonenberg>
which is usually designed with time/div being the independent vs the dependent variable
<azonenberg>
But with glscopeclient's UI design that doesn't make sense
<azonenberg>
since viewports can be arbitrarily moved and scrolled, most of the time you do *not* want the UI window size to be controlling the acquisition
<Error_404>
azonenberg: sds1204x-e
<Error_404>
Identical HW with the exception of channels for the entire gen
<azonenberg>
Error_404: and this is the one that we think is a rebranded waveace?
<azonenberg>
or vice versa
<Error_404>
correct
<Error_404>
Well
<azonenberg>
How far did you get with your driver?
<Error_404>
IIRC it worked pending some workarounds for a couple conditions which would hang the scope
<monochroma>
Error_404: just don't hang the scope
<Error_404>
Just got off the plane/looking at it
<Error_404>
Oh thanks
<azonenberg>
Can you pull latest scopehal and see if it still builds?
<Error_404>
When I get home :)
<azonenberg>
Lol fair enough
<Error_404>
downsides of mobile irc
<tnt>
btw, stupid question but how do you scroll ?
<tnt>
(time)
<azonenberg>
tnt: click and drag the timeline up top
<azonenberg>
Scrolling to center of view with the mouse wheel is planned but not implemented
<azonenberg>
right now it just changes zoom with a fixed x offset
<_whitenotifier-3>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvuqS
<azonenberg>
tnt: so your problem is offset, not scale
<_whitenotifier-3>
[scopehal] smunaut opened pull request #92: Agilent Improvement to make it work on MSOX 3000 series - https://git.io/JvuqA
<miek>
azonenberg: also, i've got access to a rigol ds1054z. i probably won't do much dev on it, but i can test stuff out
<azonenberg>
Eye patterns right now always render with 0V as the centerline, there's a ticket (scopehal:1) for changing that
<azonenberg>
tnt: To fix this, there's a "DC offset" protocol decoder
<azonenberg>
use that to vertically shift your waveform by vcc/2 so it's centered at 0, then run the eye decode on that
<electronic_eel>
azonenberg: re table of memory depths and sample rates - do you want to dynamically build that table when first connecting to the scope or do you want to hard code it in the driver?
<azonenberg>
electronic_eel: i think we should hard code for known models, supporting a discovery method for unknown scopes might work
<azonenberg>
but i dont want to mess with scope settings more than i have to during initialization
<azonenberg>
with most scopes i've seen there's generally a standard list of frequencies and sample rates, then all you have to do is cap the table at Fmax/Mmax of the driver
<electronic_eel>
but aren't there a lot of scopes using very similar command sets, but just have different mem and speed capabilities?
<azonenberg>
and maybe add one new top entry
<azonenberg>
so for example lecroy will have a standard table for 1 Msps, 2 Msps, 5 Msps, 10 Msps ...
<azonenberg>
but then if you're on a wavesurfer 3000 series, it will cap the table at 2 Gsps and add a new 4 Gsps max entry
<azonenberg>
since it can't hit 5 Gsps which is the next standard rate
<azonenberg>
This is one of the reasons why i do ID checks as the first thing when i start up
<azonenberg>
It's not used for very much yet, but down the road a lot of more advanced configuration will have to be figured out based on which scope you're using
<azonenberg>
What we might want to do longer term is have this in data files, so you don't have to recompile scopehal to support a new device in a known family
<electronic_eel>
ok, I see, not just the scpi code is similar within a vendors offerings, but also the capabilities
<azonenberg>
and then just have a discovery app you run to figure out capabilities of the scope
<electronic_eel>
yes, data files would be the next thing I have suggested
<electronic_eel>
something the user can easily edit and is easy to load, like json
<azonenberg>
(this should not be default when you launch glscopeclient, as i don't want it to mess with your current settings if you want to use glscopeclient to view data frm your current setup)
<azonenberg>
I'm more a fan of yaml for being human readable
<electronic_eel>
no problem with yaml
<azonenberg>
My plan for save data is to have a directory for the project with a yaml file for UI setup info, then a directory for each instrument you connected to
<azonenberg>
for each instrument a yaml file with instrument setup config, then a directory for each waveform
<electronic_eel>
but not having to compile anything to add data for a new scope model would be a big plus imo
<azonenberg>
With a yaml file for metadata about the capture, and a flat binary file for waveform data
<azonenberg>
you could then tar/zip this up if needed, i may eventually add single file ui sugar around this
<azonenberg>
but internally it will be a hierarchical structure
<azonenberg>
So $project/myscope/waveform1/CHAN1.dat would be the first waveform on CHAN1 for myscope within the capture
<azonenberg>
Protocol decode config will be saved, but not actual decode contents to avoid bloating the file with stuff we can recompute fairly quickly
<azonenberg>
Anyway yes a more data driven config is likely to be the way forward once we start adding timebase config and other things that vary from scope to scope
<electronic_eel>
recomputing also helps when you improve the code later on
<azonenberg>
SCPI command sets tend to be fairly similar within a single vendor, so i generally plan to have one driver per vendor
<azonenberg>
possibly with some special casing like lecroy where the MAUI scopes use VICP and the entry level ones use raw SCPI, with some differences in command sets
<tnt>
Writing a script that creates that table by scanning all options would definitely be useful :)
<azonenberg>
yes. I just don't want that to be the power-on default
<azonenberg>
since it means changing scope settings
<azonenberg>
I want the default on startup to be no-touchy
<electronic_eel>
yes, good idea running it just when issuing a special "discover" command. also saves time
<_whitenotifier-3>
[scopehal] azonenberg pushed 4 commits to master [+0/-0/±4] https://git.io/Jvumn
<_whitenotifier-3>
[scopehal] smunaut 3264cc5 - scopehal/AgilentOscilloscope: Improve model number parsing robustness The model number don't all have the same format. Here we just strip all non-digit and then convert to int to get the model number. (and derive the number of channels) Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
<_whitenotifier-3>
[scopehal] smunaut a935f29 - scopehal/AgilentOscilloscope: Improve option parsing - This removes the "(d)" at the end of options that denote demo options - This removes the weird "0" meaningless options that the MOSX 3000 returns Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
<_whitenotifier-3>
[scopehal] smunaut c101f3b - scopehal/AgilentOscilloscope: In PollTrigger, check if armed If we're waiting for a trigger at all, then a non-run mode means nothing ... Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
<_whitenotifier-3>
[scopehal] azonenberg 36404a5 - Merge pull request #92 from smunaut/msox Agilent Improvement to make it work on MSOX 3000 series
<_whitenotifier-3>
[scopehal] azonenberg closed pull request #92: Agilent Improvement to make it work on MSOX 3000 series - https://git.io/JvuqA
<azonenberg>
So we will definitely need per family or per vendor driver code in scopehal, but i want to avoid too much per device config and move that to data files
<azonenberg>
now that we're starting to get proper data file support wrt finding files no matter where scopehal is installed
<azonenberg>
(monochroma is still working on being able to actually *install*, but we're getting there
<Error_404>
Could do a combo of text configurables for scopes and then maintain quirks on an ad hoc basis
<Error_404>
Which basically every scope with full support would have, but I digress
<azonenberg>
tnt/miek: with new scopehal-cmake config the agilent driver has a couple of warnings
<azonenberg>
can you fix those?
<tnt>
azonenberg: yeah +1 on non-touchy at boot, takes enough time to create a good trigger / capture setup with the UI and definitely don't want an app to mess it up.
<electronic_eel>
azonenberg: I have a rigol mso4000 scope. would having remote access to it help you?
<azonenberg>
It would help whoever is writing the rigol driver. Right now i don't have time to put into more driver support
<azonenberg>
But if someone wants better rigol support that would be very helpful
<electronic_eel>
ok. I wouldn't be able to keep it on for a long time since the scope is quite noisy
<azonenberg>
miek has a ds1054z and is already an active developer so we'll probably use that to finish initial rigol support
<azonenberg>
then we can play with yours to get wider model support once the time comes
<electronic_eel>
yes, that sounds like a good plan
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #68: When all waveform views are closed, adding new channel fails because there's no views to add them to - https://git.io/JvuOH
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #68: When all waveform views are closed, adding new channel fails because there's no views to add them to - https://git.io/JvuOH
<azonenberg>
well, it no longer crashes
<azonenberg>
but it makes the app unusable because there's nothing left to add waveforms to :p
<azonenberg>
Progress i guess
<azonenberg>
tnt: did you get eye patterns working with the offset btw?