<_whitenotifier-7>
[scopehal-apps] azonenberg e45831b - ScopeSyncWizard: support secondaries that do not have external trigger input by allowing user to pick which channel the sync input is using
<_whitenotifier-7>
[scopehal] azonenberg 4fd7ed9 - Initial skeleton of CDR NRZ pattern trigger (does not actually function, just a placeholder). See #237.
<azonenberg>
Ok so, i think that covers most of the multiscope fixups i needed. First half of the demo video is filmed and edited, shooting the second half later today before i send back the Siglent demos
<azonenberg>
I'm sending back the SDS2104X+ and SDS6204A and getting a SDS2354X HD (12 bit 350 MHz 2000X+ series) on saturday to test the 12-bit resolution and make sure that works properly w/ scopehal
<azonenberg>
as soon as things settle on that front, the v0.2 AKL-AV1 boards are here
<azonenberg>
so once i get all the siglent stuff out of the way i can assemble and test that
bvernoux has joined #scopehal
<Stephie>
SDS1000x-e seems to have some major bugs I need to categorize and report/patch still
<azonenberg>
The older X-E series driver is definitely not as well tested as the newer X+
<azonenberg>
so not entirely surprising
<azonenberg>
Send bugs/PRs when you've got em
<Stephie>
X-E is the newest siglent have in the low end
<Stephie>
it is a totally different commandset though it seems
<Stephie>
and different software
<azonenberg>
oh wait, that's their new low end platform?
<azonenberg>
i must be mixing it up with the older low end
<Stephie>
it's their "old" low-end platform
<Stephie>
well, its 2014
<azonenberg>
i've never used any of those, i've used 2000 and 6000 which are both the unified high end software platform
<Stephie>
but it's the newest scopes they have
<azonenberg>
basically same command set
<Stephie>
I do wonder why the software is so different between the 1000X-E and the 2000 series scopes
<Stephie>
2000+ seem all unified software
<Stephie>
both ranges run linux
<azonenberg>
It is, it's all the same team
<azonenberg>
the 1000 is probably ultra cost optimized using a different soc or something
<azonenberg>
and is a different group internally
<Stephie>
I imagine the higher end scopes are using a variety of SoCs too
<azonenberg>
We do not have as close a relationship with that team
<azonenberg>
The 2000-and-up team we have direct access to the engineering folks
<Stephie>
yeah, I need to grab a higher end scope sometime
<azonenberg>
and i mean if we had a firmware bug to report in the 1000 series i'm sure we could get them to forward it along
<azonenberg>
but it's not like i can just email the R&D manager for the product line directly and say "go fix this"
<Stephie>
but I like my 1000X-E which is nice and cheap but still has very usable software (far better than rigol's unified platform)
<azonenberg>
like we could with the 2000
<Stephie>
Either way, I'll report bugs and maybe make some patches
<azonenberg>
Great
<Stephie>
A lot of people have the entry level siglent/rigol 1000 series
<azonenberg>
Yeah. Entry level has just not been our focus because a lot of the more advanced analysis capabilities need more BW to be useful
<azonenberg>
so we don't have as big of a benefit vs sigrok or the native scope ui etc
<azonenberg>
it's still useful but not by as massive a margin
<azonenberg>
That, and the corporate entities who are interested in actually using glscopeclient for billable engineering work are most interested in funding work that's useful to them, which typically involves higher end hardware
<Stephie>
yeah, this scope's usability is mostly to add cheap extra channels with linked triggers i think
<azonenberg>
the other limitation is what the driver devs actually have access to
<azonenberg>
i mostly run lecroy gear at home for example, any other driver i write is the result of someone sending me a scope and saying "go support this plz kthxbai"
<Stephie>
yep
<azonenberg>
Like siglent is doing
<Stephie>
thats nice
<Stephie>
I have some very weird hardware I might want to write some out of tree drivers for too (unobtanium 16bit PXI scopes, weird NI gear)
<Stephie>
any scope manaufacturer willing to support glscopeclient gets sent up my list of scope manufacturers though
<azonenberg>
Yeah. So far Siglent, Pico, Digilent, and Aaronia are actively supporting the project openly, and we're in private talks with a few others that haven't yet resulted in dev scopes but are promising
<azonenberg>
We notably do not have a relationship with rigol at this time
<azonenberg>
i reached out to them a while ago but not much came of it iirc
<azonenberg>
as far as out of tree drivers, we support plugins so definitely let me know if you go that route and have any issues
<azonenberg>
i actually have a private repo with some drivers and decodes i'm not publicly releasing, at least yet
<Stephie>
I have had bad experiences with rigol's software from a basic usability perspective so they'd have to have some pretty special hardware for me to consider them
<azonenberg>
some are NDA'd or otherwise unreleasable
<azonenberg>
and one is going to go public, but not yet
<azonenberg>
i'm working with the vendor and will coordinate release when their side of it is ready (it's going to be released alongside a major refresh of their firmware)
<azonenberg>
they dont want me releasing the driver early and spilling the beans about what's coming :p
<Stephie>
neat!
<Stephie>
excited to hear who it is
<azonenberg>
but anyway, point is that out of tree plugins are very much supported and should be straightforward to set up
<azonenberg>
you can just dump the .so or a symlink to it in one of the plugin search directories and it will load at startup
<Stephie>
awesome
<azonenberg>
you can include drivers, trigger types, measurements, scpi transports, and filter graph blocks
<azonenberg>
and they all register and work seamlessly in the ui just like the native ones
<Stephie>
I hope that ends up near the top of my project list one day
<Stephie>
writing a scope driver given "here's a list of PCI registers" is going to be fun
<Stephie>
nice and low latency high-bandwidth interface for sure
<azonenberg>
the explicit intent was to allow closed source or unreleaseable/nda'd drivers and plugins for things like this
<azonenberg>
e.g. decodes i write at $dayjob for proprietary protocols
<azonenberg>
that was the original use case
<azonenberg>
but obviously there's more
<azonenberg>
the other is people using glscopeclient for bizarre signal processing applications that don't fit the normal T&M use case
<azonenberg>
in which case we dont want to clutter the menus and source tree with those filters
<azonenberg>
but they can still be open source in a separate module if people want to grab it
<Stephie>
expanding scopehal with some scripting and using it as a generic interface library is definitely something I want to look into
<azonenberg>
I'm all for building scripting wrappers around it. there's lots of fun that can be had once you have the APIs built
<azonenberg>
scripting the gui might be worth looking into one day too
<Stephie>
huh, digilent ADP5250 looks like a rebrand of my NI virtualbench
<azonenberg>
digilent is affiliated with NI
<Stephie>
yep
<azonenberg>
i think owned by them
<azonenberg>
anyway one thing that is a fairly high priority for me, but complex enough from a UX perspective that i have not touched it yet
<azonenberg>
is being able to create canned filter graphs for various use cases
<Stephie>
yeah, and a protocl perspective
<Stephie>
unless they changed it
<azonenberg>
so for example, looking at a pcie lane having one click to do CDR, thresholding, and link layer decoding
<azonenberg>
then one more button to select each of the lanes and decode up to TLPs
<azonenberg>
right now we have that capability but you have to chain like a dozen filters to make it happen
<azonenberg>
which is not the best UX in terms of getting to insight quickly
<azonenberg>
equally on a SI front i want to be able to have a canned CDR, eye pattern, TIE histogram, and jitter measurement setup
<azonenberg>
that you can just click and add
<monochroma>
just need templates
<azonenberg>
the challenge is just figuring out both at the api and the gui perspective how to build it
<azonenberg>
and doing that while also doing 300 other things :p
<azonenberg>
so if anyone wants to take on that project let me know :p
<monochroma>
less gui more tui!
<azonenberg>
In general there are a lot of major UI features that have been sitting in the issue tracker for months or years
<azonenberg>
and as basically the sole UI dev i have limited bandwidth to work on it
<Stephie>
the one weird thing that gets me about the UI is how the timebase interacts with buffer size/sample rate
<azonenberg>
as much as i love all of the PRs for backend features like drivers and decodes, frontend needs love too :p
<azonenberg>
oh?
<azonenberg>
you mean the display scale being decoupled from the record length?
<Stephie>
more like there's no visual way to go to a higher sample rate on the tbase
<Stephie>
you have to go to the timebase settings and set a higher sample rate, and thats how you "zoom in" on time
<Stephie>
zooming in the UI just zooms into the buffer without changing the capture settings
<Stephie>
which is great!
<Stephie>
but it'd be nice to have a way to visually set the capture settings
<Stephie>
unless I'm missing something
<azonenberg>
I'm open to ideas
<Stephie>
i think just some basic UI buttons near the timescale to go up/down sample rates would be helpful
<Stephie>
but hard to reconcile with multi scopes
<azonenberg>
Yeah
<Stephie>
so not sure, maybe the status quo is the best option given glscopeclient's usage mostly at a static timebase setting for advanced analysis
<Stephie>
i guess often at the highest sample rate
<azonenberg>
Yeah that is very often the case. I normally know the data rate of the signal in question coming in
<azonenberg>
choose an appropriate sample rate and record length
<azonenberg>
then spend most of my time crunching data
<azonenberg>
that's really the thing, though: we're breaking new ground in capabilities here
<azonenberg>
things like multiscope simply don't exist in any other platform
<azonenberg>
we don't know what the best UI is
<azonenberg>
the closest i've seen is lecroy's OscilloSync which works on a limited set of same-model scopes
<azonenberg>
only two
<azonenberg>
and basically turns the second into a peripheral of the first that locks to the same timebase, memory depth, cascades trigger, etc
<azonenberg>
i don't think you have independent control to the extent we do here
<azonenberg>
So these features are very much experimental and subject to change if we find a better way
<azonenberg>
I just have no idea what that better way might be :)
<Degi>
Hmh, maybe configurable GUI things like whether to show a sample rate selector
<Degi>
Could be another bar over the time scale, where you can then scroll between different settings or so
<azonenberg>
I'm open to ideas
<azonenberg>
Degi: how about you file a ticket on the tracker for 'graphical sample rate adjustment' under scopehal-apps
<azonenberg>
tag it UI
<azonenberg>
i think it's a good idea, i just dont know the best way to make it work
<azonenberg>
the coding is trivial, the graphic design is the hard part
<azonenberg>
especially wrt multiscope
<azonenberg>
possible idea: combobox on toolbar to select a scope (hidden if only one scope is active)
<azonenberg>
then box next to it for selecting sample rate and record length