azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi has joined #scopehal
<azonenberg> Hmm, i'm getting an annoyingly frequent crash
<azonenberg> seems to happen when i drag the trigger position bar, but only in some situations
<_whitenotifier-1> [scopehal-apps] azonenberg labeled issue #389: Crash in WaveformArea::DoRenderCairoOverlays() on line 372 - https://git.io/J2XqR
<_whitenotifier-1> [scopehal-apps] azonenberg opened issue #389: Crash in WaveformArea::DoRenderCairoOverlays() on line 372 - https://git.io/J2XqR
<_whitenotifier-1> [scopehal-apps] azonenberg commented on issue #389: Crash in WaveformArea::DoRenderCairoOverlays() on line 372 - https://git.io/J2XY1
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J2Xn2
<_whitenotifier-1> [scopehal] azonenberg c9cb937 - Fixed typo in comment
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±3] https://git.io/J2Xcj
<_whitenotifier-1> [scopehal-apps] azonenberg 63213eb - Fixed bug at large zoom levels
<_whitenotifier-1> [scopehal-apps] azonenberg ab9788b - Don't try to render trigger info if there's no scope attached to the current channel. Fixes #389.
<_whitenotifier-1> [scopehal-apps] azonenberg ed79115 - Updated submodules
<_whitenotifier-1> [scopehal-apps] azonenberg closed issue #389: Crash in WaveformArea::DoRenderCairoOverlays() on line 372 - https://git.io/J2XqR
Bird|ghosted has joined #scopehal
Stephie- has joined #scopehal
balrog_ has joined #scopehal
vup2 has joined #scopehal
Degi_ has joined #scopehal
Stephie| has joined #scopehal
Degi has quit [*.net *.split]
Bird|otherbox has quit [*.net *.split]
d1b2 has quit [*.net *.split]
Stephie has quit [*.net *.split]
balrog has quit [*.net *.split]
vup has quit [*.net *.split]
Degi_ is now known as Degi
vup2 has quit [Read error: Connection reset by peer]
Stephie- has quit [Ping timeout: 252 seconds]
vup has joined #scopehal
JSharp_ has joined #scopehal
miek__ has joined #scopehal
JSharp has quit [Ping timeout: 252 seconds]
miek has quit [Ping timeout: 252 seconds]
bgamari has quit [Ping timeout: 252 seconds]
JSharp_ is now known as JSharp
bgamari has joined #scopehal
Bird|ub3rghosted has joined #scopehal
Bird|ghosted has quit [Ping timeout: 252 seconds]
lain has quit [Ping timeout: 252 seconds]
lain has joined #scopehal
someone-else has joined #scopehal
someone-else has quit [Quit: Connection closed]
vup has quit [Read error: Connection reset by peer]
vup has joined #scopehal
<_whitenotifier-1> [scopehal] azonenberg opened issue #512: FFTFilter results with and without OpenCL do not agree - https://git.io/J2jMP
<_whitenotifier-1> [scopehal] azonenberg labeled issue #512: FFTFilter results with and without OpenCL do not agree - https://git.io/J2jMP
<azonenberg> Hmmmm
<azonenberg> So now that i'm looking at output from this signal generator in glscopeclient i am seeing slight mismatches in results between what i expect and what i actually get
<azonenberg> Reference (LeCroy FFT option): https://www.antikernel.net/temp/fft-lecroy.png
<azonenberg> glscopeclient using FFTS: https://www.antikernel.net/temp/fft-noopencl.png
<azonenberg> glscopeclient using clFFT: https://www.antikernel.net/temp/fft-opencl.png
<azonenberg> All are using the same sample data as input and a Blackman-Harris window
<azonenberg> as you can see the results are inconsistent
<azonenberg> Me vs the scope disagreeing could be explained in part by methodology
<azonenberg> but clFFT and FFTS should give identical results
miek__ is now known as miek
<miek> can you compare them by working from a save file instead, so the samples are identical?
<azonenberg> I am
<azonenberg> but the scope had the same sample data
<azonenberg> So three different algorithms processing the same data and giving three different results
<miek> oh, why are the time domain plots different?
<azonenberg> oh i think i did do live updates not save data for those screenshots?
<azonenberg> let me re-render
<azonenberg> the opencl version almost looks like even/odd samples are swapped or something like that
<azonenberg> see the weird dip on the left edge of the main peak
<azonenberg> or some kind of interleaving issue
<azonenberg> digging more... with a rectanguular window, i get what looks like identical output
<azonenberg> so the problem might be specific to blackman-harris?
<azonenberg> or at least to all windows other than rectangualr
* azonenberg digs deeper
<azonenberg> good news is this means the fft and rendering paths are probably ok and the issue is specific to the window functions
<azonenberg> The plot thickens... it seems that the C++ implementation and the OpenCL version agree, and might be giving the right answer
<azonenberg> and the AVX2 version is acting different...
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JafNK
<_whitenotifier-1> [scopehal] azonenberg 632dec4 - FFTFilter: fixed AVX2 implementation of Blackman-Harris window multiplying alpha3 by cos(3*num) instead of cos(6*num) See #512.
<azonenberg> Ok, so that solves the first issue, my different implementations being inconsistent
<azonenberg> The second question is why the LeCroy specan is so different from mine
<electronic_eel> is it consistent over different lecroy scopes? iirc you have two different models
<azonenberg> I only have the specan for the 4 GHz
<azonenberg> its a software option
<azonenberg> I'm inclined to believe those results above mine, though, because mine look "funny" still
<azonenberg> sec
<azonenberg> Three different issues to account for
<azonenberg> 1) the LeCroy specan reports the center peak of the signal at almost exactly 1 GHz
<azonenberg> I see it at 999.9225 MHz which is a fair bit off
<azonenberg> That's 77.5 kHz off. And the FFT bin size for this config is 596 Hz
<azonenberg> So i'm about 130 bins off where I should be
<azonenberg> 2) the actual amplitude of the incident signal is 0 dBm through two FL086-24SM+ cables, a SMA-SMA coupler, a SMA-BNC adapter, and a SMA-N adapter
<electronic_eel> -2.7dBm seems reasonable through these cables and adapters, -9 not
<azonenberg> The cables have 0.39 dB insertion loss at 1 GHz, times two is about 0.8 dB, adding in losses from the couplers and such the -2.7 dBm amplitude reported by the scope specan sounds reasonable for the peak
<azonenberg> considering also there is some content outside the peak
<azonenberg> But yes, the peak amplitude I'm getting seems way off
<azonenberg> Interestingly, it seems to vary with the record length
<azonenberg> as an example, I changed the config to 2.5 megasamples at 5 Gsps, which is a 1.192 kHz RBW
<azonenberg> I now measure -3.5 dBm for the peak while the lecroy specan reports -3.8, which is far more reasonable
<azonenberg> and more importantly, the integrated in-band power glscopeclient reports is -0.9 dBm
<azonenberg> Which is almost exactly what I calculate I should be seeing
<azonenberg> Conjecture: when my record length is not a power of two I zero-pad
<azonenberg> I probably need to correct for that because the overall energy in the FFT input is reduced by this
<azonenberg> i bet i need to scale by the number of FFT input samples that actually contain data vs the number of FFT bins
<azonenberg> 3) the LeCroy specan output has nice smooth curves while I have a scalloped-looking pattern
<azonenberg> also interesting that I am reporting RBW of exactly half what the lecroy fft calculates
<azonenberg> These might be connected
<azonenberg> Like, to five significant digits
<azonenberg> So I guess the question is, how am i doing a fft of the same size, on the same data, using the same window function, and getting such dramatically different results?
Stary_ is now known as Stary
<azonenberg> It looks like they might be doing some kind of averaging or postprocessing
<azonenberg> Unless they're truncating rather than zero padding the input
<azonenberg> Yeah, it looks a lot better padded. interesting
<azonenberg> truncated*
<azonenberg> And truncated I get results more like what they do
<electronic_eel> hmm, does it fix the frequency offset you were getting?
<azonenberg> Still working on that bit
<azonenberg> i thought maybe i had an off by one from the DC bin
<azonenberg> but it looks like more than that
<azonenberg> I'm adding a config option to let you zero pad or truncate
<azonenberg> so we'll see what that does and move from there
<azonenberg> But yeah i did not realize zero padding would give me such an awful lookng spectrm
<azonenberg> So I still have a frequency offset for my center point, but the RBW and peak amplitude as well as the general spectrum shape line up very nicely with the lecroy specan
<azonenberg> (still using rectangular window for this screenshot just to do apples to apples)
<miek> are you applying the window function before or after padding?
<azonenberg> Kinda simultaneous
<azonenberg> it copies and windows in one operation and anything off the end of the window kernel gets zeroed out
<azonenberg> but i'm in the process of double checking i scale the window correctly for the input size
<azonenberg> anyway that last screenshot is a rectangular window in truncate mode
<azonenberg> rather than zero padding
<azonenberg> so any impact of padding and windowing is removed from the equation
<azonenberg> now i get very close to what the lecroy specan does except for the offset on the center point
<azonenberg> It looks like I've got a constant offset of two frequency bins which i think is related to the DC offset
<azonenberg> but i'm double checking that
<azonenberg> aha, i've got two separate bugs it looks
<azonenberg> 1) yes, I didn't account for the DC offset so every bin was one less than it should have been
<azonenberg> 2) peak detection seems to be reporting a location one bin left of where it should
vup has quit [Ping timeout: 245 seconds]
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±5] https://git.io/JaILi
<_whitenotifier-1> [scopehal] azonenberg 6bf5c2b - FFTFilter: added options for both truncation and zero padding. Fixed a bunch of bugs in normalization and peak location. Fixes #512.
<_whitenotifier-1> [scopehal] azonenberg closed issue #512: FFTFilter results with and without OpenCL do not agree - https://git.io/J2jMP
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±3] https://git.io/JaIqo
<_whitenotifier-1> [scopehal-apps] azonenberg 03f1ccd - Updated submodules
<_whitenotifier-1> [scopehal-apps] azonenberg 334bdea - Added --noavx512f and --noavx2 flags for testing
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JaLOF
<_whitenotifier-1> [scopehal] azonenberg 3ced39f - FFTFilter: scale by coherent power gain of window function
someone-else has joined #scopehal
balrog_ is now known as balrog
vup has joined #scopehal