azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [scopehal] azonenberg d36d4a9 - JitterSpectrumFilter: only look at the first 5K UIs in EstimateUIWidth()
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [scopehal] azonenberg 8d3c3f0 - Filter::FindZeroCrossings: dense pack optimizations
juli966 has quit [Quit: Nettalk6 -]
electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel has joined #scopehal
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-f> [scopehal-apps] azonenberg 679e6cd - HistoryWindow: don't crash on invalid history depths. Fixes #291.
<_whitenotifier-f> [scopehal-apps] azonenberg closed issue #291: Crash when history depth is set to zero -
m4ssi has joined #scopehal
massi_ has joined #scopehal
m4ssi has quit [Quit: Leaving]
Belieffresh has joined #scopehal
juli966 has joined #scopehal
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-f> [scopehal] azonenberg 2dce249 - IBM8b10bDecoder: print disparity in dotted format (ex: K28.5-)
bvernoux has joined #scopehal
<bvernoux> I have very good news
<bvernoux> I have finally found how to fix Rigol MSO5000 with glscopeclient ;)
<bvernoux> and it is rock stable ;)
<bvernoux> it is always slow like 1 WFM/s but now it is stable
<azonenberg> bvernoux: Yay
<azonenberg> how?
<bvernoux> just adding "*WAI" after :SING
<azonenberg> Awesome.
<bvernoux> it synchronize internal states correctly and all work fine
<bvernoux> without any workaround to do and it does not slow down anything ;)
<azonenberg> Nice
<bvernoux> now we can improve the reception
<azonenberg> send a PR
<bvernoux> yes
<bvernoux> it is a major fix as Rigol MSO5000 was unusable with freeze ...
<bvernoux> in best case it was working with 250WFM ;)
<bvernoux> there still something strange in glscopeclient
<bvernoux> The GUI seems tightly coupled with the slowness of the 1 WFM/s
<bvernoux> Do you know why ?
<azonenberg> It's probably blocking on something it shouldn't be blocking on
<azonenberg> most likely something is holding a mutex waiting for a reply to a query
<azonenberg> and that's blocking something else
<bvernoux> yes which block the UI at end
<azonenberg> I try to keep all of the slow blocking stuff in ScopeThread
<azonenberg> and not the gui thread
<bvernoux> as for me the UI shall be totally decoupled with the scope WFM slowness
<azonenberg> but clearly that isnt perfect
<azonenberg> Yes. Write queueing should fix that
<bvernoux> ok nice to know
<bvernoux> let's puhs my simple fix ;)
<azonenberg> It's just a major refactoring and i can only do so many of those at a time
<azonenberg> the ps to fs fix was also a major refactoring, it touched every driver and every filter
<azonenberg> i got that out of the way at least
<bvernoux> could you reopen it ?
<azonenberg> that bug was against scopehal-apps. if the real bug is in the driver i should move that to scopehal?
<bvernoux> other heavy improvement is to simpify it in 2nd time
<bvernoux> removeing "WAV:STAR " & "WAV:STOP " commands
<bvernoux> as they are not required
<bvernoux> and that let win previous time to reach something like 0.7s per WFM instead of 0.95s ;)
<azonenberg> Did you only do that for MSO5? they might be needed for DS
<bvernoux> and even more on big chunk of data like 10M which are loaded in 1s
<azonenberg> the comments seem to suggest that at least some scopes can only download 250K points at once
<bvernoux> yes we can add a check
<bvernoux> anyway let's fix the main issue first
<bvernoux> I will do an other commit to improve performances for MSO5000
<bvernoux> I have done multiplatform test code to test things ;)
<bvernoux> it is faster than rebuilding glscopeclient
<azonenberg> how long does it take you to rebuild glscopeclient? it compiles in maybe a minute or so for me from scratch
<bvernoux> it is my code to experiment and monitor the performances
<bvernoux> it works/build on Windows & GNU Linux
<bvernoux> yes it take something like 3minutes from scratch
<bvernoux> but it is easier to experiment with my small code
<azonenberg> I just checked, on my workstation 60.9 sec wall clock time to rebuild from scratch
<bvernoux> I have some statistics ...
<azonenberg> 885.39 sec user, 82.88 sys
<bvernoux> my PC is old ;)
<azonenberg> Fair enoguh
<bvernoux> I cannot
<bvernoux> I will link this with the pull request
<bvernoux> as it fix an issue anyway
<azonenberg> bvernoux: just send the PR without linking to the issue
<azonenberg> its already closed, i dont see the point in reopening it just to close it again a second later
<bvernoux> yes
<miek> mention it in the PR at least, having the history linked is useful
<azonenberg> let me move #146 to scopehal then
<azonenberg> sinc eits a scopehal bug, not a glscopeclient bug
<_whitenotifier-f> [scopehal-apps] azonenberg unlabeled issue #146: glscopeclient hangs on Rigol MSO5000 -
<_whitenotifier-f> [scopehal] pepijndevos opened issue #358: glscopeclient hangs on Rigol MSO5000 -
<_whitenotifier-f> [scopehal] azonenberg commented on issue #358: glscopeclient hangs on Rigol MSO5000 -
<_whitenotifier-f> [scopehal] azonenberg reopened issue #358: glscopeclient hangs on Rigol MSO5000 -
<azonenberg> ok it's now scopehal:#358
juli966 has quit [Quit: Nettalk6 -]
<_whitenotifier-f> [scopehal] bvernoux opened pull request #359: Fix glscopeclient hangs on Rigol MSO5000 -
<bvernoux> pushed ;)
<_whitenotifier-f> [scopehal] bvernoux commented on issue #358: glscopeclient hangs on Rigol MSO5000 -
<_whitenotifier-f> [scopehal] azonenberg closed pull request #359: Fix glscopeclient hangs on Rigol MSO5000 -
<_whitenotifier-f> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±2]
<_whitenotifier-f> [scopehal] bvernoux 6bfbfb4 - Fix Rigol MSO5000 issues/timeout bugs when retrieving :WAV:DATA Fix the issue glscopeclient hangs on Rigol MSO5000 This fix oscilloscope single trigger synchronization with waveform data by adding "*WAI" command which "Waits for all the pending operations to complete before executing any additional commands." (it is an
<_whitenotifier-f> IEEE488.2 Common Commands)
<_whitenotifier-f> [scopehal] azonenberg 7d3f4dc - Merge pull request #359 from bvernoux/patch-1 Fix glscopeclient hangs on Rigol MSO5000
<_whitenotifier-f> [scopehal] azonenberg commented on issue #358: glscopeclient hangs on Rigol MSO5000 -
<_whitenotifier-f> [scopehal] azonenberg closed issue #358: glscopeclient hangs on Rigol MSO5000 -
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 2 commits to master [+2/-0/±6]
<_whitenotifier-f> [scopehal-apps] azonenberg 3ea598a - Initial implementation of WaveformGroupPropertiesDialog. Fixes #53.
<_whitenotifier-f> [scopehal-apps] azonenberg 58711f3 - Updated to latest scopehal
<_whitenotifier-f> [scopehal-apps] azonenberg closed issue #53: Allow display name of waveform groups to be changed -
<_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [scopehal] azonenberg 87e48ea - RigolOscilloscope: add dense pack flag to acquired waveforms
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [scopehal-apps] azonenberg 4c12526 - Updated to latest scopehal
<bvernoux> nice
<bvernoux> there is an issue with the scaling in fact
<bvernoux> I need to understand what happen
<bvernoux> with 1 chan basic all work fine
<bvernoux> but here I have set 4 chan with different voltage scale for each channel and the display is not very good
<bvernoux> using SigGen on 2 chan
<bvernoux> and test signal on 2 other chan
<bvernoux> the issue is the min vertical is too low
<bvernoux> IIRC such settings are computed in live depending on min/max for each channel ?
<azonenberg> The vertical scale for each channel should be queried from the instrument
<azonenberg> it's cached, so if you twiddle knobs on the scope glscopeclient won't update unless you hit the refresh settings button on the toolbar
<azonenberg> this is necessary to avoid constant polling which would slow things down immensely
<bvernoux> yes I have done the refresh from instruments
<bvernoux> but the scale is wrong
<bvernoux> also horizontal scale at start is wrong
<bvernoux> do you have done some test to build glscopeclient with -O3 without debug max optim ?
<bvernoux> as by default I'm using standard build so it is with debug and I suspect -O1
<miek> set cmake to do a Release build
<bvernoux> yes I know I just want to know the impact ;)
<bvernoux> the gain
<bvernoux> as here on my PC glscopeclient is not very fast
Bird|otherbox has quit [Remote host closed the connection]
Bird|otherbox has joined #scopehal
<miek> ah! i misread
<azonenberg> bvernoux: I do all of my development in release config except when tracking down crashes, in which case i go to debug
<azonenberg> which is -O0 + asan
<azonenberg> It's substantially slower
<azonenberg> but i dont have hard numbers for you
<azonenberg> also how new is your CPU? If it supports AVX2, things will be much faster
<azonenberg> on a lot of the signal processing blocks
electronic_eel_ has joined #scopehal
<miek> maybe cmake should be set to default to release?
<bvernoux> I suspect it support AVX2
electronic_eel has quit [Ping timeout: 265 seconds]
<bvernoux> CoreI7-3630QM
<bvernoux> it is quite old but IIRC AVX2 is not very new too ;)
<azonenberg_work> It does AVX1 only
<bvernoux> ha
<bvernoux> also there is a mistake in build flags
<bvernoux> for -O3
<bvernoux> you shall remove -g
<bvernoux> as all optimisation are not enabled in case of -g -O3
<azonenberg_work> I want debug information still
<azonenberg_work> It's not a mistake. that's intended to be the default configuration for using it
<bvernoux> yes but that avoid best optimisations
<azonenberg_work> we can make a separate "release no debug info" config
<bvernoux> yes
<azonenberg_work> but realistically, it shouldn't matter. most of the heavy lifting is done in just a few functions
<azonenberg_work> and these tend to be hand tuned anyway
<bvernoux> so by default it build in Release mode ?
<bvernoux> it was not very clear with Cmake
<azonenberg_work> I dont know what the default is
<azonenberg_work> i always specify explicitly
<bvernoux> yes now I specify it explicitly
<miek> i'm pretty sure -g doesn't disable optimisations, where are you getting that from?
<bvernoux> miek, on some CPU it avoids to have all optimisations
<azonenberg_work> to give you an idea of what the actual performance critical stuff looks like
<miek> the gcc man page kinda says the opposite, it says that you can use -g with -O, but the optimisations might break your ability to debug. nothing about disabling optimisations
<azonenberg_work> yes, exactly
<bvernoux> anyway I definitely need a new PC ;)
<bvernoux> I'm waiting Ryzen5 to have a beast
<bvernoux> which crush all Intel CPU ;)
<miek> might be thinking of -Og?
<bvernoux> will be interesting to see how Ryzen5 work with glscopeclient ;)
<azonenberg_work> Yeah probably. I do want to have a release no debug option available for reduced size binary releases
<azonenberg_work> i'd like to ship binaries available with full debug info and stripped
<monochroma> could do external debug files
<bvernoux> hehe with Release flag the bin is definitely not the same ;)
<azonenberg_work> Yeah i havent used that option myself but i think thats how debian does it now
<azonenberg_work> with separate -dbgsym packages
<bvernoux> 28MB for glscopeclient
<bvernoux> with Release
<bvernoux> before it was 22MB I suspect it was debug build by default
<azonenberg_work> There might be an "unspecified" config that's neither debug nor release
<bvernoux> as optimisation with unroll/loop increase the bin size ...
<bvernoux> ha yes ;)
<azonenberg_work> the 6 MB might be debug info
<azonenberg_work> if that's not enabled globally
<azonenberg_work> idk
<bvernoux> yes I suspect it was a strange build version ;)
<bvernoux> the release seems quite faster
electronic_eel_ has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
<bvernoux> I have something strange now
<bvernoux> glscopeclient.exe --debug myscope:demo:null:null
<bvernoux> just crash
<bvernoux> with latest build
<azonenberg_work> Works fine for me on linux. stack tracE?
<azonenberg_work> trace*
<_whitenotifier-f> [scopehal] bvernoux opened pull request #360: Optimize Rigol MSO5000 AcquireData -
<bvernoux> an other optimization ;)
<bvernoux> with about 10 to 15% gain ;)
<bvernoux> azonenberg_work, Yes I need to check why
<bvernoux> It impact only the Release version it is strange
<_whitenotifier-f> [scopehal] azonenberg closed pull request #360: Optimize Rigol MSO5000 AcquireData -
<_whitenotifier-f> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±2]
<_whitenotifier-f> [scopehal] bvernoux 4392d25 - Optimize Rigol MSO5000 AcquireData Optimize Rigol MSO5000 AcquireData as it does not requires "WAV:STAR" "WAV:STOP" SCPI commands before to call "WAV:DATA?"
<_whitenotifier-f> [scopehal] azonenberg e36efd2 - Merge pull request #360 from bvernoux/patch-1 Optimize Rigol MSO5000 AcquireData
<_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [scopehal-apps] azonenberg 6d368af - Updated scopehal with Rigol fixes
<azonenberg> bvernoux: and yeah in general, any optimizations that result in less commands going to the scope are going to be a significant performance increase
<bvernoux> yes
<codysseus> azonenberg: So I have played around with that example you wrote and it is cool! I am now trying to use it to extract the waveforms of each packet, but am struggling a bit. I tried converting from the offset back into rows in the CSV, but am getting odd results (m_offset + m_len > next packet's m_offset) am I going about this the right way?
<bvernoux> the explicit -DCMAKE_BUILD_TYPE= is missing
<bvernoux> for both Linux & Windows
<_whitenotifier-f> [scopehal-apps] bvernoux commented on issue #28: Improve state of developer documentation -
<azonenberg> codysseus: m_offset should be the number of time ticks since the start of the waveform for that packet
<azonenberg> with time ticks measured in m_timescale femtoseconds
<azonenberg> offset+len should always be <= next offset, however it is possible there are bugs causing an incorrect offset
<azonenberg> When importing a CSV, i believe i always convert the input timestamp to femtosecond resolution since there's no way of knowing what the original scope's sample rate was
<azonenberg> or if the samples are even at uniform intervals
<codysseus> I will check with the unmodified values to make sure that is the case. I had tried to do some modification to make them correspond to CSV row numbers but that might have altered the value significantly.
<bvernoux> very strange this crash with demo
<bvernoux> with debugger it does not crash ;)
<azonenberg> bvernoux: try debug build with asan and see if that gives you any info?
<azonenberg> (just run it, not under debugger)
<bvernoux> debug build does not crash too
<bvernoux> only the release
<bvernoux> when launched without debugger ;)
<azonenberg> do you get any memory errors in asan that aren't fatal?
<bvernoux> I does not have the setup for asan
<azonenberg> debug build should compile with asan by default
<azonenberg> unless you changed settings
<bvernoux> but here my issue is with Release
<azonenberg> Yeah, those are tricky to catch
<azonenberg> can you enable coredumps and get a core?
<bvernoux> I'm checking with VIsual Studio ;)
<azonenberg> codysseus: the best way to trace back to a sample number on the input waveform is probably just to binary search the timestamp
<bvernoux> it seems related to FFT
<azonenberg> bvernoux: it's likely related to alignment then
<azonenberg> possible the aligned memory allocator isn't acting right on windows
<bvernoux> yes I suspect something like that too
<bvernoux> which will explain sometimes it works
<bvernoux> depending on memory ...
<azonenberg> Yeah
<bvernoux> Unhandled exception at 0x0000000001F82A56 (libscopehal.dll) in glscopeclient.exe: 0xC0000005: Access violation writing location 0x0000000011FE0000.
<azonenberg> well that's great. stack trace? anything obvious?
<bvernoux> 0000000001F82A50 66 41 0F 28 1C 4E movapd xmm3,xmmword ptr [r14+rcx*2]
<bvernoux> 0000000001F82A56 41 0F 29 1C 0A movaps xmmword ptr [r10+rcx],xmm3
<bvernoux> 0000000001F82A5F 4C 39 E9 cmp rcx,r13
<bvernoux> 0000000001F82A5B 48 83 C1 10 add rcx,10h
<bvernoux> 0000000001F82A62 75 EC jne 0000000001F82A50
<azonenberg> assembly without knowing what function it's in etc isn't all that useful :)
<bvernoux> it is in Visual Studio let me check how to retrieve all the context
<azonenberg> in any case, file a new bug against libscopehal for it
<bvernoux> I suspect it cannot parse correctly debug as it is build with mingw64 ...
<azonenberg> yeah it might have dwarf and not pdb debug info
<azonenberg> why not use gdb?
<azonenberg> can you attach gdb once it's started and then make it crash?
<bvernoux> yes I will try to attach with gdb
<bvernoux> as natively it is VS which is launched when something crash
<bvernoux> so far I cannot make it crash when launched from gdb
<bvernoux> it is the hard part ;)
<azonenberg> Yay for heisenbugs
<bvernoux> ha yes catched
<bvernoux> Thread 17 received signal SIGSEGV, Segmentation fault.
<bvernoux> [Switching to Thread 4808.0x1e94]
<bvernoux> 0x0000000002132a56 in ffts_generate_table_1d_real_32f ()
<bvernoux> from C:\msys64\home\Ben\glscopeclient_build_release\libscopehal.dll
<bvernoux> #0 0x0000000002132a56 in ffts_generate_table_1d_real_32f ()
<bvernoux> (gdb) bt
<bvernoux> from C:\msys64\home\Ben\glscopeclient_build_release\libscopehal.dll
<bvernoux> #1 0xfffd17f9fffd15c8 in ?? ()
<bvernoux> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
<azonenberg> interesting
<bvernoux> yes ;)
<azonenberg> so ffts itself is crashing
<codysseus> azonenberg: I did a simple test (p1 offset + len > p2 offset) and there are a lot of packets which overlapped.
<azonenberg> codysseus: can you send me an input file demonstrating the bug along with any test code needed to reproduce? it's likely a bug in the usb decode
<codysseus> Sure thing!
<azonenberg> File a bug against libscopehal for it as well
<azonenberg> anything you're ok with sharing publicly should go on the tracker
<bvernoux> haha maybe it is because my CPU does not support SSE3 ;)
<azonenberg> bvernoux: o_O. i dont know if ffts does any auto detection of that or not
<bvernoux> I see that in code
<bvernoux> #ifdef HAVE_SSE3
<bvernoux> #else
<bvernoux> ffts_generate_table_1d_real_32f(p, sign, 0);
<bvernoux> ffts_generate_table_1d_real_32f(p, sign, 1);
<bvernoux> #endif
<bvernoux> so I suspect ;)
<azonenberg> hmm, can you check what it actually passed?
<azonenberg> i know in my case i compile for generic x86_64 and then enable AVX2 on a per-function basis
<azonenberg> if it's present
<bvernoux> I have used default conf
<azonenberg> I do this at run time so one binary will run on both avx2 and no-avx2 cpus
<bvernoux> just
<azonenberg> yeah gcc *should* detect that. but cant hurt to investigate further
<bvernoux> in thr Cmakefile I see something which try to detect SSE3 ...
<bvernoux> anyway my CoreI7 support SSE3
<azonenberg> So its not that
<azonenberg> it could be bad aligment or something else
<bvernoux> Fix compilation for non SSE machines
<bvernoux> ;)
<bvernoux> ffts seems abandonned
<bvernoux> lot of PR without any merge since lot of time
<_whitenotifier-f> [scopehal] Codysseus opened issue #361: USB Decoder does not function correctly. -
<bvernoux> this fork seems more up to date
<bvernoux> let me try ;)
<bvernoux> it is broken
<bvernoux> I'm rebuilding ffts with -DENABLE_SHARED=ON
<bvernoux> this flag was not included
<bvernoux> it crash with demo
<bvernoux> for info asan seems not supported for MSYS2 MINGW64
<azonenberg> Good to know
<azonenberg> and yes ffts is not well maintained
<azonenberg> the problem is, it's one of the few reasonably decent non-GPL fft libraries
<azonenberg> i looked
<azonenberg> AKL-PT2 silicone molds shipped
<azonenberg> components are en route as well, so by the time the PCBs get here i should have everything i need
juli966 has joined #scopehal
massi_ has quit [Remote host closed the connection]
<codysseus> Not feeling it for GPL?
<azonenberg> codysseus: i'm trying to keep at least the libscopehal core permissively licensed in order to allow commercial tools to integrate easily
<codysseus> That makes sense.
<marshallh> bvernoux: nanovna came :)
<bvernoux> ha great
<bvernoux> marshallh, do you have done some tests ?
<marshallh> yes i have 2.4ghz bandpass test filter
<bvernoux> You shall see immediatly the difference with the other NanoVNA
<bvernoux> especially for 2.4GHz
<bvernoux> where the standard NanoVNA is limited to 3GHz and with lot of noise after 2GHz
<bvernoux> yes 2450 is not perfect
<bvernoux> you see the best is before
<bvernoux> like 2400
<bvernoux> but 101 pts is very limited
<bvernoux> it is better to use 1601pts
<bvernoux> with PC tools
<marshallh> 2.45 is design ccenter, with smith chart closest to 50ohm
<marshallh> hm
<marshallh> after SOLT calibration at 2.45ghz i still get a ring
<bvernoux> on picture you provide it clearly requires tuning
<bvernoux> as the center is not tuned correctly
<marshallh> on S11
<marshallh> yeah i tried
<bvernoux> also 34Ohms instead of 50Ohms
<bvernoux> so you can improve the antenna
<bvernoux> changing the capacitor
<marshallh> well this was a 2.4ghz bandpass microstrip filter on rogers
<bvernoux> S11 shall be under -10dB to have something good
<bvernoux> in center 2.45GHz
<bvernoux> ha yes so the best performance is at 2.4GHz
<bvernoux> that explain all
<marshallh> after calubration with SOLT and both leads attached to thru connector
<marshallh> thru
<marshallh> not sure if good or not
<bvernoux> you shall check open & close
<bvernoux> with 50Ohm
<bvernoux> -with+and
<bvernoux> 500MHz SPAN is too much if you want to tune accurately from 2350 to 2500MHz
<bvernoux> especially with only 101pts
<marshallh> with only 50ohm load on S11 looks very good with just 1 pixel at center
<marshallh> but when connecting S21
<bvernoux> just connect a -3dB (or even 0dB) attenuator
<bvernoux> to see
<bvernoux> S11 shall be <-20dB
<bvernoux> in best case
<bvernoux> and S21 shall be very flat
<bvernoux> the best is to use minicircuits attenuator
<bvernoux> as you have the expected s2p provided
<bvernoux> as reference
<marshallh> hm yes S11 is -18.9dB S22 0.01dB
<marshallh> S21*
<bvernoux> so it seems good
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal