<d1b2>
<kretien> I'd lean towards a 2D abstract waveform icon, similar to the lumaFusion example. Simple, not too detailed, and easily recognizable
Degi has quit [Ping timeout: 272 seconds]
Degi has joined #scopehal
<lethalbit>
I've not checked in in a while, how are things going?
<lethalbit>
(i've also noticed that there is still a bug, at least on my system where I can't delete things from the filter graph :v)
<d1b2>
<azonenberg> o/
<azonenberg>
lethalbit: sooo
<azonenberg>
that isnt a bug per se, so much as an annoying architectural limitation (that does cause some bugs)
<lethalbit>
Mmm
<lethalbit>
Fair
<azonenberg>
tl;dr the filter graph as it stands is unidirectional from sink to source
<azonenberg>
the original intended flow was lazy evaluation from viewport to data source
<lethalbit>
would be really quite nice to get that sorted :v especialy when I add the wrong thing and now it jusut lives there forever
<lethalbit>
buut I get ya
<azonenberg>
there is no easy way to traverse from source to sink which means it is impossible to find what is using something
<azonenberg>
so there's no way to disconnect all users before you make it go away
<lethalbit>
yeah I get ya
<lethalbit>
sounds like it needs a bit of a revamp
<azonenberg>
we have a hacky homegrown refcounting scheme that occasionally leaks references but in theory is supposed to make stuff self-delete when all users go away
<azonenberg>
Right now we are three github tickets and an app icon away from shipping a v0.1 release, our first official cross platform binary release
<lethalbit>
Exciting!
<azonenberg>
as soon as that's done there's several dozen big refactorings planned plus a bunch of other delayed annoyances
<azonenberg>
Making the filter graph bidirectionally traversable and replacing the homegrown refcounting with std::shared_ptr are two of them
<azonenberg>
they have to happen in that order, because right now we rely on the refcount to do things like "turn off a scope channel in hardware when all users of it go away"
<lethalbit>
ye
<lethalbit>
oh that as another thing that might already be an issue but I didn't check just yet
<lethalbit>
if you accidentally close a waveform view, there is no way to get it back
<azonenberg>
but if we can instead simply traverse to see who is consuming the channel's output
<azonenberg>
I don't think we have a ticket for undo
<azonenberg>
it would be great to have but is nontrivial to implement
<azonenberg>
definitely not a 0.1 feature maybe not even a 0.2
<azonenberg>
but certainly 1.0 or before
<lethalbit>
Yee
<azonenberg>
anyway, there's a lot of benefits that will come from a bidir filter graph
<lethalbit>
I can check and make a ticket for it if it doesn't exist
<lethalbit>
mhm!
<lethalbit>
sounds like things are progressing though!
<azonenberg>
(there definitely is not one)
<azonenberg>
one of which is that it will enable deletion (you can find every consumer of a node and disconnect them)
<azonenberg>
another is that it will speed things up in many filters
<azonenberg>
because we have to compute all possible outputs from a graph block, even fairly expensive ones, not knowing in advance which will be consumed
<azonenberg>
if the graph is bidir we can skip computing outputs with no loads
<lethalbit>
mhm
<azonenberg>
Another big change i have planned, which will break compatibility with some existing filter graphs (I consider this OK to do in the v0.x series if i have a good reason, as long as it's not too difficult to fix afterwards and no actual waveform data is lost)
<azonenberg>
is to make it so instead of the CDR filter outputting a clock and then doing the sampling of the waveform against the recovered clock in the sink filter
<azonenberg>
(s)
<azonenberg>
it will output both a clock and the sampled data
<azonenberg>
this avoids a lot of manual traversal to figure out which clock edge matches up with which waveform sample, since we already have that info at generation time
<lethalbit>
ooh that would be nice
<azonenberg>
and also if you have say an eye pattern plus a protocol decode
<azonenberg>
you don't call SampleOnAnyEdges() twice
<azonenberg>
you will still be able to get the clock waveform for display or doing jitter analysis if you want it
<azonenberg>
but with lazy generation it won't be created if not used
<azonenberg>
we'll also need to add an explicit sampling block for protocols like old-school SGMII that send a clock along with serial data
<azonenberg>
(since you will no longer have a clock input on each protocol block, the clock will be implicit on the sampled data)
<azonenberg>
On that note, at some point i want to document stability guarantees and lack thereof
<azonenberg>
i.e. what level of compatibility to expect between current, past, and future ngscopeclient versions
<azonenberg>
the tl;dr is that for the 0.x series there is no expectation of API or ABI compatibility, drivers/plugins/filters need to be recompiled against the same git hash of libscopehal that ngscopeclient was as we can change anything internal at any time
<azonenberg>
scopesession files are strictly upward compatible in terms of waveform data and core settings
<lethalbit>
yeahh, I think that's expected if you're doing semantic versioning
<azonenberg>
i.e. if you load a session from version current-X, it will load, configure the instruments properly, but some filter graph blocks may behave differently due to semantics changing around sampling or configuration
<azonenberg>
and you may have to tweak them
<azonenberg>
and loading sessions from current+X maaaay work but you're on your own and there is no expectation this will work
<azonenberg>
but any failure to parse an old session or loss of data is considered a bug no matter how old, even going back to glscopeclient
<azonenberg>
and yes we are using semver
<azonenberg>
lethalbit: anyway basically there's a lot of fun stuff i want to do that will make things much better long term
<azonenberg>
that i just can't do right now because i need to ship 0.1 and not start long term projects that might break the build in the relevant dev branch for a prolonged time period
<lethalbit>
yee,
<lethalbit>
I get ya
<azonenberg>
in particular the filter graph refactoring and shared_ptr work will basically touch every filter and driver
<azonenberg>
and most of the ui
<azonenberg>
and it's not going to be possible to halfway it
<azonenberg>
it has to be done globally
<lethalbit>
mhm
<azonenberg>
but yeah basically in the long term i want to make every waveform view a sink in the filter graph
<azonenberg>
it probably won't be drawn as such to avoid clutter
<azonenberg>
but that's the concept
<azonenberg>
the other big thing i want to do eventually is add proper AWG support. i'm not sure of the right semantics for this, my gut feeling is that you would generate a waveform in the filter graph then feed it to an input on the AWG output node
<azonenberg>
then have some kind of update trigger that lets you download the new waveform to the arb
<azonenberg>
right now we support plenty of waveform generator drivers but only in function-gen mode, i.e. you can't actually push a waveform to them
<azonenberg>
another big thing is i want to add some way to output log messages or problems from filters
<lethalbit>
mmm
<azonenberg>
right now if there's a problem with missing inputs or something, we just output null and maybe log to stdout
<azonenberg>
ideally i want a trouble icon in the gui and some kind of either tooltip or popup speech bubble thing or something that says *why* the filter created no output
<lethalbit>
Yeah, another nice thing to add eventually would be descriptions of all the nodes in the tooltips
<azonenberg>
e.g. "fft only works on uniformly sampled input" or "subtract needs two inputs" or "cannot find peak to peak amplitude of a waveform with only one sample"
<lethalbit>
lots to do, never enough time,
<azonenberg>
yep lol
<azonenberg>
so stepping back a bit, more fundamentally
<azonenberg>
i am basically *the* core and gui dev right now
<azonenberg>
we have a lot of people contributing drivers and decodes here and there, and occasional bugfix PRs
<azonenberg>
but basically nobody else is doing work on the object model and the bulk of the UI. fredzo did some good work on the sidebar a few months ago then seemed to have dropped off a bit
<lethalbit>
yeah,
<azonenberg>
but we need more core devs long term, i can't be the only one working on that
<lethalbit>
I would offer to help, but i'm pretty busy myself and trying to get my feet undermyself again before I can do anything
<azonenberg>
lol no worries, if that changes we'd love a hand
<lethalbit>
I would love to help, there is nothing really even close to ngscopeclient as it stands in the first place, and having it be polished up would be really nice
<azonenberg>
what's the filter graph config you're using?
<azonenberg>
does the generated waveform look right?
<azonenberg>
and yes, ngscopeclient has basically no competition. pybert has some useful tools for high speed serial analysis and sigrok has some decent decodes for obscure oddball i2c chips etc
<azonenberg>
but nothing does this all in one high speed as fast as possible etc
<lethalbit>
It's not a super complicated graph, just PTRBS Data into some jitter both into the NRZ then in to an emphasis then noise then LPF then AC couple then CDR to eye
<lethalbit>
the waveform is rough, but looks fine
<lethalbit>
I'm just messing around its not important, just having fun
<azonenberg>
You shouldn't need the AC couple block if you set the NRZ to generate a dc-centered waveform
<azonenberg>
e.g. -400 to +400 mV
<lethalbit>
Ye, I didn't mess with it that much after it crashed on me the last 4 times, lol
<azonenberg>
or if you set the cdr threshold and eye center manually
<azonenberg>
I'm very interested in stack traces if you crash it
<azonenberg>
any known reproducible crash is a potential release blocker
<azonenberg>
and i try to drop everything and fix it every time i crash it while doing other things
<lethalbit>
On the topic of PyBERT, I really wish there was a better flow for channel simulation with the FOSS tools, I would like to be able to just select a bit of a KiCad layout and have a pipeline be able to do the extraction and simulation on it
<azonenberg>
me toooooo
<azonenberg>
right now i do that by exporting gerbers and using klayout to crop them down to a small ROI layer by layer laboriously
<lethalbit>
With the crashes, they've not been repeatable, just kinda random, one was with popping out a panel, another it just randomly sigsegv'd
<azonenberg>
then import into sonnet, do final trimming there
<azonenberg>
then simulate, get a s2p, feed that into ngscopeclient
<lethalbit>
Yeah, I would love to work on a proper end-to-end flow with FOSS tools if possible, but I don't enough enough about all the intermechanics needed and openEMS is *painful*
<azonenberg>
Even if not repeatable if you can get a core dump and at least give me what it was trying to do and where it failed
<lethalbit>
and then PyBERT is kinda slow
<azonenberg>
I pay for sonnet because openems is useless as it stands
<lethalbit>
Yeah, fair
<azonenberg>
its a decent solver kernel missing the other 95% of what a good em tool suite needs
<azonenberg>
also because i have a bit of a special relationship with sonnet at this point lol
<azonenberg>
i'd never get that kind of treatment from e.g. ansys
<lethalbit>
I have a *cough*copy*cough* of HyperLynx, but i've not really gotten it up and running because of the whole isolated VM layer causing friction
<azonenberg>
lol
<lethalbit>
and I would love some automated flow
<lethalbit>
*shrug*
<azonenberg>
yeah this is a fully legit paid copy with a support contract and i'm on a first-name basis with their head engineer and VPs and such
<azonenberg>
and the inner loop of their matrix solver is avx code i wrote :p
<lethalbit>
Oh that's nice
<azonenberg>
yeah tl;dr i got mad it was too slow, threw it in vtune
<azonenberg>
and ida
<azonenberg>
rewrote it faster and emailed my support contract with a "pull request"
<azonenberg>
contact*
<lethalbit>
I've been poking the free version of Sonnet every now and then, but running it under wine is a little painful, would be nice if the eval copy had native linux as an option
<azonenberg>
huh it doesnt? i thought the newer lite version did
<azonenberg>
could be wrong
<lethalbit>
Maybe the newer one?
<azonenberg>
definitely try
<lethalbit>
I last touched it a bit over a year ago
<lethalbit>
maybe I could also just email them about it :v
<azonenberg>
yeah definitely do, and cc me andrew.zonenberg at antikernel.net
<azonenberg>
they'll pay attention that way :p
<lethalbit>
ehehe, okay
<azonenberg>
but yeah basically after a bit of internal deliberation where they decided suing me for violating the EULA when i was offering a 40-70% speedup for their product in exchange for zilch was a monumentally stupid idea
<lethalbit>
yeah fr
<azonenberg>
they decided to make the lawyers happy by sending me a formal authorization on company letterhead to keep it up as long as i maintained an active support contract
<lethalbit>
ehehehe
<azonenberg>
they later invited me to their office when i was visiting family in the area, i spent a couple hours going over the product roadmap and code with senior leadership and engineers
<azonenberg>
negotiated a NDA for partial source code access
<lethalbit>
oooooh, nice!
<lethalbit>
(and yeah, looks like Sonnet Lite only has a Windows installer still)
<lethalbit>
tbf it runs fine in bottles, but its still a bit iffy
<azonenberg>
then took my somewhat hacky binary patch and rewrote it in proper intel intrinsics and with C prototypes matching their existing SSE implementation so they can do cpuid checks
<azonenberg>
and in the most recent release they shipped it lol
<lethalbit>
nice nice, that's honestly really cool to see
<azonenberg>
i want to throw vtune at the latest build and see what else i can tweak
<azonenberg>
havent had the time
<lethalbit>
ehehe
<lethalbit>
Oh, speaking of tooling, have you poked at SIMBEOR at all?
<azonenberg>
aanyway any ngscopeclient crash you can get me at least a stack trace from would be super helpful
<azonenberg>
might at least put me on the trail of something
<lethalbit>
I've had no luck getting an eval copy but it seemed neat, but I don't anyone know who's used it
<lethalbit>
Yeah I can pull out the coredumps
<azonenberg>
I have not. i've heard good things and seen yuri showing it off on linkedin
<azonenberg>
but thats it
<lethalbit>
mmm fair
<lethalbit>
it's a shame for things like that they're less willing to deal with individuals
<lethalbit>
anyway
<azonenberg>
yeah sonnet is very willing to deal with individuals if you have sufficiently deep pockets or are only using lite
<azonenberg>
but the flow for kicad integration isnt very good yet
<azonenberg>
long term btw i want ibis-ami modeling in ngscopeclient
<azonenberg>
we're a long ways from that
<lethalbit>
oooh yeah that would be nice
<azonenberg>
our current ibis driver block basically just replays the canned rising/falling edge waveforms
<azonenberg>
which is... better than nothign i guess
<lethalbit>
I think that's what PyBERT might do, too
<lethalbit>
dunno
<lethalbit>
I've been wanting to be naughty and kinda re-write something like PyBERT (but in rust, ofc :v)
<lethalbit>
but that seems kinda rude
<lethalbit>
(I also don't need more projects, lmao)
<azonenberg>
ngscopeclient has most of what pybert does afaik. the big missing bit is a cdr pll with jitter transfer curves matching standards
<azonenberg>
vs one we home grew
<azonenberg>
and a DFE block
<azonenberg>
idk if they have one we only have CTLE and FIR equalizers atm
<lethalbit>
yeah, ideally I want something I can pipeline/script in an easy and headless manner
<lethalbit>
*shrug*
<lethalbit>
Oh also, I don't know if you're even thinking about this at all, but maybe for the v1.0 you could reach out to Tyson Tan,
<lethalbit>
He does mascot design stuff for FOSS projects
<azonenberg>
if any of you have feedback on what direction we should take
<lethalbit>
Oooh
<lethalbit>
I'll take a look after lucnh
<azonenberg>
We rejected the one sketch that looked exactly like the keysight logo
<azonenberg>
others are still in play
<lethalbit>
(meanwhile I'm browsing ebay drooling over some DCA-X 86100D's *cough*)
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #scopehal
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #scopehal
<dingwat>
azonenberg: just curious, the demo Tek MSO5 you had, was it Windows or Linux flavor?
<azonenberg>
dingwat: Linux IIRC, we didnt have the windows option on it i think
<lethalbit>
(I quite like the Filter Graph Window B variant or just the normal eye diagram one personally, but also i'm a big sucker for skeuomorphic things so personally I think it would be cute if it was like, just a little DSO shaped friend, lol)
<dingwat>
azonenberg: nifty. Ours is Windows flavor because apparently only Windows flavor can run ethernet compliance
<azonenberg>
interesting
<azonenberg>
Filter graph window A is too much like the keysight logo so that's a hard no
<dingwat>
seems pretty insane to maintain/support two different operating systems for a scope rather than munge your compliance sweet to work on *nix but what do I know
<azonenberg>
I like B, i like the concept of the connections one too but i feel it's too busy and probably wouldnt work well at small sizes
<azonenberg>
and lol
<azonenberg>
and they still cant be bothered to put the work into making their scpi stack not crash constantly :p
<azonenberg>
dingwat: btw do you have 10/100 ethernet protocol decoding on yours?>
<azonenberg>
or just compliance
<dingwat>
azonenberg: I don't think we've installed our licenses yet, but probably just 1GbE compliance. We don't use any 10/100, so unless it's included with 1000BaseT we wouldn't have a reason to have it
<azonenberg>
yeah thats why i'm curious
<azonenberg>
if it's included
<azonenberg>
it feels like it might be
<dingwat>
We're still getting acquainted with this thing, gonna reach out to Tek and have them do a little Q&A session with us soon
<lethalbit>
azonenberg: Yeah I saw Filter Graph Window A and was like "Ah, yeah, that's the keysight logo" lmao
<azonenberg>
tek likes to bundle
<dingwat>
Uh, let me see what's in the bus decode by default
<azonenberg>
lol yeah glad i wasnt the only one with that reaction
<azonenberg>
even if its a different color it's a hard no :p
<dingwat>
azonenberg: we have I2C, parallel, SPI, and I2S/TDM (which I think we purchased)
<dingwat>
And none of the Ethernet applications are licensed so I dunno if they do decode. But I'll let you know once we get the compliance stuff installed
<dingwat>
you're in the market for an 86100D? good lord. That's a big boi
<lethalbit>
dingwat, I would *love* one, but I can't justify the price,
<lethalbit>
I'm so mad T&M equipment holds it's value so damn well second and third hand
<dingwat>
lethalbit: uh, yeah, what do those usually go for on the used market haha
<lethalbit>
how can a poor catgirl like me get a decent setup
<dingwat>
lmaoooooo
<lethalbit>
Maybe I should email keysight and see if they were willing to sponsor a VTuber, lmao,
<lethalbit>
I will shill keysight for some free stuff
<azonenberg>
lethalbit: wrt "holds its value" how much compared to new? lol
<lethalbit>
Okay, when I say "holds its value" you must understand my budget for things, even things I *need* is sadly under 1k
<azonenberg>
because i'm used to ~60-80% of list price as a manufacturer refurb and often closer to 10-30% from third party resellers
<azonenberg>
so like, sure you won't be getting a $250K scope for $500
<azonenberg>
but i would say the $200K ish scope I got for $33K was a pretty good deal and depreciated quite far
<lethalbit>
right, I don't expect that, but I still would love to snag a deal on someting for 4 digits
<azonenberg>
it's definitely an exponential decay like cars imo
<lethalbit>
anything over that is way out of scope (haha)
<azonenberg>
like the first day you own it, resale value goes way down
<azonenberg>
but the difference between a 10 and 12 year old instrument's resale value is minimal
<lethalbit>
yeah
<dingwat>
sometimes you get lucky :)
<lethalbit>
Oh yeah forsure, I scored a Synopsys HAPS-80D for a steal
<azonenberg>
lol now that was an impressive deal
<lethalbit>
and also a bunch of Agilent PCIe analysis stuff too, but I really need to try to get a good high-bw dso
<azonenberg>
reminds me of the time i found a bunch of 3G/4G remote radio heads from a liqudiation of an israeli cell carrier r&d lab
<lethalbit>
It was!
<miek>
the 86100a comes up for much cheaper now and then, and still has a lot of capability
<dingwat>
got a great deal on a TDS5104B because I think the auction was really short?
<azonenberg>
they had an xcku3p and a TI RFIC that does like 1 GHz BW in 2x2 mimo or slightly less in 4x4, and no frontend (just raw IF ports out to a connector)
<azonenberg>
and i think i got 7 for $50ish a pop, a friend grabbed another ten
<azonenberg>
mine were from further down the pile and some had some minor damage that looks reworkable, at least one i got fully booting and partially RE'd already
<lethalbit>
I was looking at trying to snag a Textronix 11801B and sd-24 or two
<lethalbit>
that might be managable
<lethalbit>
but
<lethalbit>
anyway, lol
<lethalbit>
I'm just being yearny for T&M equipment
<azonenberg>
i'm eyeing the signalhound vna400 eventually
<dingwat>
wish I could convince $work to buy that
<azonenberg>
niiice
<dingwat>
We have to farm out phase noise quals right now :(
<lethalbit>
azonenberg: yeah thanks for the offer, i'll keep it in mind if I need something like that~
<dingwat>
in other T&M news, I realized my XPD60-9 wasn't broken, I just had the DIP switches in the wrong setting. So that's on the bench now. It's really compact for a 540W bench supply
<lethalbit>
oooh
<dingwat>
now I just need to figure out what's wrong with this stupid keithley meter
<lethalbit>
that remnds me, I need to fix the RS-232 tx on my keithley, it can receve SCPI commands just fine but output is dead as a doornail
<dingwat>
and I'll have all the bits and pieces I realistically want, minus a load
<lethalbit>
I also need to figure out what the deal is with Linux GPIB now that a big chunk of the drivers and such are merged mainline
<dingwat>
I thought I got an awesome deal on a Keithley 2700, turns out there was a reason it was cheap, doesn't do the things
<lethalbit>
oops
<lethalbit>
lol
<azonenberg>
lethalbit: well we moved the linux-gpib driver to a plugin since we found the userland components as of now are GPL'd
<lethalbit>
Yee
<azonenberg>
but if we can use the kernel interface directly maybe we can work around that
<azonenberg>
(i want gpib support on other platforms too anyway eventually although its a low priority, i mostly use stuff modern enough to have ethernet and/or usb on it)
<lethalbit>
I might be able to poke that, actually, as I finally got a new USB cable for my Keysight 82357B
<lethalbit>
(they made it really easy to replace, wich is nice)
<azonenberg>
i really do not like keysight/agilent part numbers because they're so meaningless
<azonenberg>
i have to constantly google part numbers when looking them up
<azonenberg>
vs with lecroy e.g. CPxx = current probe, ZSxxx = single ended high-z active probe, PPxxx = passive probe, Dxxxx = differential probe
<lethalbit>
Ehehehe
<miek>
i haven't been having much luck with linux-gpib lately, i think a regression got introduced for my 82357A and i haven't had a chance to track it down. i ended up switching to keysight's VISA drivers
<azonenberg>
you might not have the full specs from the part number but at least you know roughly what kind of instrument or accessory it is
<lethalbit>
yeah, the HP/Agilent/Keysight PNs are just
<azonenberg>
at least the keysight family names arent awful
<azonenberg>
like MXR = Moderately eXpensive Realtime (oscilloscope)
<azonenberg>
UXR = Ultra eXpensive Realtime
<azonenberg>
:p
<ALTracer>
Hameg/Rohde had meaningful names, too
<azonenberg>
ALTracer: did they? HMC8042 vs HMC8012
<azonenberg>
which is a power supply, which is a multimeter
<azonenberg>
how many channels does each have
<azonenberg>
(I have two of each and i still mix them up sometimes lol)
<ALTracer>
HMO1002 is 100MHz 2ch, RT-ZP03 is passive probe, HO3508 is logic prove 8ch (now RT-ZL03)
<ALTracer>
don't have anything else from that lineup, unsure about buying the logic probe vs. REing the 8051 that goes in there
<ALTracer>
that's how SAMA5D3 that runs the scope knows a LA was plugged, and tells it the voltage to set on buffers/comparators
<azonenberg>
you remind me i keep wanting to build that monstrously fast logic analyzer
<azonenberg>
i want to make something using xilinx serdes in oversampling mode as a LA
<azonenberg>
to get 10+ Gsps and several Gbps of data rate
<azonenberg>
on ultrascale+ even 20+ Gbps should be achievable
<azonenberg>
20+ Gsps*
<azonenberg>
for a relatively low cost
<lethalbit>
Gbps -> Giga-boops-per-second
<azonenberg>
That's what you do to a really cute snek
<d1b2>
<azonenberg> not sure why you're doing the LPF and noise in parallel and summing. it makes more sense to run them end to end
<d1b2>
<azonenberg> that skips a filter block and also the LPF might introduce a phase shift
<lethalbit>
I was just playaing around
<lethalbit>
s/playa/play/
<lethalbit>
some funny looking results
<azonenberg>
what are you using for the nrz sample rate and rise time? it looks like you might not be oversampling sufficiently to get much in the way of rise/fallling edge samples
<azonenberg>
i usually run at 50+ Gsps for this kind of modeling
<lethalbit>
I was using all the defaults, for the NRZ it was 100 Gsps iirc
<azonenberg>
ah ok
<azonenberg>
yeah that should be fine then
<lethalbit>
*shrug*
<azonenberg>
the lack of rising/falling edge samples is interesting though