azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | | Logs:
balrog has quit [Quit: Bye]
<_whitenotifier-1> [scopehal-apps] umarcor opened pull request #355: Use make install on Windows (MSYS2) -
balrog has joined #scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
Tost has joined #scopehal
bvernoux has joined #scopehal
<_whitenotifier-1> [scopehal-apps] bvernoux commented on pull request #355: Use make install on Windows (MSYS2) -
<_whitenotifier-1> [scopehal-apps] bvernoux edited a comment on pull request #355: Use make install on Windows (MSYS2) -
<_whitenotifier-1> [scopehal] bvernoux edited pull request #481: Add support of PicoScope3000 MSO (16chan option) -
<azonenberg> bvernoux: why SERIES_UNKNOWN? add a new enum for 3000 series
<bvernoux> because in fact it is not used for PICO3000
<bvernoux> it is for FlexRes stuff
<azonenberg> It's used for other stuff too
<bvernoux> and such feature does not exist on any Pico3000
<bvernoux> ha ok
<azonenberg> We still want to know what the model is
<bvernoux> so Yes I will add SERIES_PICO3000 to be checked
<azonenberg> also we will have to do things like gating channel enabling by sample rates
<azonenberg> if 3000 is anything like 6000, at max sample rate you can't use all analog and digital channels at once
<azonenberg> you run out of ram bandwidth
<bvernoux> yes the SERIES_XXXX shall have a definition to understand how it is used
<azonenberg> so it has to know the available BW to determine whether a channel can be turned on
<azonenberg> in CanEnableChannel()
<bvernoux> IIRC Pico3000 is not affected by that
<bvernoux> but anyway it will be required to manage the BW
<bvernoux> so far there is no hurry to merge my PR anyway
<bvernoux> I will try to create some SERIES_XXXX for different cases of PICO3000 options ...
<bvernoux> I'm also afraid PicoOscilloscope.cpp/.h will requires major refactoring
<bvernoux> as it will be harder and harder to maintain it if we add the different Picoscope ...
<azonenberg> Why do you think it will need major refactoring?
<noopwafel> in the worst case: there are not that many picoscopes :D
<bvernoux> there is tons of Picoscope ;)
<bvernoux> in fact the most refactor will probably appears in pico-bridge
<noopwafel> I got suckered into producing results for One Last Paper this week hence me kind of vanishing again :p
<noopwafel> but I will after that bother people into lending me some other picos and see what it looks like with those, I think honestly it will end up pretty clean to support
<bvernoux> the challenge is to have guys with different Pico to test ;)
<bvernoux> as it is typical code which cannot be tested with Unit Test ;)
<azonenberg> Yeah there's not THAT many different families
<bvernoux> the good point is Pico5000 and Pico3000 are very similar the only diff is FlexRes for Pico5000
<azonenberg> Pico has already offered to send a 2000 series to anybody who wants to test them
<azonenberg> i dont think anyone is working on 4000 yet but i'm sure we'll get to it soon
<bvernoux> I doubt Pico2000 is interesting anyway IIRC they are USB2.0 so they will be slow to refresh ...
<bvernoux> I doubt someone is interested to use an oscilloscope with something like 2WFM/s ...
<bvernoux> except to say look it works ;)
<noopwafel> you just reduce the buffer size
<azonenberg> Still, a cheap scope is nice for some purposes
<noopwafel> the super-cheap picos have tiiny buffers anyway
<noopwafel> 8kS :(
<bvernoux> noopwafel, yes on Pico it could be a good point if it is not like Rigol or other scope which are in all case not >2WFM/s ...
<azonenberg> It'll still be faster than a rigol with the same memory depth lol
<bvernoux> yes clearly
<noopwafel> there are basically two models of pico2k
<bvernoux> anyway basic support shall be quite fast to add I think if the API is not too different from Pico3000
<bvernoux> Especially when Pico3000 will be well supported with MSO...
<bvernoux> I doubt Pico2000 have MSO in fact
<noopwafel> the low-end one with the tiny buffers which cap out at 1MS/s anyway, and the higher-end one with large buffers and which can come closer to saturating usb2, 30MS/s or so
<bvernoux> ha yes they have MSO option ;)
<noopwafel> so I know quite a few people who have them just so they always have a scope with them on the go
<bvernoux> Pico2000 USB streaming is 1MS/s max or for the big version 9.6MS/s ;)
<noopwafel> the hw can do faster
<noopwafel> (the specs are for the gui)
<noopwafel> oh the sdk specs are there too
<noopwafel> search for 'sdk / api'
<bvernoux> it is limited by USB I think
<bvernoux> it is spec about the USB streaming
<noopwafel> so if you can make it fast enough, then 8kS buffers is not a disaster as long as you can trigger well outside that
<noopwafel> but I suspect you can't,
<bvernoux> it can reach 31.25 MS/s in fact with some version
<noopwafel> the ps3k API lets you pick pre/post samples but you can't get further away than $buffer_size from the trigger pt
<noopwafel> oh right there's just set trigger delay
<noopwafel> duh I am so slow sometimes
<noopwafel> ok, so you can build a perfectly fine debug view out of this I guess, just you don't get the analysis
<noopwafel> just adjust the trigger delay if you want to zoom into an area which doesn't include the trigger
<noopwafel> something like this would be useful for any scope with slow transfer speeds I guess?
<noopwafel> but I should go back to what I was doing because trying to split my attention apparently doesn't work :D
<_whitenotifier-1> [scopehal-apps] umarcor commented on pull request #355: Use make install on Windows (MSYS2) -
<_whitenotifier-1> [scopehal-apps] azonenberg commented on pull request #355: Use make install on Windows (MSYS2) -
<_whitenotifier-1> [scopehal-apps] umarcor commented on pull request #355: Use make install on Windows (MSYS2) -
<_whitenotifier-1> [scopehal-apps] umarcor commented on pull request #355: Use make install on Windows (MSYS2) -
<_whitenotifier-1> [scopehal-apps] azonenberg commented on pull request #355: Use make install on Windows (MSYS2) -
<GyrosGeier> azonenberg, -- that is the current state
<GyrosGeier> ffts is uploaded already, the glscopeclient packages still need some work
<GyrosGeier> at least lintian is unhappy with them still
<GyrosGeier> W: glscopeclient: binary-without-manpage usr/bin/glscopeclient
<GyrosGeier> W: glscopeclient: desktop-entry-lacks-main-category usr/share/applications/glscopeclient.desktop
<GyrosGeier> these are upstream issues
<GyrosGeier> the rest is packaging stuff
<GyrosGeier> also:
<GyrosGeier> dpkg-shlibdeps: warning: symbol dlopen used by debian/glscopeclient/usr/lib/x86_64-linux-gnu/ found in none of the libraries
<GyrosGeier> dpkg-shlibdeps: warning: symbol dlsym used by debian/glscopeclient/usr/lib/x86_64-linux-gnu/ found in none of the libraries
<GyrosGeier> so it seems a dependency on libdl is missing
<GyrosGeier> which isn't a big problem because gtk pulls it in anyway
<azonenberg> Lack of a man page is definitely a problem, someone has to write one
<azonenberg> I have no idea how to do that but let me file a ticket and mark it as a release blocker
<_whitenotifier-1> [scopehal-docs] azonenberg opened issue #29: Write a man page -
<GyrosGeier> binaries are untested as of yet
<_whitenotifier-1> [scopehal-apps] azonenberg opened issue #356: Desktop file lacks a main category -
<_whitenotifier-1> [scopehal-apps] azonenberg labeled issue #356: Desktop file lacks a main category -
<_whitenotifier-1> [scopehal] azonenberg opened issue #482: Linux builds should link against libdl for dlopen/dlsym -
<_whitenotifier-1> [scopehal] azonenberg labeled issue #482: Linux builds should link against libdl for dlopen/dlsym -
<azonenberg> Filed bugs for them, will work on them once I finish
<GyrosGeier> I also get a segfault
<GyrosGeier> let's see where
<GyrosGeier> #9 0x00007ffff7160e1d in ffts_execute_1d_real () from /lib/x86_64-linux-gnu/
<GyrosGeier> oof
<GyrosGeier> that will be interesting
<azonenberg> GyrosGeier: interesting indeed. Especially because ffts does JIT code generation
<GyrosGeier> part of the problem will be that ffts is linked into a shared library
<GyrosGeier> so it needs to be built with -fPIC itself
<azonenberg> And was it not?
<azonenberg> oh wait
<azonenberg> 0x00007ffff7160e1d in ffts_execute_1d_real () from /lib/x86_64-linux-gnu/
<azonenberg> not
<azonenberg> that seems to imply it was linking to static ffts
<GyrosGeier> yes
<GyrosGeier> there is no shared libffts
<GyrosGeier> but that shouldn't be the entire story
<GyrosGeier> amd64 usually works around non-PIC code in shared libraries
<azonenberg> well if we're packaging libffts separately it should be distributed as shared
<GyrosGeier> yes
<azonenberg> So fix that and if it still crashes investigate then?
<GyrosGeier> but it has no stable ABI
<azonenberg> It also hasn't been updated since like 2017
<azonenberg> it's stable by virtue of being stagnant :D
<GyrosGeier> true
<GyrosGeier> I've filed a bug "please declare the ABI stable"
<azonenberg> I think it's abandoned, the developer hasnt been on github in years and his website is a parking domain
<azonenberg> Not even sure if he's still alive
<azonenberg> but it works and, well, it's a math library, not like math changes
<GyrosGeier> to trigger this, I just started, and set up a "demo" device with "null" transport named "scope" and address "asdf"
<azonenberg> At some point i plan to fork it and add AVX/AVX512 code generation and we could declare that a new major version that's not ABI compatible
<azonenberg> But for the near term and the v0.1 release, the current version on github is the way to go
<azonenberg> you can pick that commit hash explicitly if you want
<GyrosGeier> there is an explicit [disable-shared] in :P
<GyrosGeier> well, I can just override that with --enable-shared
<azonenberg> Yeah that's what our build instructions in the docs do
<GyrosGeier> mh
<GyrosGeier> can you reproduce the crash with the "demo" driver?
<GyrosGeier> #9 0x00007ffff7160e1d in ffts_execute_1d_real () from /lib/x86_64-linux-gnu/
<GyrosGeier> #10 0x00007ffff715907c in TestWaveformSource::DegradeSerialData (this=0x5555569199d0, cap=0x7fffd0000e00, sampleperiod=20000, depth=100000, lpf=true, noise_amplitude=0.00999999978) at /build/glscopeclient-0.0.20210518+git6b1e125/lib/scopehal/TestWaveformSource.cpp:347
<azonenberg> No. I'm using dynamic ffts and everything works fine
<GyrosGeier> #11 0x00007ffff7158aa1 in TestWaveformSource::GeneratePRBS31 (this=0x5555569199d0, amplitude=0.899999976, period=96969.6016, sampleperiod=20000, depth=100000, lpf=true, noise_amplitude=0.00999999978) at /build/glscopeclient-0.0.20210518+git6b1e125/lib/scopehal/TestWaveformSource.cpp:233
<GyrosGeier> #12 0x00007ffff70cbbb3 in DemoOscilloscope::AcquireData (this=0x555556917000) at /build/glscopeclient-0.0.20210518+git6b1e125/lib/scopehal/DemoOscilloscope.cpp:473
<azonenberg> I suspect it has to do with the static ffts
<GyrosGeier> I was just thinking maybe nobody really uses the demo driver because everyone who uses the program now has a scope :P
<azonenberg> No the demo driver works fine
<GyrosGeier> okay
<azonenberg> i actually use it all the time along with the channel emulation filter
<azonenberg> the "unit step" output combined with channel emulation lets you view step response of arbitrary S-parameters
<_whitenotifier-1> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±3]
<_whitenotifier-1> [scopehal] azonenberg cf69d7e - Fixed various invalid YAML formatting in serialization
<_whitenotifier-1> [scopehal] azonenberg 524f9ec - Added libdl reference to libscopehal on POSIX. Fixes #482.
<_whitenotifier-1> [scopehal] azonenberg closed issue #482: Linux builds should link against libdl for dlopen/dlsym -
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4]
<_whitenotifier-1> [scopehal-apps] azonenberg 63162d9 - Added missing keys to waveform metadata files so they're valid YAML. See #156.
<_whitenotifier-1> [scopehal-apps] azonenberg 3e9523c - Fixed various YAML elements in scopesession files with missing keys. Fixes #156.
<_whitenotifier-1> [scopehal-apps] azonenberg closed issue #156: scopesession files contain invalid yaml -
yourfate has quit [Quit: Sayōnara, ihr Trottel.]
maartenBE has quit [Ping timeout: 265 seconds]
yourfate has joined #scopehal
maartenBE has joined #scopehal
<GyrosGeier> float *const FFTS_RESTRICT buf = (float *const FFTS_RESTRICT) FFTS_ASSUME_ALIGNED_32(p->buf);
<GyrosGeier> (gdb) p/x buf
<GyrosGeier> $1 = 0x7fffd040aed0
<GyrosGeier> hmmmmm
<GyrosGeier> okay
<GyrosGeier> it falls over in
<GyrosGeier> => 0x7fffe47d52b7: movaps 0x20(%r9),%xmm0
<GyrosGeier> %r9 is NULL
<GyrosGeier> => 0x7fffe47d52a8: mov 0xd8(%rdi),%r9
<GyrosGeier> that is the "constants" field of struct _ffts_plan_t
<GyrosGeier> aha
<GyrosGeier> that is only initialized if HAVE_SSE is set
<GyrosGeier> but that should be set
<azonenberg> you're doing movaps
<azonenberg> which is a sse instruction
<azonenberg> so presumably HAVE_SSE is set
<azonenberg> Just confirmed it's working fine on my install
<GyrosGeier> mh
<GyrosGeier> --enable-sse is missing on the configure call
<GyrosGeier> but it's still using SSE
<GyrosGeier> that may be the problem
<GyrosGeier> okay, that will need additional work for different architectures
<GyrosGeier> it will probably fall over on arm64 now\
<azonenberg> yeah that could be it
<azonenberg> if --enable-sse missing doesnt turn off all sse
<azonenberg> On amd64 i wouldnt even worry about checking for SSE support
<azonenberg> that's pretty much assumed on any amd64 platform AFAIK
<azonenberg> i think the ISA requires it
<azonenberg> since they removed the old x87 fpu stack
<GyrosGeier> yes
<GyrosGeier> that seems to have been the problem
<GyrosGeier> new packages at
<GyrosGeier> (https is available too)
<ericonr> anuejn: iirc amd64 is sse2 unless it's some really oddball components
<ericonr> oops, azonenberg
<GyrosGeier> mh
<GyrosGeier> it's annoying that it generates SSE code in non-SSE mode
<azonenberg> Yeah but i think enabling sse in the amd64 build unconditionally is fine. like i said sse2 is always present in amd64
<GyrosGeier> yes
<GyrosGeier> I will have to add a bit of logic for the other architectures though
<GyrosGeier> and/or runtime switching
<GyrosGeier> at least libdl pulls stuff from subdirectories according to feature flags first, so I can have /usr/lib/i686-linux-gnu/sse2/ or something such
<GyrosGeier> it's annoying because it's work
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal] azonenberg a62b0be - WAV files, and CSV without a time header, now use file mod time as the waveform timestamp in history. Fixes #426.
<_whitenotifier-1> [scopehal] azonenberg closed issue #426: CSV import: if no header with timestamp, use file modification time as timestamp for history view -
ericonr has quit [Ping timeout: 240 seconds]
<bvernoux> I'm trying to rebuild latest code from scopehal-pico-bridge\src\ps6000d\ScpiServerThread.cpp
<bvernoux> but I have some error related to min()/max()
<bvernoux> like
<bvernoux> ScpiServerThread.cpp:1069:54: error: no matching function for call to 'max(int64_t&, long int)'
<bvernoux> with
<bvernoux> In file included from C:/msys64/mingw64/include/c++/10.3.0/memory:63,
<bvernoux> from C:/msys64/home/Ben/scopehal-pico-bridge/lib/log/log.h:29,
<bvernoux> from C:\msys64\home\Ben\scopehal-pico-bridge\src\ps6000d\ps6000d.h:33,
<bvernoux> from C:\msys64\home\Ben\scopehal-pico-bridge\src\ps6000d\ScpiServerThread.cpp:110:
<bvernoux> C:/msys64/mingw64/include/c++/10.3.0/bits/stl_algobase.h:254:5: note: candidate: 'template<class _Tp> const _Tp& std::max(const _Tp&, const _Tp&)'
<bvernoux> 254 | max(const _Tp& __a, const _Tp& __b)
<bvernoux> | ^~~
<bvernoux> C:/msys64/mingw64/include/c++/10.3.0/bits/stl_algobase.h:254:5: note: template argument deduction/substitution failed:
<xzcvczx> #include <algorithm>
<xzcvczx> ?
<azonenberg> There is no line 1069 in SCPIServerThread.cpp
<azonenberg> It's only 1036 lines
<bvernoux> yes because I have done modifications too ;)
<bvernoux> I'm implementing things for Pico3000A
<azonenberg> What's the offending line then?
<bvernoux> so the lines are different
<bvernoux> size_t nPreTrigger = min(max(triggerDelaySamples, 0L), (int64_t)g_memDepth);
<azonenberg> Replace 0L with (int64_t)0
<bvernoux> yes success
<bvernoux> strange that you do not have thigs error with GCC
<bvernoux> this
<azonenberg> It's not gcc
<bvernoux> so in theory I have implemented Pico3000A MSO stuff ;)
<azonenberg> it's windows vs linux
<azonenberg> in particular on windows long is 32 bits and long long is 64
<azonenberg> on posix, long is 64
<azonenberg> So 0L is 32 bits on windows and 64 on posix
<bvernoux> ha yes because mingw64 use some windows cheat ...
<azonenberg> and std::max is a templated function that due to annoying quirks of C++ doesn't promote
<azonenberg> so if it sees max(int64, int) it won't promote the int to int64
<azonenberg> it just fails to compile
<azonenberg> This has bit me before and i thought i fixed all of the cases of it
<azonenberg> clearly missed one
<azonenberg> This is why I try to avoid using "int" and "long" as much as possible and prefer stdint types
<bvernoux> yes good explanation I was not aware of that
<azonenberg> note that the common C min/max using macros is unaffected by this
<azonenberg> only the templated C++ STL implementation
<bvernoux> ha ok I see ...
<bvernoux> the most annoying so far is the support of %zu it is really bloated with tons of warnings with mingw64 ...
<bvernoux> even if that work fine in fact ;)
<bvernoux> and also the mess with gtkmm redefinition ...
<bvernoux> which seems very specific to mingw64 too
<bvernoux> I'm implementing SERIES_3XXXX right now
<bvernoux> in PicoOscilloscope.cpp/.h
<bvernoux> I'm also checking how to improve those settings
<bvernoux> SetSampleRate(625000000L);
<bvernoux> SetSampleDepth(1000000);
<azonenberg> Yeah those are defaults for 6000E series
<bvernoux> they are coded and does not work fine for Pico3000
<azonenberg> So just have a switch on the series and pick the max rate that works for all channels to start
<bvernoux> I think those will be better with a dedicated ScpiServerThread.cpp command
<bvernoux> as I do not really like to check that in PiscoOscilloscope.cpp which is like an abstraction
<bvernoux> what do you think to add a default command in the bridge ?
<bvernoux> which could be called in PicoOscilloscope::IdentifyHardware()
<bvernoux> that will move lot of specific stuff to bridge
<bvernoux> and it will return m_series
<bvernoux> as there is clearly redundant stuff between bridge & PicoOscilloscope.cpp today
<azonenberg> PicoOscilloscope has to have default stuff
<azonenberg> because state is clientside
<azonenberg> it's not a cache, the server has no read functions
<azonenberg> you need to set every configurable attribute in the constructor so the client knows what the state is, and to flush any old state from the last connection out
<azonenberg> The bridge is intended to be a very thin wrapper around the API that has as little intelligence as possible
<azonenberg> And there is not much redundancy because most of the validation of legal channel configs etc is all clientside
<azonenberg> The server just calls the pico api and if you give it bad input, it will error out
<bvernoux> i was seeing the client side more like a high level pico in fact
<bvernoux> to avoid checking anything too specific
<bvernoux> and so using server command ...
<bvernoux> especially to manage correctly the setting for
<bvernoux> SetSampleRate(625000000L);
<bvernoux> SetSampleDepth(1000000);
<azonenberg> From my perspective the bridge does two things
<bvernoux> which are clearly specific to each Pico
<azonenberg> it converts from the pico APIs for different models to a single common interface
<azonenberg> and it bridges that interface out to scpi commands
<azonenberg> but it's still pretty much a 1:1 mapping
<azonenberg> it's intended to be as thin as possible
<bvernoux> yes
<azonenberg> All intelligence is in the PicoOscilloscope class
<azonenberg> There has to be logic in there already to know what combinations of sample rates, memory depths, enabled channels, FlexRes modes, etc are legal
<azonenberg> It's the proper place for it
<bvernoux> ok
juli9611 has joined #scopehal
<bvernoux> so the hard coded values
<bvernoux> SetSampleRate(625000000L);
<bvernoux> SetSampleDepth(1000000);
<bvernoux> shall be computed in PicoOscilloscope
<bvernoux> depending on hardware
<bvernoux> those parameter shall come from GUI in fact
<bvernoux> as it shall be configured by user
<bvernoux> but as those GUI stuff are not implemented today we shall just find good default value with a simple algorithm
<azonenberg> No, those are not coming from the gui
<bvernoux> ha ?
<azonenberg> This is default values set *when you first connect to the scope*
<bvernoux> yes
<azonenberg> it has to have *some* sample rate before you change anything
<bvernoux> but after it shall be configured by users
<azonenberg> Yes, if you double click on the timeline you get presented with the list of sample rates and memory depths
<azonenberg> Those are pulled from the bridge via RATES? and DEPTHS?
<bvernoux> ha ok
<bvernoux> I will test that
<azonenberg> But before you do that the first time
<azonenberg> it has to have some settings
<azonenberg> Which is what that default is for
<azonenberg> Doesnt matter what it is, as long as it's legal for the current instrument
<bvernoux> so I will just implement GetDefaultSampleRate() & GetDefaultSampleDepth()
<azonenberg> You could make a function out of it but it seems a bit pointless as it's only ever used in the constructor once
<bvernoux> yes maybe just keep it simple with a good default value for any Pico3000
<azonenberg> May not be possible because the available rates are different for each series. And for a 6000 series it makes sense to have the default be fast-ish
<azonenberg> Just have a switch statement, what's the problem?
<azonenberg> if you think this is bad you haven't seen the lecroy driver :p
<GyrosGeier> hmmmk
<GyrosGeier> eye pattern decoder crashes as well
<GyrosGeier> this will take a while to get stable
<azonenberg> Very interesting how you're hitting so many problems
<azonenberg> in things that have been very stable for everyone else
<azonenberg> what's the crash location etc?
<azonenberg> and is it an immediate crash or after some time?
<GyrosGeier> immediate, when I forget to set up the clock source
<GyrosGeier> works fine otherwise, it seems
<GyrosGeier> hitting problems is kind of what I do normally :P
<azonenberg> Lol. File a bug against scopehal and the v0.1 milestone, i'll look at it
<azonenberg> All of the filters *should* gracefully degrade if inputs aren't configured
<azonenberg> if the eye crashes when not given a clock that's a problem
<GyrosGeier> also, I tried to see if I could recover a clock from the PRBS
<GyrosGeier> apparently, no
<azonenberg> You should be able to
<azonenberg> It's 10.3125 Gbps
<GyrosGeier> ah
<azonenberg> the 8b10b is 1.25
<GyrosGeier> ah yes
<GyrosGeier> now that works
<GyrosGeier> hmm
<GyrosGeier> is there anything special I need to do to use the 8b10b decoder?
<GyrosGeier> I mean, I can apply it to the recovered clock, which is a bit silly
<GyrosGeier> but for the actual waveform it's greyed out
<azonenberg> 8b10b is a digital protocol. You have to apply it to a digital signal, not an analog one
<azonenberg> Which typically means applying a threshold filter
<azonenberg> Longer term we plan to add some glue that will automatically infer a threshold filter when you try to perform a decode that wants a digital input and give it an analog signal
<azonenberg> and pick 50% or some other reasonable level
<azonenberg> But right now it has to be created by hand
<GyrosGeier> ah
<azonenberg> That's i think on the v0.2 feature list
<azonenberg> and is one of the hundreds of things i want to improve on the UX side that i can't because there's one of me and hundreds of tickets to work on :p
<GyrosGeier> oof
<GyrosGeier> right click on the threshold output gave segfault
* GyrosGeier retries
<azonenberg> attention channel, GyrosGeier is officially our senior test engineer :p
<GyrosGeier> lol
<bvernoux> yes
<bvernoux> Pico3000 MSO works ;)
<azonenberg> bvernoux: you got the digital channels up? great
<azonenberg> I'm still working on adding trigger-on-mso-channel support
<azonenberg> That will hopefully be in some time tonight or tomorrow
<azonenberg> right now if you try to pick a pico mso channel as a trigger source it will probably just crash, or maybe it just won't show up as a valid input
<bvernoux> yes I have digital channels
<bvernoux> and nothing crash ;)
<bvernoux> let's put something on digital channels to be sure the state are good ;)
<bvernoux> also I have changed default sampling rate to 125MSPS for Pico3000
<bvernoux> as it is the good value when all is enabled
<bvernoux> strange things why I have 2WFM/s ;)
<bvernoux> also the freq is wrong
<bvernoux> on analog chan
<bvernoux> X
<azonenberg> It's almost certainly related to timebase stuff
<azonenberg> the set-timebase function might use a different base frequency in 3000 than 6000
ericonr has joined #scopehal
ericonr has quit [Ping timeout: 240 seconds]
<bvernoux> yes
<bvernoux> ON and OFF seems to work anyway on digital chan
<bvernoux> Pause/Start does not work also on Pico3000
<bvernoux> need to change the trigger
<bvernoux> I do not remember is that was working before ;)à
<bvernoux> azonenberg, that does not explain why now I have only 2WFM/s ;)
<bvernoux> something is broken
<azonenberg> bvernoux: Unplug and replug it
<azonenberg> seriously, something gets stuck in the usb stack on 6000 series sometimes and it seems to fall back to usb2 speeds
<bvernoux> ha ok maybe ;)
<bvernoux> no
<bvernoux> something is broken ;)
<bvernoux> speed is slow
<bvernoux> If i just revert my small modifications in PicoOscilloscope.cpp
<bvernoux> I have 11WFM/s now on 4 Chan
<bvernoux> hmm just doing a moving avg on 1000pts slow down from 14WFM/s to 2WFM/s
<bvernoux> a moving avg on 4x1Mpt shall not be so slow
<bvernoux> in fact it is only on 1 chan so on 1Mpts
<azonenberg> a 1000 point average window is a lot of math
<azonenberg> that's processing 4GB of sample data per waveform
<azonenberg> And i don't think the moving average filter is vectorized either... the FIR is
<bvernoux> what do you do in your moing average ?
<bvernoux> moving
<bvernoux> as a basic moving avg is just doing sum of n points then divide by n point
<bvernoux> ok yes I have missed the window ;)
<azonenberg> A 1K sample moving average means each output sample is the average of 500 samples left and 500 right
<azonenberg> so that's 1K multiply-adds per point
<GyrosGeier> I need to continue the "use FPGAs for OpenCL" work I did for that startup once
<GyrosGeier> a CycloneIV GX with DMA access will likely be good at applying FIR filters
<azonenberg> Before we get too far into the OpenCL side of things i need to do major work on memory management
<azonenberg> in particular if you apply one OpenCL filter to the output of another
<bvernoux> ok I have found what does this 2WFM/s
<azonenberg> right now there's an unnecessary GPU -> CPU -> GPU copy
<bvernoux> it is the SetSampleRate(125000000L);
<azonenberg> What's probably happening is that when you ask for a sample rate that's not valid, it picks something super slow
<azonenberg> or underflows or something
<azonenberg> What happens if you pick a reasonable sample rate, like 100 Msps or something? have you validated the actual timebase settings in the bridge against the pico API?
<azonenberg> like i said hours ago, fix that before wasting time looking for other problems
<azonenberg> Treat behavior with an invalid sample rate as undefined
<bvernoux> yes it shall be debugged deeply ;)
<bvernoux> I doubt the commands was working
<bvernoux> I will add explicit trace for each command with answers ...
<bvernoux> as the settings are definitively broken
<bvernoux> it was by luck that with 625MSPS it was like working fine ;)
<bvernoux> as anyway it cannot set such speed on Pico3000 with 4chan which is limited to 125MSPS
<bvernoux> it seems to corresponds as I see a x5 factor in fact for the 1Khz I see 5KHz
<azonenberg> Like i said, look at the API and see what the timebase values are
<bvernoux> hmm the command "RATES" is not called ...
<bvernoux> hmm and DEPTHS is buggy ;)
<azonenberg> It's only called when you open the timebase properties dialog
<azonenberg> And DEPTHS requires a sample rate to get the memory depth
<azonenberg> I hard coded 1.25 Gsps for 6000 series
<azonenberg> You need to use other values for other models
<azonenberg> If you actually read the comments in the bridge you'd see this :)
<bvernoux> yes I need to review everything in fact ;)
<bvernoux> those parts was already coded and are not working correctly
<azonenberg> might have been noopwafel then
<azonenberg> I didnt touch anything in 3000 series
<azonenberg> but i thought i clearly commented all of the spots that made assumptions about sample rates etc
<bvernoux> yes just need full check everywhere
bvernoux has quit [Quit: Leaving]
<Degi> I think it can be theoretically used to simulate PCBS
<Degi> (Even with nonlinearity)
juli9611 has quit [Quit: Nettalk6 -]
ericonr has joined #scopehal
<azonenberg> SMA test boards should ship friday ish
<GenTooMan> RF project?
<azonenberg> Testbed for about six different types of SMA with a combination of microstrip and coplanar waveguide launches
<azonenberg> note to self for when i get back: eSPI seems to have some bogus content in I/O reads, i need to look into that
Tost has quit [Quit: Nettalk6 -]
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-1> [scopehal] azonenberg 07f92da - eSPI: fixed bug causing extra data to be appended to a split transaction in the protocol analyzer view
<_whitenotifier-1> [scopehal] azonenberg synchronize pull request #481: Add support of PicoScope3000 MSO (16chan option) -