<_whitenotifier-1>
[scopehal-apps] umarcor opened pull request #355: Use make install on Windows (MSYS2) - https://git.io/JsEdb
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) - https://git.io/Jszrr
<_whitenotifier-1>
[scopehal-apps] bvernoux edited a comment on pull request #355: Use make install on Windows (MSYS2) - https://git.io/Jszrr
<_whitenotifier-1>
[scopehal] bvernoux edited pull request #481: Add support of PicoScope3000 MSO (16chan option) - https://git.io/Js0o0
<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
<GyrosGeier>
dpkg-shlibdeps: warning: symbol dlopen used by debian/glscopeclient/usr/lib/x86_64-linux-gnu/libscopehal.so found in none of the libraries
<GyrosGeier>
dpkg-shlibdeps: warning: symbol dlsym used by debian/glscopeclient/usr/lib/x86_64-linux-gnu/libscopehal.so 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 - https://git.io/JsgIz
<GyrosGeier>
binaries are untested as of yet
<_whitenotifier-1>
[scopehal-apps] azonenberg opened issue #356: Desktop file lacks a main category - https://git.io/JsgIP
<_whitenotifier-1>
[scopehal-apps] azonenberg labeled issue #356: Desktop file lacks a main category - https://git.io/JsgIP
<_whitenotifier-1>
[scopehal] azonenberg opened issue #482: Linux builds should link against libdl for dlopen/dlsym - https://git.io/JsgIh
<_whitenotifier-1>
[scopehal] azonenberg labeled issue #482: Linux builds should link against libdl for dlopen/dlsym - https://git.io/JsgIh
<GyrosGeier>
#9 0x00007ffff7160e1d in ffts_execute_1d_real () from /lib/x86_64-linux-gnu/libscopehal.so
<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/libscopehal.so
<azonenberg>
not libffts.so
<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 configure.ac :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/libscopehal.so
<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] https://git.io/Jsgs1
<_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 - https://git.io/JsgIh
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JsgsF
<_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.
<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/libffts.so or something such
<GyrosGeier>
it's annoying because it's work
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JsgdS
<_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 - https://git.io/JO9sr
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>
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
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jsaf7
<_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) - https://git.io/Js0o0