<azonenberg>
this is an extremely simplistic simulation but should be good enough for what i want to do with it right now
<lain>
azonenberg: looks good
<azonenberg>
in particular it's just replaying the curves in the datasheet and probably breaks down if you push a LVCMOS buffer past sane limits
<azonenberg>
i.e. if it hasn't finished rising and you try to make it fall, it might bork
<azonenberg>
and it only works under conditions with waveforms in the ibis directly
<azonenberg>
all of my attempts to use the i/v curves ended in disaster
<azonenberg>
But it lets me synthesize plausible waveforms which i can then feed into a S2P etc
<azonenberg>
The next step will be creating a mock oscilloscope for glscopeclient that takes in an IBIS file and model name as arguments and creates a test waveform you can do stuff to
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
<miek>
azonenberg: i found that equalisation video again, such a cool demo https://youtu.be/l-PE7bNIDY0?t=4731 - worth a look if you haven't seen it already
* azonenberg
watches whole video
<azonenberg>
Shahriar is one of the very few folks i've seen with more high-end test equipment in their house than me lol
<azonenberg>
But he has me beat by a massive margin
<miek>
lol
<azonenberg>
Also, probe PCBs came in early
<azonenberg>
I think i have enough resistors to populate one of them, but i need to order more to do the production batch. And more SMAs
<azonenberg>
Right now the ibis file and model name are hard coded but they'll be provided as arguments to the "scope" later on
<azonenberg>
Next step is channel emulation
<azonenberg>
And then eventually, support for importing VCDs instead of just doing PRBS's
<azonenberg>
So you can see how line-coded data or actual application layer packets look
<_whitenotifier-b>
[scopehal] azonenberg pushed 2 commits to master [+6/-0/±16] https://git.io/JJRRg
<_whitenotifier-b>
[scopehal] azonenberg cf9a397 - Initial version of SignalGeneratorOscilloscope. Still a bunch of hard coded config.
<_whitenotifier-b>
[scopehal] azonenberg 0109bda - Initial implementation of channel emulation. Not closing the ticket because phase correction is screwed up for some reason.
<azonenberg>
no dispersion yet, i'm only modeling loss
<lain>
:D
<azonenberg>
And this is working *in real time*
<azonenberg>
It is however saturating my 32-core workstation :p
<lain>
I'm really excited to compare your final system with hyperlynx (and the real world). once it's working well, that's one less BS tool I need to mess with lol
<lain>
yah but compute shaders eventually™
<azonenberg>
Yes, moving the FFTs to the GPU will be a HUGE performance boost
<azonenberg>
But i want to get dispersion modeling working on the CPU first
<azonenberg>
for some reason as soon as i add phase support everything goes down the toilet
<azonenberg>
even though it works fine de-embedding
<azonenberg>
The *real* signal is even better than this because this isn't a minicircuits s2p, this is my own measurements that top out at 6 GHz and assume no transmission past that
<_whitenotifier-b>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JJR0J
<_whitenotifier-b>
[scopehal] azonenberg 4860989 - Fixed some bugs around phase handling at S2P boundary conditions. Fixes #184.
<_whitenotifier-b>
[scopehal] azonenberg opened issue #188: Add PAM4 signal generator - https://git.io/JJRNu
<_whitenotifier-b>
[scopehal] azonenberg opened issue #189: Add noise/jitter support to signal generator - https://git.io/JJRN2
<_whitenotifier-b>
[scopehal] azonenberg opened issue #190: Add pre/de-emphasis support to signal generator (or separate filter) - https://git.io/JJRNV
<_whitenotifier-b>
[scopehal] azonenberg edited issue #189: Add noise/jitter support to signal generator (or separate filter) - https://git.io/JJRN2
<kc8apf>
When did 24MHz for JTAG/SWD become fast?
<azonenberg>
is it?
<azonenberg>
i've seen fpgas that can run jtag at 66
<_whitenotifier-b>
[scopehal-apps] azonenberg assigned issue #131: Add 48x48 renders of toolbar icons, and preference setting to use 24x24 or 48x48 - https://git.io/JJqpP
<_whitenotifier-b>
[scopehal-apps] azonenberg opened issue #147: Filename parameters to filters should have a "launch file chooser dialog" button next to the text box - https://git.io/JJRx7
<_whitenotifier-b>
[scopehal-apps] azonenberg labeled issue #147: Filename parameters to filters should have a "launch file chooser dialog" button next to the text box - https://git.io/JJRx7
<azonenberg>
NeroTHz: also i forget if i mentioned but since glscopeclient connects (typically) via IP networking, you dont even have to be near the scope to use it
<azonenberg>
you can set up a test fixture then go home and crunch data over a VPN or something
<azonenberg>
obviously WFM/s suffers in this use case
<azonenberg>
but you can do all of the DSP clientside without pulling data from the scope other than the initial waveform
<NeroTHz>
yeah, that would be a big issue in my case. And for me, we often spend a lot of time tweaking bias voltage etc of our TX/RX chips to optimize the eye
<NeroTHz>
but cool none-the-less
<azonenberg>
Exactly. And that presumably can also be done remotely?
<azonenberg>
or do you not have IP control on those power supplies?
<NeroTHz>
often these supplies are lots of manual trimmers on devboards and so on
<azonenberg>
ah, ok
<azonenberg>
yeah all of my power supplies are IP controlled to allow a fully hands off test platform
<azonenberg>
You're mostly a Keysight shop right?
<NeroTHz>
In theory we could make it all remote-controllable, and it´s something im looking into, but for us, it can often be usefull to just be there
<NeroTHz>
nah, R&S
<NeroTHz>
only our scopes are Keysight
<azonenberg>
re scopes i meant
<NeroTHz>
yeah, for high-speed scopes, keysight
<NeroTHz>
(mostly because R&S doesn´t make >20 GHz scopes)
<NeroTHz>
(though I´ve been told the future for R&S scopes is exciting)
<azonenberg>
well at some point if you're interested i'd love to have you try glscopeclient out with them. We have an "agilent" driver that works with some keysight hardware but we have to do a lot more testing to expand the list of supported models
<azonenberg>
i have no idea how much agilent/hp/keysight's scpi command set has changed over the years
<NeroTHz>
yeah, sure, I think that would be very interested. I also have a number of higher speed R&S scopes to test with too, if you want
<azonenberg>
LeCroy scopes from the floppy drive era work with my driver written for a modern waverunner
<azonenberg>
they've been extremely stable wrt the command set
<azonenberg>
as far as R&S goes we have a somewhat bitrotted driver that was tested on a RTM3000 series years ago and then not touched since
<azonenberg>
because nobody in the channel had a R&S scope to do dev on :p
<azonenberg>
Generally speaking i'm the main core developer and maintain the core library, lecroy driver, and write most of the protocol decodes and filters
<NeroTHz>
If you want, once I can go back to the lab (and I don´t forget) I can provide you with a list of all scopes I can work with
<azonenberg>
then Degi is the Rigol driver maintainer, miek is working on agilent stuff and the USB protocol decoders
<azonenberg>
katharina comes and goes, she's recovering from covid and hasn't done much code yet, but is a beta tester for the rigol stack and has been doing some really nice looking UI work that's not yet merged
<azonenberg>
noopwafel was interested in doing a picoscope driver but i dont think has had time to do much on it
<NeroTHz>
I´m not strong on the softwareside, so I can´t help you apart from offering the lab for testing :p
<azonenberg>
pepijndevos has been doing a lot of good testing on the rigol driver and found a bunch of bugs we need to work on :p
<azonenberg>
Well, that's still helpful
<azonenberg>
The suite of hardware we'd need to get all of the drivers i want would easily be millions of dollars
<azonenberg>
we cant afford to buy every scope on the market just to get driver support
<NeroTHz>
I also saw you are looking at some AWG stuff - can provide a number of models there to test on too - right up to the 65 GSa/s
<azonenberg>
We're a long ways from that. I have a very basic function generator API in the library but no UI to invoke it
<azonenberg>
at a high level there's a couple of main components to the project
<azonenberg>
libscopehal is essentially an open source, less awful VISA replacement that exposes a C++ API for test equipment
<azonenberg>
it contains all of the drivers and SCPI transports, as well as some base classes for filtering, but no actual decodes/filter
<azonenberg>
libscopeprotocols is all of the protocol decodes and filters
<azonenberg>
and glscopeclient is the primary user interface, although you can also call the libraries directly from scripted ATE-type use cases
<azonenberg>
There is support in libscopehal for basic function generators (no full arb) and power supplies and multimeters
<azonenberg>
but no UIs for those yet
<NeroTHz>
Full arb is something I´ve been looking at a lot for work
<azonenberg>
When I get an AWG it's something i will definitely play with more
<NeroTHz>
to get much more control over PAM4 with pre-emphesis and so on
<azonenberg>
I've been drooling over the lecroy T3AWG series among others
<azonenberg>
T3AWG3352 or similar. 1.2 Gsps, 350 MHz, but 16 bit resolution
<NeroTHz>
16 bit is a lot
<NeroTHz>
I think ours is 8?
<azonenberg>
But a lower res higher sample rate one would be nice too. No budget right now, my new 4 GHz 40 Gsps scope arriving weds blew my lab budget for most of the rest of the year :p
<azonenberg>
But as i mentioned the CDR PLL needs work to properly lock to them
<azonenberg>
with MLT-3 since you don't have a bottom-to-top transition, I can just look for edges on the top eye or bottom eye and sync to those
<azonenberg>
and treat transitions in the bottom half as runs of 1s or 0s
<NeroTHz>
yeah. for us the main thing is also the filtering. Our pam4 has unequal levels in our current system, which is something the AWG software can´t optimize for
<azonenberg>
But with PAM that doesnt work
<azonenberg>
the other thing i want to do is implement a standard cdr pll
<azonenberg>
right now i'm using a homegrown one that works, but doesn't have the exact bw characteristics of, say, the FC golden pll
<azonenberg>
ultimately what i think is going to happen longer term is i'll have two filters, one is an edge detector that turns an analog waveform into a digital one including sub-sample interpolation to find exact edge positions
<azonenberg>
for NRZ this is just thresholding, for PAM it will be more complex
<azonenberg>
then the second filter will be a PLL that locks to a digital bit stream
<NeroTHz>
makes sense. You do support external clock inputs, or not yer?
<azonenberg>
The eye pattern filter takes a digital waveform as a sampling clock and an analog waveform as the data
<azonenberg>
right now, the clock must be double rate at a 90 degree phase angle
<azonenberg>
iow, it expects a UI centered on both the rising and falling edge
<azonenberg>
down the road i may make it more flexible to support 0-degree and single rate reference clocks
<azonenberg>
eventually i also want to support frequency synthesis filters, so you can take say a HDMI pixel clock, multiply up by 10x, then use that as your sampling clock for the eye
<NeroTHz>
ah, that is somewhat annoying for me, but I get that that is not priority
<NeroTHz>
That would be great for us, we often can´t generate like a 50-60 GHz clock
<NeroTHz>
so we use some lower frequency divided down clock reference
<azonenberg>
well it's not that it isn't priority so much as the project is a small team
<azonenberg>
and i can't do everything i
<NeroTHz>
Oh I understand
<azonenberg>
i'm also working on the hardware side with MAXWELL etc
<azonenberg>
and of course this is all a spare time project i'm not getting paid for
<azonenberg>
If it got to the point that big companies wanted to use it, and were willing to sponsor development, it would progress a lot faster i think
<azonenberg>
but it's not there yet
<azonenberg>
i think it has potential though
<NeroTHz>
I agree, I really do think it has pottential
<azonenberg>
The software is way ahead of the hardware but longer term in both HW and SW i want to be competing with keysight/R&S
<NeroTHz>
yeah, that would be amazing
<azonenberg>
i mean, it's already to the point that for my home lab i just don't buy vendor software options
<azonenberg>
my 2 GHz scope is naked
<NeroTHz>
we spend so, so much money on software options for all our stuff
<azonenberg>
that's the calculus i want people to be doing
<azonenberg>
basically, at what point is it worth spending $10K to pay me/somebody to write a software package to decode your protocol
<NeroTHz>
(but ofcourse, after you get a 750k for the hardware, nobody bats an eye at 100k for 20 software options)
<azonenberg>
rather than paying keysight $2K for each of 50 scopes
<azonenberg>
to buy the premade software
<NeroTHz>
that would make sense
<azonenberg>
at some point if your fleet is large enough, especially considering turnover as you retire equipment and have to buy more software for the new ones
<azonenberg>
it's cheaper to develop the tool
<azonenberg>
the one thing you still need done in hardware is triggering obviously
<azonenberg>
oh, i almost forgot a really awesome capability i have
<azonenberg>
I call it "conditional halt" but it's similar to what lecroy calls WaveScan
<azonenberg>
basically, stream waveforms from hardware on a simple edge trigger or similar, then look for complex protocol conditions
<azonenberg>
for example, no scope has a 'trigger on vlan tag" feature
<NeroTHz>
ah yeah, protocol triggerign kinda?
<azonenberg>
but it's easy to decode frames after triggering on edges, or doing a simple serial pattern trigger to look for start of frame or something
<azonenberg>
then post-triggering on complex protocol fields
<azonenberg>
I also have some fancy features for things like video
<azonenberg>
this is a DVI/HDMI protocol decode on three TMDS channels showing actual recovered scanline data at right
<NeroTHz>
damn
<NeroTHz>
Yeah, I guess you have a lot of protocol-level need right? for your job
<azonenberg>
then the protocol decode overlays at left showing the actual video data on the top trace
<NeroTHz>
in my head scopes just show me an eye and faster eye is more better
<azonenberg>
actually a lot of this is for my own use on hardware i or friends are building... most of the stuff i do at $dayjob is simple i2c/spi/uart type work
<azonenberg>
But yeah i'm trying to build full protocol analyzer functionality, as well as all kinds of sophisticated signal integrity tools
<azonenberg>
this is the test fixture i collected those ethernet waveforms from
<azonenberg>
full custom fixture with integrated 20:1 transmission line probes, fancy vishay flip chip RF resistors
<azonenberg>
then SMA to the scope
<NeroTHz>
that is a pretty cool fixture actualy
<azonenberg>
i want to respin it with better matching at the SMA launch at some point now that i have sonnet, this was done before i had a field solver so the matching is a bit off from ideal
<NeroTHz>
you seem to have way too much time
<NeroTHz>
I spend two years just to get an eye on my scope :p
<azonenberg>
I have ones for HDMI and USB as well
<azonenberg>
that i need to optimize as well
<azonenberg>
eventually i hope to sell a whole line of such fixtures way cheaper than the big brands
<azonenberg>
But i have a ways to go before i'm satisfied with the results
<monochroma>
"How did azonenberg die?" "Keysight had him assassinated."
<azonenberg>
lol
<NeroTHz>
Just let me know when you start on VNA software
<azonenberg>
Lol one thing at a time :p
<NeroTHz>
Than I can give you some more input than ´eye goe weeeeeeeeee '
<azonenberg>
Anyway, a lot of our users so far are hobbyists working on low end (rigol class) gear so there's been a lot of interest in bringing advanced analysis capabilities to the low end gear
<NeroTHz>
that makes a lot of sense
<azonenberg>
for example, rigol won't sell you an 10baseT ethernet or 12 Mbps usb protocol decode for a 70 MHz scope
<azonenberg>
or doing eye patterns on a long CAN bus
<NeroTHz>
mhm
<azonenberg>
but with my software as long as you have the bandwidth and sample rate IDGAF what your scope is
<azonenberg>
it can be a pc sound card for all i care :p
<azonenberg>
Anyway in parallel with all of this we're working on our own hardware
<azonenberg>
You saw MAXWELL already
<NeroTHz>
yeah, I think so
<azonenberg>
The other active project, besides the probe, is BLONDEL - a scope intended to compete with the low-end rigol gear but with some advanced features and better remote performance (rigol's WFM/s sucks over LAN)
<azonenberg>
BLONDEL will be a 1U headless system with *eight* 50 ohm SMA probe ports on the front
<azonenberg>
and 10GbE to the outside world on the back
<NeroTHz>
that is pretty cool
<azonenberg>
Two groups of 4 channels each sharing a single reconfigurable ADC + crossbar
<azonenberg>
you can do 1 Gsps in 8 bit or 500 Msps in 12 bit, shared across 1/2/4 channels, with 100 MHz frontend bandwidth
<azonenberg>
So you can have one group be 8 bits 4 channel 250 Msps and the other be 12 bit 1 channel 500 Msps
<azonenberg>
I maaaay have gone overkill with the RF layout for a 100 MHz frontend :p
<NeroTHz>
Yeah, this is where I can´t really help you that much, or a certain german test-equipment vendor is gonna get really angry at me
<azonenberg>
Lol
<NeroTHz>
and yeah, I think that might be a tad overkill :p
<azonenberg>
Actually the frontend should be good to 500 MHz with different AA filters
<azonenberg>
I plan to use this frontend in three generations of scope
<azonenberg>
BLONDEL is the first, then DUDDELL will have an ADC dedicated to each of the 8 channels
<azonenberg>
vs one per 4
<azonenberg>
so 1 Gsps / 500 Msps all the time in 8/12 bit mode, 250 MHz bandwidth
<azonenberg>
then ZENNECK will interleave four ADCs per channel giving 4/2 Gsps in 8/12 bit mode, 500 MHz bandwidth
<NeroTHz>
but then you do need an external SaH?
<azonenberg>
TBD, but i dont think so. The sampling aperture on these ADCs is actually quite short, they have ~600 MHz analog bandwidth
<azonenberg>
i should be able to get away with a 1:4 power splitter and four phased clocks
<NeroTHz>
don´t underestimate the difficulty in interleaving - you can very easily get spurs when you don´t have perfect matching and any phase error between them
<azonenberg>
I'll be using a TI LMK04806 PLL for clock synthesis
<azonenberg>
It gives me per output phase adjustment in 25ps steps and jitter in the 120 fs range
<azonenberg>
so i can very precisely tune the sampling phase of each clock
<NeroTHz>
okay, that is good
<azonenberg>
and then the ADCs actually have support for some analog trim to do better matching of gain/offset between several
<azonenberg>
i can do further correction in postprocessing
<NeroTHz>
yeah, okay, sounds like it indeed
<azonenberg>
Anyway, then the next generation of scope, way further out, will use a completely new frontend
<azonenberg>
the AD9213 is a JESD204B ADC that does 12 bits at 10 Gsps
<NeroTHz>
By that part you will be getting an ASIC team going and spin your own
<azonenberg>
I'll need some beefy FPGAs to keep up with 120 Gbps of data per channel :p
<azonenberg>
probably a sodimm of ddr4 per adc
<azonenberg>
VOLLUM is targeting 1-2 GHz bandwidth, one of those per channel
<azonenberg>
and MURDOCK will interleave four AD9213s per channel to get 6 GHz bandwidth and 40 Gsps
<azonenberg>
It will also cost as much as a cheap house at digikey prices :p
<azonenberg>
the ADc alone is $3500 and i'll need 32 of them lol
<NeroTHz>
I mean yeah :p why do you think scopes are so expensvie
<azonenberg>
and then multiple large FPGAs to keep up with the 3.84 Tbps of data coming off the ADCs
<azonenberg>
and probably 16/32 channels of DDR4 to buffer the waveforms
<azonenberg>
but at that point you're talking about hardware competitive with a lower end lecroy SDA
<NeroTHz>
Have you considered a card-system at that point?
<azonenberg>
Yes, that is the plan
<NeroTHz>
so each channel is a card?
<azonenberg>
i'd be running probably 10GbE on the backplane
<azonenberg>
then a master fpga bridging all of the control traffic out to 40GbE to the outside world
<azonenberg>
On the lower end stuff i'll have larger blocks
<azonenberg>
BLONDEL will have 4 channels on a card and they'll be horizontal in 1U
<azonenberg>
the higher end scopes will be eurocard based
<NeroTHz>
will be interesting to see how this works out
<azonenberg>
yeah i'm just getting started, part of the question is budget
<azonenberg>
i hope to fund the higher end projects by selling assembled units of the lower end models
<NeroTHz>
that makes sense
<azonenberg>
So far my probe project i think is running at a net loss
<azonenberg>
While i'm taking a profit on the kickstarter, it wasn't enough to make up for R&D expenses with the 20-odd probes i sold on KS
<azonenberg>
i did ten board spins and lots of test fixtures :p
<azonenberg>
but now that the R&D is done i can continue to sell them afterwards and hopefully break even eventually
<NeroTHz>
If you are seriously considering startup-route, there are often deals to be had with the software vendors if you end up needing to simulate stuff
<azonenberg>
Right now i'm sticking with the day job and doing this on the side
<azonenberg>
if/when it becomes something i can make a living on, great
<NeroTHz>
I know a few guys doing a RFIC startup, and they get offers from Keysight and Cadence, usually packages where you get their software for extremely low price, untill you release your first product/are out of startup-phase, and then they start fully charging you
<_whitenotifier-b>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JJRhX
<azonenberg>
NeroTHz: I get a discount from sonnet for being a one man shop
<NeroTHz>
yeah, but I heard it still was quite limiting right?
<azonenberg>
Well i have their lowest edition
<azonenberg>
i'll be upgrading to a much higher version soon
<azonenberg>
but it waseither that or a new scope
<NeroTHz>
If I may be so curious, what did they charge you? 1y license?
<azonenberg>
and when i saw a 4 GHz 40 Gsps scope up for sale and was able to negotiate $13K with trade in, plus transferring all of my old software options to the new scope
<azonenberg>
i jumped on it
<azonenberg>
but that was the budget i was planning to spend on sonnet upgrade, so it might be a bit
<NeroTHz>
yeah, so long tehre is no money being made on sold items, I can always stuff somet hings in EMPro/HFSS/Momentum for you, but once you get out of the early phase that kinda breaks my use-terms
<azonenberg>
Roughly speaking it's $4K for basic, $8K for silver, $12K for gold, and somewhere around 25K for pro (fully uncapped)
<azonenberg>
Each seat is a perpetual license for that version and comes with a year of support
<azonenberg>
Renewing support is 15% of sale price per year
<NeroTHz>
Damn, they really give their software away
<NeroTHz>
(compared to some of the other EM packages)
<azonenberg>
You see why i dont use hfss? :p
<azonenberg>
And if you upgrade to a higher version with an active support contract they charge you the delta only
<azonenberg>
and give you another year of support
<azonenberg>
so for example i bought basic around christmas of last year so support runs till xmas of this year
<azonenberg>
if i buy silver before then, it will cost me $4K
<azonenberg>
and i'll have support until xmas 2021
<azonenberg>
if i then upgrade to gold at any point before that it will cost another $4K and give me support until xmas 2022
<azonenberg>
at which point it will be about $1.8K per year to renew support
<azonenberg>
very affordable, non-predatory licensing and absolutely first rate support
<azonenberg>
you heard the story about the time i crashed the solver on christmas eve right?
<azonenberg>
one hour from email to reply from support engineer with confirmation of the bug and a workaround
<azonenberg>
an hour after that, reply from an actual solver core developer with root cause identified, a better workaround, and says he's filed a CR for a fix to be released in the next point release
<azonenberg>
ON CHRISTMAS EVE
<azonenberg>
For a customer who paid only $4K for the license
<azonenberg>
the support is worth every cent
<NeroTHz>
damn
<NeroTHz>
that is increddible
<azonenberg>
I obviously prefer open source tools but if i have to pay for software, i want good support. And sonnet delivers
<azonenberg>
the tool also runs great on linux which is nice
<azonenberg>
but that beats lite which is 32 MB solver memory, 4 ports, and max of 3 ideal components :p
<azonenberg>
(that's the free demo)
<azonenberg>
silver is IMO a pointless edition, it bumps you to 256 MB solver memory and 8 ports but you pay twice as much
<azonenberg>
gold goes to 2GB solver memory, 3 layers, and basically unlimited everything else except for no multithreaded solver and it's missing some advanced stuff like non-cartesian meshing
<azonenberg>
and then pro is uncapped and comes in two versions, one with an 8-thread solver cap and the other with no limits at all
<azonenberg>
i think it maxes at 64 threads due to algorithm scaling limits
<azonenberg>
I really need gold or pro for the work i'm doing, just a matter of finding the cash
<azonenberg>
Support is very impressed at how much i've managed to shoehorn into basic, apparently i'm one of their most advanced users of that edition
<azonenberg>
But they agree that i really need a higher version
<NeroTHz>
I mean you´re gonna be hardpressed to find a company that wont tell you that you need to spend more on their product ;)
<NeroTHz>
ah sonnet is FDTD right?
<azonenberg>
no MoM
<NeroTHz>
they don´t have a frequency-domain product?
<NeroTHz>
oh really
<NeroTHz>
right, yeah, MoM, I should have known, itś 2.5D
<azonenberg>
yeah all FFT based
<azonenberg>
openems is FDTD and looks like a very nice solver
<azonenberg>
but there's literally no UI
<azonenberg>
it's JUST a solver
<azonenberg>
which makes it worthless to me
<NeroTHz>
yeah, I´ve used FDTD on EMPro, and it is incredibly fast on GPUs, but it is such a horrible pain in the backside to set up
<azonenberg>
sonnet also has a very nice s-parameter viewer that lets you do all kinds of transformations
<NeroTHz>
so sure, my simulation in FDTD goes in 10 minutes instead of 1 hour, but I need 2 hours to get usefull results out of it
<azonenberg>
to view equivalent R/L/C, export a broadband HSPICE model
<azonenberg>
calculate port impedance, group delay, etc
<NeroTHz>
yeah, but if you can export s-parameters, a lot of that math is actually kinda simple in python/octage/matlab
<NeroTHz>
in fact, I´ve long ago written some basic matlab to deal with simulation results
<azonenberg>
yeah i havent got to that point. i actually use sonnet's s-param viewer to crunch data from my VNA
<azonenberg>
because it's better than the vna software lol
<NeroTHz>
haha :p
<azonenberg>
of course it's pico, that isnt a high bar
<azonenberg>
pico makes great hardware but their software is atrocious
<NeroTHz>
I really like the R&S software, but that might just be me being biased
<NeroTHz>
they completly re-did it for the new ZNA, and so far I really liked it, but I have only had 1 day to play with it before I had to be kicked out of tha lab for COVID testing
<monochroma>
R&S has a COVID testing option? ;)
<azonenberg>
monochroma: lool
<NeroTHz>
hahah ;) nah, my sister got sick and as soon as she did I decided to self-quarantine. And she ended up testing positive, so I also went for a test, waiting for results now
<monochroma>
:(
<NeroTHz>
We are all fine, barely any symptoms, so all good. Just very frustrating because I was just starting measurements
<monochroma>
yeah :<
<NeroTHz>
So I can´t wait to go back and finish and play with all my toys
<azonenberg>
Clearly you need a 100ghz scope in your basement
<NeroTHz>
I really do
<NeroTHz>
110 though
<NeroTHz>
100 G is the lecroy and it aint that good
<azonenberg>
if only i had the cash this is quite a nice price
<azonenberg>
i never expected to see a labmaster on ebay
<monochroma>
azonenberg: i've seen em a few times
<monochroma>
usually from california
<NeroTHz>
prime market for those scopes on ebay, I¨ve been told, is iran and similar trade-restricted coutries
<azonenberg>
lol
<NeroTHz>
they sometimes sell for more than they cost new (not in this case, you mostly see that with keysight PNA-X)
<azonenberg>
So basically people willing to violate export controls
<NeroTHz>
pretty much
<azonenberg>
But $50K for a scope that's easily worth six figures new is a good deal
<azonenberg>
the labmasters start >$100k
<NeroTHz>
yeah, that is true
<azonenberg>
I dont have the cash, but if i did
<azonenberg>
you bet i'd be interesteed
<NeroTHz>
haha :p
<monochroma>
azonenberg: you've got a bike, sell the car!
<azonenberg>
The car wasnt worth $50k new
<monochroma>
and a kidney
<azonenberg>
certaily not now that it's 7 years old
<azonenberg>
lol
<azonenberg>
I wouldnt want a labmaster as a primary scope anyway
<azonenberg>
50 ohm inputs and super fragile
<NeroTHz>
yeah, it´s like the Z-series and UXR at my lab - these are scopes you have for just one reason - high speed data
<azonenberg>
that's what i like about the SDAs and similar class scopes
<azonenberg>
they still have 1M ohm inputs and probus probe capabilities
<azonenberg>
you dont get full bandwidth of course
<azonenberg>
but it lets you use one scope for multiple purposes
<NeroTHz>
z-series does also have probe options
<azonenberg>
My current lecroy stuff is <= 4 GHz and has BNC inputs with switchable 50 ohm / 1M
<noopwafel>
azonenberg: yeah I did bare minimum to make pico do a waveform
<azonenberg>
noopwafel: did you send a PR?
<azonenberg>
i dont recall seeing it anywhere
<noopwafel>
no, it depends on my SCPI hack, I should tidy it up
<noopwafel>
azonenberg: do you have any suggestions for remote-controlling glscopeclient itself?
<noopwafel>
I bought that midi controller and wanted to hook it up
<noopwafel>
was thinking of just hacking in something to listen on a socket and obey basic commands, then I can just write an external script
<azonenberg>
noopwafel: hmmmm
<noopwafel>
but if you have a more elegant idea..
<azonenberg>
I think what we'd want to do is have a server that listens for commands then calls UI methods in the OscilloscopeWindow
<azonenberg>
Probably poll the socket every time it checks the scope for new waveforms or something, there's a timer thread
<azonenberg>
a timer callback*
<azonenberg>
just use nonblocking io
<monochroma>
just have a raw RPC interface to all functions ;)
<azonenberg>
This should also tie into katharina's UI code so we have preferences to enable/disable said UI server
<noopwafel>
is that merged?
<azonenberg>
It's in the ui-dev branch
<azonenberg>
not merged to master yet
<azonenberg>
She's recovering from covid and has been slow to update it
<azonenberg>
last i heard she was out of the hospital and doing fairly well but not at 100%
<noopwafel>
*nod*
<noopwafel>
one nice thing about the scpi bridge is that I can connect multiple clients to it
<noopwafel>
and get live visualisation of side-channel captures while I also have a script writing (annotated) traces to disk for SCA
<azonenberg>
you made the scpi bridge already?
<azonenberg>
Would you be willing to contribute that to scopehal-apps?
<noopwafel>
eh, I hacked up something :p
<noopwafel>
the first draft was on my github somewhere
<noopwafel>
and nice, I had not noticed gui-dev branch at all..
<noopwafel>
let me grab a rigol and see how much I regret this
<azonenberg>
She's working on a bunch of improvements including a preferences system and a much nicer looking startup dialog
<noopwafel>
I am already regetting this
<Degi>
Oh geez im a maintainer now
<noopwafel>
oh ugh
<noopwafel>
glscopeclient is sending different commands to what I expected :p
<noopwafel>
no colons in front
<noopwafel>
what's the known-good for the rigol driver, ds1054z?
<azonenberg>
I think so
<azonenberg>
the mso5000 series seems to malfunction if you send commands too fast
<azonenberg>
we have plans for workarounds but theyr'e not implemented yet
<noopwafel>
this is a ds1102d, which really wants the colons at the front of commands, among other things
<azonenberg>
I had an 1102d years ago
<azonenberg>
it was actually the first driver i wrote for scopehal before it was even scopehal
<azonenberg>
but i guess the colons disappeared over time because i was testing on newer gear
<azonenberg>
Feel free to send a PR adding them
<azonenberg>
degi: please test on your newer gear
<noopwafel>
for a rigol scope it's .. actually responsive, which is nice
<Degi>
What exactly? Whether it goes faster with colons? Should I just git clone the newest commit?
NeroTHz has quit [Read error: Connection reset by peer]
<noopwafel>
I can PR something for testing in a bit - maybe I should add a new protocol enum
<noopwafel>
there's a few other problems, e.g. it's using CH1 and not CHAN1, and it doesn't support some things
<azonenberg>
Degi: no i mean whether the leading colons break things on your scope
<azonenberg>
yes new protocl enum is probably the way to go then
<azonenberg>
since CHx vs CHANx is definitely a per device difference
<Degi>
Colons is ';'?
<noopwafel>
:
<noopwafel>
right now it's inconsistent, some have : and some don't
<noopwafel>
http://noopwafel.net/random_rigol_colons.txt except you probably don't want that channel name change and I didn't check the rest, nor the programming manual for other rigol scopes :)
<azonenberg>
Yeah the channel name change definitely has to check the model number
<azonenberg>
i wonder why they did that
<noopwafel>
it doesn't support :WAV:PRE? so it will definitely be a model check
<Degi>
Hmh sending :wav:data? gets right reply
<azonenberg>
noopwafel: this is what i like about lecroy
<azonenberg>
as far back as i've gone, they use the exact same protocol and command set on everything
<azonenberg>
it's completely compatible
<azonenberg>
i've had to make a few tables for things like per model legal max memory/sample rate
<azonenberg>
but other than that, totally unified
<noopwafel>
just a little unaffordable :/
<azonenberg>
yeah
<azonenberg>
But a lot of other vendors have been breaking compat between lines
<azonenberg>
i wonder why, is it a totally new firmware each model?
<noopwafel>
in some of these cases, definitely yes
<azonenberg>
Lecroy is also very good about keeping a consistent UI etc across models
<noopwafel>
I mean, the low-end fw approach as opposed to Windows means this is maybe partially to be expected
<noopwafel>
I imagine the rs232 was the expected communication mechanism for this thing, and usbtmc was afterthought
<azonenberg>
Yeah no ethernet on that lol
<azonenberg>
i remember it well, it was my first scope i had all the way through college
<azonenberg>
i bought my first lecroy once i had a real job to pay for hardware :p
<noopwafel>
this is my uni dept's scope (I am PhD candidate, we are CS software group)
<noopwafel>
as a random debugging scope it's .. much better than nothing :)
<azonenberg>
Yeah
<noopwafel>
ah nice I hit the bug whitequark reported, now
<azonenberg>
Well it's reproducible, lol
<azonenberg>
Guess we have to do more digging on that
<azonenberg>
i'm in the middle of pulling fiber so intermittently away from the computer but i'm gonna try and go through pending tickets later today and see what i can do
<azonenberg>
you actually have a rigol in your lab though so if you want to troubleshoot more, great
<azonenberg>
also see if this is related to the hangs pepijndevos was complaining about
<noopwafel>
ah meh the naming is just inconsistent :/
bvernoux has quit [Quit: Leaving]
<noopwafel>
yes, will see what I can work out
<azonenberg>
noopwafel: related, but likely not a fix, is to add write queueing to transports
<azonenberg>
so that we don't need to block for a socket to become clear when sending a single command from the UI thread
<azonenberg>
it should be possible to queue that command
<azonenberg>
but that is nontrivial because some commands need responses, we have to match requests to responses, and we have to ensure thread safety
<azonenberg>
i haven't had time to sit down and figure out the details yet
<noopwafel>
I think the ds1054z is one of the scopes that really likes one packet per command
<noopwafel>
which is fun
<noopwafel>
so I wonder how well it would interact
<azonenberg>
when i say queueing i dont mean batching
<azonenberg>
i mean a fifo you can write to from multiple threads
<azonenberg>
then one thread that pushes them to the hardware and reads replies
<noopwafel>
*nod*
<azonenberg>
basically what we want to avoid is the situaition where you drag the vertical axis to change volts/div or something
<azonenberg>
and the ui freezes for 200ms while a waveform is downloaded and you can't get the mutex to send that command
<noopwafel>
ah, right, the UI blocking :/
<noopwafel>
sorry, not reading properly
<azonenberg>
So we want to make all write commands nonblocking
<azonenberg>
Reads will be inherently blocking, but most reads are related to downloading waveforms and that's already in another thread
<azonenberg>
most other reads are related to scope settings and those will block once then cache from there on out
<azonenberg>
improving ui responsiveness in general is on the todo list
<_whitenotifier-b>
[scopehal] noopwafel forked the repository - https://git.io/JJ0I1
<_whitenotifier-b>
[scopehal] noopwafel opened pull request #191: [WIP] fix support for Rigol DS1000D/E scopes - https://git.io/JJ0Id
<noopwafel>
got busy and going to bed now, just pushing local diff to a PR so it doesn't get lost
<noopwafel>
those hangs are super annoying for debugging :x but hopefully will track down tomorrow
Bird|ghosted has quit [Remote host closed the connection]