<azonenberg>
mubes: isnt that what they're supposed to do?
<d1b2>
<mubes> So, as far as I understand it, an urb can basically be any length, and it's split into usb-packaet sized frames and re-assembled at the far end. I think what Siglent have done is to break it into fragements to submit to the urb's.
<d1b2>
<mubes> So, in usbtmc, it sees a whole sequence of messages instead of the one big one it expects
<d1b2>
<mubes> ...and since the contents of those messages are nominally random at the tmc framing level, you see the funky errors.
<d1b2>
<mubes> Fix should be easy, submit the app level message as a single urb, and enjoy some speedup.
<azonenberg>
ah i see. So it's a firmware issue on their end
<d1b2>
<mubes> Well, I don't like to point fingers 'cos they have a habit of coming back and biting me, but I'm very suspicious. If so, there's a lot of speedup to be had here. I've sent them a question on it. Let's see.
<azonenberg>
also i found the 6" version of the 12" cable I've been using for AKL-PT5 testing
<azonenberg>
I think 6" is long enough for the ultra-flexible part
<azonenberg>
especially considering how lossy the micro coax is
<azonenberg>
so i ordered one and we'll see how it turns out
Ekho has quit [Quit: CORE ERROR, SYSTEM HALTED.]
Ekho has joined #scopehal
<azonenberg>
Hmmmm
<azonenberg>
Trying to think of the best way to design complex filter graphs with a huge number of signals
<azonenberg>
we might need some kind of bus abstraction
<azonenberg>
as an example, suppose we make a filter to convert single ended s-parameters to mixed mode s-parameters
<azonenberg>
the input is 32 channels of data (16 mag and 16 angle channels)
<azonenberg>
making the user select 32 dropdowns or draw 32 channels in the filter graph would be stupid
<azonenberg>
at the same time, we need to account for things like de-embeds and reference plane extension or normalization that may change some of those values
massi has joined #scopehal
<azonenberg>
now imagine chaining several of those to do ref plane extension or de-embedding
bvernoux has quit [Quit: Leaving]
_whitelogger has joined #scopehal
massi_ has joined #scopehal
Fridtjof has joined #scopehal
massi has quit [Ping timeout: 256 seconds]
GenTooMan has joined #scopehal
gruetzkopf has quit [Ping timeout: 250 seconds]
gruetze_ has joined #scopehal
someone-else has joined #scopehal
CarlosEDP has joined #scopehal
CarlosEDP has quit [Remote host closed the connection]
CarlosEDP has joined #scopehal
CarlosEDP has quit [Remote host closed the connection]
<Degi>
Maybe a python scripting window or so?
CarlosEDP has joined #scopehal
<azonenberg>
i mean you can script all kinds of stuff but i want a good way to do it in the GUI
mikolajw has joined #scopehal
sajattack[m] has joined #scopehal
tiltmesenpai[m] has joined #scopehal
fridtjof[m] has joined #scopehal
<azonenberg>
in terms of ways to gang related signals
<azonenberg>
automatically infer what s-params you want once you hook uip a few
<azonenberg>
just kinda musing out loud
<azonenberg>
but these are the kinds of things i will want for multigigabit differential channel design
CarlosEDP has quit [Quit: Client limit exceeded: 20000]
mikolajw has quit [Quit: Client limit exceeded: 20000]
sajattack[m] has quit [Quit: Client limit exceeded: 20000]
fridtjof[m] has quit [Quit: Client limit exceeded: 20000]
someone-else has quit [Quit: Connection closed]
<Degi>
Is the reference plane the point where the cable from the measuring instrument connects to the DUT?
<Degi>
azonenberg: Kinda like in spreadsheet programs where you can drag the corner and it auto-fills values?
<azonenberg>
Not exactly
<azonenberg>
The reference plane is the point from which the S-parameter measurement is supposed to be
<azonenberg>
i.e. zero phase
<Degi>
Ah
<azonenberg>
with a default calibration and no plane extension, this is at the end of the VNA test lead
<azonenberg>
but it's common to use plane extension to shift this to compensate for e.g. transmission line on a test fixture between the connector and the DUT
<Degi>
Do you do that by using the S parameters of that transmission line (probably without the DUT)?
<azonenberg>
so in that case the *calibration* plane is the end of the VNA lead while the *reference* plane is the footprint for the actual DUT
<azonenberg>
So, straightforward plane extension is purely a phase shift
<azonenberg>
i.e. it assumes ideal transmission lines of the specified length between the cal plane and the ref plane
<azonenberg>
In the real world, the line is not ideal
<azonenberg>
if you are able to obtain s-params of that line, you can de-embed it from the measurement
<azonenberg>
So you can think of plane extension as a degenerate case of de-embedding in which the line has perfectly linear phase and no loss
<Degi>
I see
<azonenberg>
and can be completely described by a scalar electrical length
<azonenberg>
I intend to support both
<azonenberg>
as far as where you get those s-params from, that's a whole other can of worms
<azonenberg>
one possible approach is by EM simulation of the fixture
<Degi>
Hmh, I mean ideal delay would just be a set of S params with linear phase increase with frequency...
<azonenberg>
Correct. You can totally implement plane extension as synthesis of s-params for an ideal transmission line followed by a general de-embed
<azonenberg>
although this would probably perform worse since it has to do math on the amplitude and ultiamtely not change it
<azonenberg>
vs just changing phase
<azonenberg>
Anyway so another approach for de-embedding - which i cannot currently do (the PicoVNA software does not support it)
<azonenberg>
is to create two versions of your fixture
<azonenberg>
one with the DUT, and another slightly shorter containing the same connectors and feed lines back to back with no DUT
<azonenberg>
i.e. a "2x thru"
<azonenberg>
you can measure s-params of this, then do some math i'm still trying to wrap my head around to get separate s-params for left and right halves of this known-symmetric network
<azonenberg>
then de-embed those individually from a measurement of the DUT on your fixture
<azonenberg>
and end up with a measurement of just the DUT
<azonenberg>
The PicoVNA software allows you to de-embed a .s2p from each port, but does not support calculating the two de-embedding networks from a 2x thru measurement
<azonenberg>
and since i am adding more s-param analysis capabilities to glscopeclient that's something i am thinking of doing
<azonenberg>
so i want to be able to use the PicoVNA software to measure the 2x thru and the thru-dut-thru paths on a fixture
<azonenberg>
then do my own postprocessing to extract just the DUT s-params
<azonenberg>
and then do time domain transforms, etc on that
<Degi>
Hmm neat
<Degi>
To combine S params can you just convert to complex amplitude and multiply them?
<azonenberg>
To a first order, yes. but this does not consider the case of multiple reflections
<azonenberg>
consider two networks N1 and N2 end to end
<Degi>
Hmm right, that would make it more complicated...
<azonenberg>
if you just multiply them together you get the energy that went through N1 and through N2
<Degi>
Similar to figuring out the impedance vs distance of a cable with a TDR
<azonenberg>
but you do not get stuff that reflected off the input of N2, into N1 again
<azonenberg>
back out N1, and through N2 again
<azonenberg>
Depending on the extent of your mismatch this could be significant or not
<azonenberg>
Right now, in glscopeclient i do not model this. you can apply two consecutive de-embeds to a signal but only a single path is modeled
<azonenberg>
so you only consider S21 -> S21 of the two networks
<azonenberg>
and not anything reflecting between them
<azonenberg>
my long term plan is to build a composition filter that, given two 2-port networks, outputs a new set of 2-port s-params equivalent to the combination of the two
<azonenberg>
which you can then de-embed or channel emulate
<azonenberg>
Doing this requires converting the S-params into something called ABCD-params which I think might also be the same as T-params
<azonenberg>
These do cascade, but cannot be directly applied to a signal
<azonenberg>
so I'd need go to from S to ABCD, cascade, then back to S
<azonenberg>
i have some reading material open that talks about the equations to do this
<azonenberg>
but haven't implemented it
<azonenberg>
before i do, i need to start thinking about what the UX is going to look like
<azonenberg>
because even a 2-port network has 4 measurements * 2 complex halves = 8 channels of data
<azonenberg>
and i don't want to hook up 8 ports to every filter when doing s-param stuff
<azonenberg>
I mean I *can* it'll just be ugly and labor intensive and not friendly to work with
<azonenberg>
while i could hypothetically create a new channel type for "2-port s-parameters" this has its own problems, like the fact that it would be restricted to 2 ports, and that it wouldn't easily allow access to the individual channels of data for display or analysis
<azonenberg>
since e.g. the group delay filter works on a single phase channel only
<azonenberg>
the de-embed and channel emulation filters work on a single complex channel
<azonenberg>
only network level transforms like cascading or ref extension would work on an entire network
<Degi>
Hmh, could you make a bus type channel which then applies the filter once to each channel?
<azonenberg>
it's not separately on each channel though