azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
juli966 has quit [Quit: Nettalk6 -]
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 246 seconds]
Degi_ is now known as Degi
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
<azonenberg> So playing around in the lecroy SDA software, it looks like i can undo the pcie de-emphasis with an 8-tap delay line filter, one UI per tap, using some magic coefficients
<azonenberg> the question is how to calculate those coefficients
<sorear> snoop link init, get them there?
<azonenberg> better
<azonenberg> equation 2
<azonenberg> figure 2*
<_whitenotifier-f> [scopehal] azonenberg pushed 2 commits to master [+4/-0/±9]
<_whitenotifier-f> [scopehal] azonenberg 960a504 - Initial implementation of TappedDelayLineFilter. See #51.
<_whitenotifier-f> [scopehal] azonenberg c9959b5 - Initial implementation of EmphasisRemovalFilter
<_whitenotifier-f> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [scopehal-docs] azonenberg 900019a - Added skeleton doc pages for tapped delay line and emphasis removal filters
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-f> [scopehal-apps] azonenberg afde43d - Updated submodules
<azonenberg> the filter is a little slow right now because there's no AVX optimizations yet. That's on my to-do list
<azonenberg> But it does work
<sorear> why is the right eye wider, isn't the pre-emphasis supposed to improve things
<azonenberg> sorear: i'm undoing the de-emphasis
<azonenberg> The emphasis is intended to make things better *at the far side of the link*
<azonenberg> it will actually look worse up front
<azonenberg> basically you're applying the inverse of the estimated channel transfer function up front
<azonenberg> i'm measuring right next to the TX
<azonenberg> Very often you will want to remove emphasis from a signal in order to measure the true amount of jitter present
<azonenberg> as you can see in the left plot, the histogram has multiple peaks indicating there's data dependent jitter being added by the emphasis filter
<azonenberg> which makes sense, emphasis is essentially ISI by definition
<azonenberg> It's just calculated to be the exact inverse of the channel ISI
<azonenberg> (or at least close enough)
<azonenberg> So if you want to measure jitter at the tx, you have to either turn off the emphasis (if there's register settings to do that)
<azonenberg> or just remove it in post
nelgau has quit []
<azonenberg> also i think i figured out my audio noise problems, it seems the cheap 2.4 GHz wireless mic i was using was one of the main contributors
<azonenberg> but the pc sound card was also not goo
<azonenberg> good*
<azonenberg> a usb sound card and the same headset i was using appears to have a massively better snr
juli966 has joined #scopehal
<lain> :3
<azonenberg> lain: i'm gonna be putting together a new glscopeclient demo video shortly, focusing on PCIe as the test subject
<azonenberg> i'm gonna be showing off both some new features as well as old stuff all in one video
<azonenberg> trying to go for slightly higher production value than i have in the past so i'm actually writing up a high level outline of the demo
<azonenberg> not like a full script with everything i say, but the list of things i'm demonstrating in order etc
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-f> [scopehal] azonenberg 550bbf2 - TIE measurement: allow skipping a short time at the start. Persist min/max autorange better.
<lain> nice
<azonenberg> right now my plan is to do spread spectrum clock analysis, looking at modulation frequency/depth
<azonenberg> then PCIe protocol decoding up to TLPs
<azonenberg> eye pattern of the original signal, then remove the 6 dB of de-emphasis and compare the difference in eyes
<azonenberg> then emulate a lossy channel and show how the emphasis helps
<azonenberg> also probably playing with removing some of the emphasis to see how much you need for different channels
<azonenberg> then jitter analysis of the signal as is, with emphasis removed, and after a lossy channel
<azonenberg> Anything else you can think of that would be cool to demo on the same signal?
<lain> not off the top of my head
<azonenberg> oh, i'll throw a fft on there too
<azonenberg> so you can see how there's no peaks because of the spread spectrm clocking
<monochroma> oh that will be cool
<azonenberg> and a waterfall
<azonenberg> that will be a cool lead-in to the spread spectrum analysis
<lain> :D
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [scopehal-apps] azonenberg 433b252 - Updated to latest scopehal
<azonenberg> Well that was annoying. i just recorded a whole glscopeclient demo
<azonenberg> and the video is totally hosed
<azonenberg> Choppy audio and dropped frames. it looks like the recording software couldnt keep up or something
<azonenberg> i told it 30fps and it's like 2fps
<lain> oop
<monochroma> :<
<_whitenotifier-f> [scopehal] mjgerm forked the repository -
<_whitenotifier-f> [scopehal-apps] azonenberg opened issue #291: Crash when history depth is set to zero -
<_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #291: Crash when history depth is set to zero -
<_whitenotifier-f> [scopehal] mjgerm opened pull request #353: I2S Decoder Implementation -
<azonenberg> So basically it seems kazam is a trainwreck and obs studio has no problem keeping up
<azonenberg> time to reshoot the whole demo again. guess i got a free rehearsal out of it :p
<monochroma> heh
maartenBE has quit [Ping timeout: 256 seconds]
maartenBE has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
_whitelogger has joined #scopehal
<bvernoux> I think I have found a fix for Rigol MSO5000
<bvernoux> sometimes there is no data for 1st channel
<bvernoux> but it is possible to detect that with socket as it returns 1 bytes and the value is always 0x0A which is end of data marker
<azonenberg> Interesting
<azonenberg> I guess the question is how we want to handle that
<azonenberg> do we throw away data from the other channels and pretend it didn't trigger?
<azonenberg> or do we leave the old data on that channel?
<azonenberg> neither is good, i'm not sure what makes the most sens
<azonenberg> sense*
<bvernoux> it is quite simple
<bvernoux> we just need to retry the data for current channel
<bvernoux> and it works ;)
<bvernoux> just send again
<bvernoux> :WAVeform:DATA?
<bvernoux> also a big improvement will be to manage timeout on RX
<bvernoux> to be configurable to avoid to be locked in case we do not have all data for robustness purpose
bvernoux has quit [Quit: Leaving]
<azonenberg> oh great
<d1b2> <LoialOtter/DCFurs> Ooo, awesome seeing this here!
<miek> isn't this just #146 popping back up? "t is hard to tell from the trace, but my impression is that when the time between the TRIG:STAT? reply and the WAV:DATA? command is short, it bugs out and sends nothing."