<_whitenotifier>
[scopehal-apps] lain dd4f4a2 - Fix unit tests
<_whitenotifier>
[scopehal-apps] lain e335b92 - Merge branch 'master' of github.com:glscopeclient/scopehal-apps
<lain>
hm
<azonenberg>
lain: confirmed tests now compile and pass on my x86 / linux / nvidia box
<lain>
yeah, just double-checked on my amd box
<d1b2>
<louis> I don't know if this is a known issue, but I (still) need to put cmake target_link_libraries(scopehal SPIRV SPIRV-Tools-opt SPIRV-Tools ) at the end of the root CMakeLists.txt (or somewhere else, I'm sure) to get stuff to build on my box
<azonenberg>
hmmmm
<azonenberg>
what vulkan sdk version? installed from package manager or what
<d1b2>
<louis> SPIRV-Tools v2022.1 v2022.1
<d1b2>
<louis> and yes, vulkan from arch package manager
<d1b2>
<louis> also, azonenberg: can we pick a semantic for what channels to open when connecting a scope and make it consistent between gn and gl?
<d1b2>
<louis> gl currently wants to display all analog channels of the first scope you connect, and then only those enabled of subsequent scopes you connect
<azonenberg>
@louis: Yes. The behavior I am trying to standardize on is:
<d1b2>
<louis> ng seems to have the show-only-those-enabled behaviour for any scope regardless of connection order, plus special behaviour for headless
<d1b2>
<louis> I would like to standardize on the ng behaviour personally
<azonenberg>
1) If the scope has at least one currently enabled channel, show all enabled channels
<azonenberg>
2) If there are no enabled channels, enable the first analog channel
<azonenberg>
3) If it's a headless scope, enable all analog channels (this may change to only be the first, TBD)
<azonenberg>
i thought that got backported to gl
<azonenberg>
if not, it should be
<d1b2>
<louis> also, on the subject, i would like to bikeshed about what channels we display by default in the filtergraph
<d1b2>
<louis> is there a reason to display disabled channels?
<azonenberg>
yes
<azonenberg>
we refcount channels and enable them as soon as you connect a load to them
<azonenberg>
that said, there is an argument that perhaps we should hide them and then have some way to add them as needed
<d1b2>
<louis> I would much prefer that
<azonenberg>
especially with things like the tek mso that have so many ancillrary channels for digital etc
<d1b2>
<louis> current UX pain point is having 6 channels * 2 (analog, spectrum) show up in every session connected to our Tek
<azonenberg>
Yes
<d1b2>
<louis> yeah exactly
<azonenberg>
one strategy i have thought about but not had time to prototype is to make it so that if you drag from the *input* of a filter block to empty space, a menu pops up with a list of channels you can enable and instantiate
<d1b2>
<louis> Just patched to not display channels where !CanEnableChannel
<azonenberg>
Well ok
<azonenberg>
so theres two different things
<d1b2>
<louis> So that's down from 6*10 (analog, spectrum, 8x digital)
<azonenberg>
the first is to not display cannot-be-enabled channels
<azonenberg>
i.e. digital channels when no mso probe connected
<d1b2>
<louis> yes
<d1b2>
<louis> i just did that :p
<azonenberg>
that's an easy, no doubt fix
<azonenberg>
i'll take a PR for that whenever
<azonenberg>
the second is, hiding channels that can be, but are not currently, enabled
<azonenberg>
which raises the question of how we want to present UI for enabling them
<azonenberg>
drawing from input of a filter to empty space is one possible path but this only works once you have a filter to draw to
<azonenberg>
so its not a good choiec for starting from a blank slate
<azonenberg>
maybe right click on empty space to add a channel
<azonenberg>
i have ideas, just havent tried them all out yet
<d1b2>
<louis> I rarely set up my filters from the graph window, so I usually just do Add -> Channel -> ... and then right click -> add filters
<azonenberg>
Yes. i used to do that in glscope
<azonenberg>
but in ngscope the graph window is much nicer
<d1b2>
<louis> and then delete the items earlier in the chain from the view when i don't need them
<azonenberg>
and i intend for it to become a primary flow
<azonenberg>
so i want to design UI to make that a smooth, pleasant task
<d1b2>
<louis> Another thought is a right-click -> add channel in the filter graph, and then have the node in the filter graph editor be a reference to keep it enabled while open
<d1b2>
<louis> Or actually, probably no reason to enable unless the user adds a filter to it or displays it in the window
nelgau_ has quit []
<azonenberg>
yeah just the graph should not hold a reference
<azonenberg>
that said, as of right now in ngscope, creating a filter instance in the graph will also add a view for it
<azonenberg>
if you then delete the view it disappears from the graph
<d1b2>
<louis> Understood. I will dig deeper on why the DPI scaling in imgui isn't working right [for me] at a later date... needed to make it big enough to work with today :p
<azonenberg>
But yeah in general the whole stack should be dpi aware and if it's not, fix that
<azonenberg>
most likely we have to do exactly what you did there, just scaled by the DPI vs a new env var
<_whitenotifier>
[scopehal] 602p c0a7506 - Fix bugs causing Tektronix driver to enable all channels and display spurious digital channels
<_whitenotifier>
[scopehal] azonenberg ad0414b - Merge pull request #733 from 602p/tek_dont_enable_all_channels Fix bugs causing Tektronix driver to enable too many channels
<d1b2>
<louis> Probably more in the thread of DSP stuff for a work project, and UX improvements stemming from M's dogfooding :p
<azonenberg>
ah ok. And yeah i saw his video lol
<azonenberg>
but hey, it's working well enough he can complain about it *on his m1 mac*
<azonenberg>
so that's progress lol
<d1b2>
<louis> the tek enabling 60 channels by default is one such UX issue lol
<azonenberg>
lol yes
<azonenberg>
So, quick update since we didnt have a dev call this month (holidays made it hard to schedule one)
<azonenberg>
we wrapped up lain's contract doing the macos porting, i'm still mostly working on ngscopeclient
<azonenberg>
i finished all of the core protocol analyzer dialog features other than wireshark-style filter expressions
<azonenberg>
which will be ported over from glscopeclient with some tweaks to the grammar to make it more powerful
<azonenberg>
missing features holding us back from feature parity are horizontal cursors (easy but not a high priority), multiscope sync (needs a new wizard + vulkan accelerated correlation kernel written)
<azonenberg>
a dialog for configuring trigger settings
<azonenberg>
export to common interchange formats
<azonenberg>
and scopesession load/save
<azonenberg>
we currently support multiscope (although it's lightly tested) however there's no sync wizard yet
<azonenberg>
And then i have a long list of new features i want to add that are tabled because i'm focusing on the more important bits first
<azonenberg>
My current plan is to try and get an extension of lain's contract and put her on the scopesession load/save while i finish the protocol analyzer and then move on to trigger settings
<d1b2>
<louis> sounds good
<d1b2>
<louis> I think for my use the scopesession load/save is the highest priority thing still missing
<azonenberg>
Yes agreed
<azonenberg>
which is why I wanted to put lain on it since she has the most experience with some of that low level frontend code other than me
<azonenberg>
and i have too many other things on my plate
<azonenberg>
scopesession load/save is the single key blocker stopping me from using it for real work
<azonenberg>
Ultimately i want a couple of experienced frontend developers to work on ngscopeclient other than just me
<azonenberg>
the vast majority of community contributions have been focused on drivers and filters
<azonenberg>
and while backend is useful, we need a ui too :p
<azonenberg>
(also waiting on CI checks before merging 546 and 548, but they look good at a visual inspection)
<d1b2>
<Code and Solder> I'm here as invited (jan_gronska on Twitter), short summary on my progress: - Koaxis wanted to charge me $40 for the privilege of taking my money (and unspecified shipping) so I have two different cheap SMPM cables on the way from China, on paper seem pretty much identical for ~1/3 the price, should be here Tuesday-ish - parts and PCBs for AV1 and AD4 are here, waiting to be assembled - PCBWay is willing to sponsor me some fancy RF
<d1b2>
laminate or flex PCB, I'm thinking about a version of AD4 with input resistors on flex
<azonenberg>
Yeah I cannot comment on other cable vendors. The big reason I went with Koaxis is the excellent performance of KF047 cable and the fact that they'd do VNA testing of the cable at the factory and ship serialized s-parameters
<azonenberg>
you are unlikely to get that from a low cost chinese supplier although i'm sure if you know the right guys someone will do it
<d1b2>
<Code and Solder> Random notes: - metal etching is surprisingly cheap, for RF shields and like - same with custom cable harnesses and the like, even complex stuff is usually under a dollar, with MOQs ~100 - from a quick inquiry seems getting the tip resistors made from SMD parts on the cheap is also doable
<azonenberg>
So we are actually looking at overmolding tip resistors in house
<azonenberg>
specifically because the vishay HMLs we had yield issues with
<azonenberg>
active experimentation is ongoing, probably using a vishay CH0402 series resistor as the base
<azonenberg>
but figuring out the exact material and gauge of wire ot use etc is nontrivial
<azonenberg>
this is one of the reasons i made that tip testing fixture with the separate signal and ground contacts
<azonenberg>
the one that you apparently got before me, mine is in the post office in seattle and won't arrive until tomorrow :p
<azonenberg>
But i will be using that to evaluate the vishay parts against some of my experimental alternatives
<azonenberg>
as far as tip resistors on flex, that's the AKL-PT2
<azonenberg>
my earlier solder in probe
<d1b2>
<Code and Solder> I'm waiting on the screw on SMA though, ordered them from the same Chinese supplier
<azonenberg>
it worked well to 6ish GHz, could have gone higher if i made the flex shorter to reduce loss
<azonenberg>
but mechanically it was awful. if you had it flat to the DUT you had lots of coupling and loss
<azonenberg>
if you came in from an angle it was super fragile
<azonenberg>
since it was soldered castellations directly to the dut there was no room for things to flex if you bumped it
<azonenberg>
it'd just rip off
<azonenberg>
and the flex could only bend in one axis, not both like coax
<azonenberg>
the PT5 was the evolution of the design to avoid all of those issues
<d1b2>
<Code and Solder> I also got some samples of the smallest connectors from Mill-Max to try socketing the tip resistors
<d1b2>
<Code and Solder> To solder in more and switch when measuring potentially
<azonenberg>
I'd be interested in seeing how that turns out but my experience is that being reeeally small and solder with minimal stubs is crucial to minimzie loading at higher freqs
<azonenberg>
i got like a GHz more bandwidth out of some earlier PT1 (handheld transmission line probe) prototypes by switching a socketed tip out for a slightly shorter one
<d1b2>
<Code and Solder> Yeah, at 6GHz it won't be pretty, but most of my use is way below that
<azonenberg>
Yeah. I'm all for you making forks of the designs to suit your own needs
<azonenberg>
My focus is maximizing performance
<azonenberg>
i'm not aiming at making OSH competition to entry level 1000 class scopes and such
<azonenberg>
i want to play with the big boys
<azonenberg>
things you can use to sniff PCIe and 10GbE and such
<azonenberg>
And when I'm making a $250 probe that competes with stuff that costs 4 or 5 digits, it's not worth trying to cut another $10 off the price tag by cheaping out on parts
<d1b2>
<Code and Solder> I get that completely, I did want to get Koaxis until the take-your-money-fee
<azonenberg>
Yeah i mean i'm sure there are vendors more local to you that have better pricing. I went with them because they were US based
<azonenberg>
not sure where you are
<azonenberg>
anyway, then the other probe i didnt see you mention is the AKL-PR1, my other passive solder in probe project (still very much a WIP)
<azonenberg>
it currently gets 200-300 MHz BW although i plan to push to 500
<azonenberg>
and is a generic r-c divider like a normal scope probe
<azonenberg>
Just in a high density solder in form factor
<azonenberg>
For when you need to probe low bandwidth signals in a tight area
<azonenberg>
(The U.FL connections on the AV1/AD4 are only for power, not RF)
<azonenberg>
and that looks like it only has 2.92 and 2.4mm connectors for the other end not SMA
<azonenberg>
but i guess you can always use adapters or live dangerously and made without one
<azonenberg>
I also don't see a factory VNA testing option from them (again, samtec will probably do it if you call special but not somethign you can request on the form)
<d1b2>
<Code and Solder> Isn't 2.92 into SMA reasonably OK?