<azonenberg>
lain: so i think tonight i'm going to experiment with early de-embedding in scopehal
<lain>
:D
<azonenberg>
In particular, i'm going to do "scalar de-embedding"
<azonenberg>
i.e. correcting for frequency dependent loss only and assuming flat phase response
<azonenberg>
Just to start
<azonenberg>
Then i can worry about correcting phase later on
<azonenberg>
basically my plan is, fft the signal, linearly interpolate the S21 values from the provided S2P to find the loss at each FFT bin, multiply each bin by the inverse of the channel response, then inverse fft it
<azonenberg>
lain: i think to start i'll try feeding some test signals through one of the 6-foot rg188 cables. or even two end to end
<azonenberg>
and then see what happens when i de-embed them
<azonenberg>
and how close that looks to a direct feed of the signal with minimal cable loss
<azonenberg>
i'm a bit handicapped still since my 2 GHz scope is down for service, so i'm gonna use an extra lossy cable to make the effects more obvious
<lain>
:)
<azonenberg>
My thought is to feed the 40ps pulse generator (nice broadband source) into a splitter
<azonenberg>
then one path from the splitter through a super short low loss cable into the scope, considered the golden waveform
<azonenberg>
the other through a long lossy cable
<azonenberg>
Then see how close the de-embed looks
<azonenberg>
Longer term i'll want to support stacking multiple s2p's in a single de-embed
<azonenberg>
which would be pretty simple i think, most of the compute is in the FFT
<lain>
sounds reasonable
<azonenberg>
short term you'll have to manually type the absolute path as an argument
<azonenberg>
until i get a UI for it set up
<azonenberg>
also now that i think about it, i will want to correct for phase response at some point too. So if you know group delay of an element you can null that out
<azonenberg>
i.e. i dont necessarily care about *frequency dependent* delay as much
<azonenberg>
but absolute delay i do
<azonenberg>
but once i'm doing that it's silly not to de-embed full phase
<azonenberg>
The initial PoC will be amplitudes only though just to see how it looks
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
electronic_eel has quit [Ping timeout: 258 seconds]
electronic_eel has joined #scopehal
<_whitenotifier-b>
[scopehal] pepijndevos commented on issue #179: Add write queueing to transports for better handling of high-latency instruments - https://git.io/JJ8JV
<miek>
now i just need to fix my home network so i can poke at it..
<Degi>
neat
<_whitenotifier-b>
[scopehal-apps] pepijndevos commented on issue #146: glscopeclient hangs on Rigol MSO5000 - https://git.io/JJ8qr
<pepijndevos>
Degi, ^^^ Rigol basically says we're sending the wrong command sequence to read data. I don't think they are correct, but we'll see what they reply next.
<miek>
yeah, sounds like they haven't really understood the problem
<pepijndevos>
I mean, it's a sensible first line of support reply to make sure some rando on the web is sending the right commands. But *sometimes* getting a *partial* reply sounds... buggy
<pepijndevos>
But who knows... maybe setting MODE also blocks until the data is available or something silly like that.
deltab has quit [Ping timeout: 256 seconds]
juli964 has joined #scopehal
m4ssi has joined #scopehal
juli964 has quit [Client Quit]
<Degi>
pepijndevos: Have you sent them a trace of the data transferred ovef th esocket
<Degi>
I wonder how the web client handles it...
<pepijndevos>
Degi, I could not do so in their contact form, but did so in my reply to their email.
<pepijndevos>
web client?
<Degi>
Good
<Degi>
The thing you get when you put the scope IP into a web browser
<pepijndevos>
ah yea. it seems like that's just a frame loading an image?
deltab has joined #scopehal
<pepijndevos>
Which... so far honestly works better for recording a video of the scope than either their own software or this software
<Degi>
hahaha
<pepijndevos>
I just pointed OBS to a cropped browser window. It only refreshes every second, but so do either software packages tbh
<pepijndevos>
I actually ordered a HDMI USB capture thingy from aliexpress for a few bucks to do this at a higher frame rate.
<Degi>
Hmh they have their own software which you can like install as an application?
<pepijndevos>
yea
<pepijndevos>
I've been meaning to get a wireshark trace of it
<pepijndevos>
but it's only windows so have to dig up my old laptop
<Degi>
Maybe it runs in wine
<pepijndevos>
It's based on labview -.-
<Degi>
ugh
<pepijndevos>
yea maybe...
<pepijndevos>
I suspect it's just too slow to trigger the bug
<_whitenotifier-b>
[scopehal] azonenberg 0b35104 - DeEmbedDecoder: initial support for amplitude correction (see #183). Does not support phase correction yet.
<azonenberg>
pepijndevos: LOL
<azonenberg>
the rigol software has no channel to channel sync?
<pepijndevos>
Doesn't seem like it...
<pepijndevos>
I mean, that's the entire reason you do single shot in a loop right?
<Degi>
Wait what do you mean? Per-channel time offset?
<pepijndevos>
They run on auto, and I was curious how they do it. Apparently they just... ignore the problem
<pepijndevos>
Degi, you can get two traces from different triggers.
<Degi>
huh?
<pepijndevos>
Because the channels are just read one by one
<pepijndevos>
so it could be SOURCE CHAN1, DATA? [trigger] SOURCE CHAN2, DATA? and you'd get the *new* data for channel 2
<pepijndevos>
For this reason scopehal runs SING, loops on TRIG?, reads all channels, and runs another SING
<Degi>
Hmh isnt that the purpose of the trigger that it records a trace of each channel with the same time frame etc
<Degi>
uhuhu
<Degi>
When its in auto?
<Degi>
Why isnt there a get all data command anyways
<pepijndevos>
If only...
<pepijndevos>
Or transactions hehe
<Degi>
Hmh
<Degi>
Actually blondel might beat rigol...
<Degi>
At least the 4 ch version
<Degi>
I mean a rigol for 1 k has 70 MHz, 200 Mpts sample depth, some weird bugs, is closed source etc