<_whitenotifier-1>
[scopehal] azonenberg closed issue #457: Pico: Support for digital channels - https://git.io/J3igF
juli9611 has joined #scopehal
<azonenberg>
So i can't quite decode 1000base-X with the pico LA
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JslWP
<_whitenotifier-1>
[scopehal] azonenberg 79f9cd4 - ClockRecoveryFilter: added support for doing CDR on digital input channels
<azonenberg>
Might be possible with some PLL adjustments
<azonenberg>
i suspect the current CDR is unable to track the high jitter from only oversampling the data 4x
<azonenberg>
noopwafel: anyway i pushed what i have now on the pico driver. it still seems a bit buggy but i havent found the root cause yet
<azonenberg>
i think i need to stress test it a bit more to figure out where it's going wrong
<azonenberg>
it intermittently seems to read garbage
<azonenberg>
then die with a std::bad_alloc from trying to create an rx buffer of an absurd size
<azonenberg>
But so far i havent found any obvious root cause
<azonenberg>
or way to reproduce it
<_whitenotifier-1>
[scopehal-apps] azonenberg labeled issue #350: Add "scopehal-server" utility for bridging an arbitrary Oscilloscope to a socket - https://git.io/Jsl0R
<_whitenotifier-1>
[scopehal-apps] azonenberg opened issue #350: Add "scopehal-server" utility for bridging an arbitrary Oscilloscope to a socket - https://git.io/Jsl0R
<noopwafel>
when calculating numchans, you check g_msoPodEnabled and not g_msoPodEnabledDuringArm
<noopwafel>
(I also see that my ps3000 code doesn't actually do 'numSamples = numSamples_int' after calling GetValues which is another bug in this code..)
<noopwafel>
It looks okay to me otherwise, but the enabled thing would cause a dsync.
<azonenberg>
Yeah ok that might be it
<_whitenotifier-1>
[scopehal-pico-bridge] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JslzD
<_whitenotifier-1>
[scopehal-pico-bridge] azonenberg 996a02b - Fixed using msoPodEnabled instead of msoPodEnableDuringArm
<azonenberg>
It's a bug so i'll fix it regardless, will need to hammer on it a bit more to be sure if this is the actual bug
<azonenberg>
Then i need to do a bit of cleanup and start figuring out how to do triggers on mso channels
<azonenberg>
Now i just need to find a nice test subject in my lab to demo the MSO on
<azonenberg>
all of my recent MSO stuff has been on client boards for work
<azonenberg>
so i gotta find something i can actually show
bvernoux has joined #scopehal
<bvernoux>
hello
<bvernoux>
I have just rebuilt latest glscopeclient and something amazing
<bvernoux>
the bug with 64b66b.scopesession has disappeared ...
<bvernoux>
very very strange ...
<bvernoux>
I can load it with success without any crash
<bvernoux>
It seems it is clearly a buffer overflow somewhere which is probably in an other area without direct/visible impact ...
<bvernoux>
buffer overflow of something corrupted in memory
<bvernoux>
or maybe it is fixed ...
<azonenberg>
bvernoux: try valgrind or asan and see if you can shed any light on it
<bvernoux>
they are not supported with windows :(
<azonenberg>
asan isn/t?
<bvernoux>
valgrind works only with Linux
<azonenberg>
isn't*
<bvernoux>
I shall check asan
<azonenberg>
i think we even have config in cmake for it
<azonenberg>
just add -DANALYZE=ON to the cmake command line iirc?
<bvernoux>
Asan is supported with MSVC ;)
<azonenberg>
if it is a race condition, small changes to how long some stuff takes to run might make or break it
<azonenberg>
bvernoux: also mso support for picoscope 6000e is now pushed. unsure how similar 3000 series MSO is
<azonenberg>
as of now you cannot trigger on the mso channels
<azonenberg>
attempts to do so are likely to end badly
<azonenberg>
but you can trigger off an analog channel and acquire waveforms
<azonenberg>
I'm still testing and debugging but it mostly seems to be working
<bvernoux>
yes I have not tried so far
<bvernoux>
I was just doing my standard test after build loading demo, and spi, 6466 ;)
<bvernoux>
even if it is limited test so far it showed lot of issue when there was ;)
<bvernoux>
it will be great to push a test with all decoders ;)
<bvernoux>
everything ;)
<bvernoux>
just for robustness and perf test
<bvernoux>
and why not non regression test if we have a way to compare what is displayed vs what is expected but it is not easy with GUI stuff ...
<azonenberg>
Yes, it's tricky on the GUI side, but the decodes are all just data structures in ram
<azonenberg>
there's absolutely nothing stopping us from making unit tests for decodes
<azonenberg>
in fact, we have one already. i think for the "frequency" measurement
<azonenberg>
it's just a matter of putting in the effort to thoroughly test *all* of the decodes, collecting corpuses of test data
<azonenberg>
preferably without excessive volumes of data or sample rate, because my current collection of test waveforms is something like a hundred GB
<azonenberg>
I can't put that on github and expect everyone to run tests against it
<bvernoux>
unfortunately asan seems not available for MSYS2 mingw64
<bvernoux>
I have an error to build with the option
<azonenberg>
And there's at least a few protocols where my only available waveform data at the moment is from work, and thus not shareable
<bvernoux>
ha yes not good
<bvernoux>
I think we just need small test with all type of data to display all type of decoders/features all at same time ;)
<azonenberg>
So yes, probably in the gear-up for v0.2 i want to put a lot more effort into creating open, small test datasets we can use
<azonenberg>
Not going to happen before 0.1
<bvernoux>
yes there is no hurry for v0.1 it is mainly for mid/long term
<azonenberg>
for 0.1 i'm focused on taking everything we have and finishing the rough edges, documenting things, fixing the file format, etc
<bvernoux>
yes such things shall not block v0.1 I'm 1000% agree
<bvernoux>
especially actual version is already very mature for a v0.1 even if you want to finish some cleanup ...
<bvernoux>
lot of dataset could be converted from sigrok data maybe too
<bvernoux>
for protocols
<bvernoux>
when I have MSO working with my Pico3000 I could push some "open" capture for different protocols like I2C, SPI, UART ...
<bvernoux>
I'm not those are the most interesting but it is always good to have more and more dataset for test ...
<azonenberg>
Yeah the challenge will be in minimizing the data
<azonenberg>
I might try to create some tools for that
<azonenberg>
deleting unnecessary waveforms from history
<azonenberg>
downsampling waveforms
<azonenberg>
deleting channels not in use
<bvernoux>
yes it will be great on future version to have a "selector" to remove data before / after
<azonenberg>
So we can create a file with specific data that's not bloated more than it needs to be
<bvernoux>
such feature is not available on any PC scope tool like pulseview, DSView ...
<bvernoux>
sigrok can do it with cli version IIRC
<bvernoux>
what I hate in sigrok is the dependency on Python 3.x path
<bvernoux>
it is bloated ;)
<bvernoux>
I must rename my Python 3.8 dir as it is in path and PulseView does not start ;)
<bvernoux>
even if PulseView have python34.dll in same dir as the exe it seems it try to use the one from path before ...
<bvernoux>
anyway it is not related to glscopeclient but it is annoying I really start to hate all those python bloated stuff which are uncompatible between version ...
<bvernoux>
in Python 3.9 they have also broken support to Win7 ...
<bvernoux>
and so they force people to move to Win10 it is a "dictature"
<bvernoux>
they have broken the installer in fact with intentionally remove support for Win7 ...
<bvernoux>
Just for info my WIndows 7 Entreprise N receive updates
<bvernoux>
as there is extension for that special version so it is dead ;)
<bvernoux>
+not ;)
Stephie has quit [Quit: Fuck this shit, I'm out!]
Stephanie has joined #scopehal
Tost has joined #scopehal
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Js88X
<GenTooMan>
I wonder if Mycenaean symbols work with GTK
<azonenberg>
GenTooMan: if your font has it, anything in unicode should work
<azonenberg>
all text rendering is done via Cairo
<azonenberg>
mubes: anyway, ultimately it comes down to what std::to_string() or snprintf() does, depending on the part of the code in question
<azonenberg>
we could string replace inf with the infinity sign in post if you want
<bvernoux>
haha fun Emoji in chan name ;)
<d1b2>
<mubes> I noticed it on the vertical cursors when you don't set a second one, so the delta is inf GHz. I'll have a grep through the code at some point.
<azonenberg>
mubes: it's going to mostly be in the Unit class
<azonenberg>
For v0.2 and later i have a bunch of improvements planned for it
<azonenberg>
Among other things, I want to add support for units created via arbitrary linear combinations of units
<azonenberg>
Like V/s for the output of a differentiation filter
<d1b2>
<mubes> I dread to think what effect an Emoji channel name will have when sent to the scope, but I feel an unnatural desire to find out
<azonenberg>
Lol
<azonenberg>
I have yet to try that lol
<azonenberg>
My guess is the utf8 sequence will be rendered as separate ascii bytes
<d1b2>
<mubes> Should happen automatically on Siglent. Ill try it later
<azonenberg>
or the command will fail to parse
<azonenberg>
I should try on a lecroy too and see
<azonenberg>
this demo i did offline so it didnt send a command to the scope
<bvernoux>
on Pico3000 also the frequency is wrong
<bvernoux>
5x too big
<bvernoux>
I think it is clearly related to SMPS which is wrong like explained before
<bvernoux>
with 4 Chan it is 250MSPS instead of 625MSPS in actual code where it is hard coded
<azonenberg>
No
<azonenberg>
I think what's happening is that when i try to set the sample rate too high in the constructor
<azonenberg>
the bridge code just clamps to whatever it wants
<bvernoux>
anyway such things will be to be checked when we could configure sample rate and nb samples
<azonenberg>
but the bridge is generally write only
<azonenberg>
So any validation of parameters has to happen clientside because if you give it invalid config the bridge won't say anything
<bvernoux>
yes
<bvernoux>
I need to check if Pico3000 have those DigitalPods too
<bvernoux>
probably yes in that case it will have 2 DigitalPods for 16IO
<bvernoux>
yes I confirm that in the API
<bvernoux>
up to 4 DIGITAL_PORT each is 8bits
<azonenberg>
great, so the 6000 series driver should be easy to adapt
<bvernoux>
so let's hack the code to support MSO on Pico3000 ;)
<bvernoux>
good news to detect MSO it is exactly like for Pico6000
<bvernoux>
Variant info: 3406DMSO
<bvernoux>
I imagine you have 6xxxxMSO or something similar
<azonenberg>
Mine is just 6824E
<azonenberg>
I don't think there's any 6000 series without MSO
<bvernoux>
ha yes
<d1b2>
<mubes> Pleased to report Siglent just ignores unicode....or more specifically, doesn't render it, which might not be the same thing from the perspective of overflows etc.
<bvernoux>
so we have the same logic to detect the bandwidth and number of chan
<bvernoux>
so far the BW is not used but it could be to provide a list of sample rates supported
<bvernoux>
even if it seems there is an API for that
<GenTooMan>
I believe the 6000 series Siglent is still china exclusive no?
<d1b2>
<mubes> Yes. Not tales about in the west, but the software between the 2000X+, 5000 and 6000 is understood to be largely common.
<d1b2>
<mubes> 6000 has deep sample memory and high resolution sampling, as well as extended bandwidth.
<_whitenotifier-1>
[scopehal-apps] azonenberg opened issue #351: Saving a session while cionnected to a PicoScope 6000 series scope, and trigger in run state, crashes - https://git.io/Js81e
<_whitenotifier-1>
[scopehal-apps] azonenberg labeled issue #351: Saving a session while cionnected to a PicoScope 6000 series scope, and trigger in run state, crashes - https://git.io/Js81e
<_whitenotifier-1>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Js8SW
<_whitenotifier-1>
[scopehal] azonenberg 6ec2673 - Added MSO channel threshold and hysteresis settings to scopesession file format. Fixes #480.
<bvernoux>
I have a remark about => void PicoOscilloscope::IdentifyHardware()
<bvernoux>
the code inside will be better to be moved in pico-bridge
<bvernoux>
to have all things specifics to PicoXXXX in pico-bridge when possible to avoid modifying 2 parts of code
<azonenberg>
The thing is, some stuff has to be known clientside
<azonenberg>
i'm trying to avoid excessive round trips
<azonenberg>
that adds latency
<azonenberg>
look at all of the code for things like which channels can be enabled, or which sample rates are allowed, in particular configs
<azonenberg>
the FlexRes scopes have quite complex configurations
<azonenberg>
and it would be crazy to hit up the bridge for all of that
<bvernoux>
yes
<bvernoux>
just to find a good compromise
bvernoux has quit [Quit: Leaving]
<_whitenotifier-1>
[scopehal-pico-bridge] azonenberg pushed 2 commits to master [+0/-0/±5] https://git.io/Js8Ac
<_whitenotifier-1>
[scopehal-pico-bridge] azonenberg bc03657 - Refactored Stop() out to its own function. "capturing call stop" error handling can now handle repeated cases.
<_whitenotifier-1>
[scopehal-pico-bridge] azonenberg af0d63b - Refactored psXXXXRunBlock() into StartInternal()
<_whitenotifier-1>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/Js8xk
<_whitenotifier-1>
[scopehal] azonenberg 520d149 - Added channel interleaving and ADC mode configuration to scopesession file format
<_whitenotifier-1>
[scopehal] azonenberg closed issue #116: Add timebase configuration to save files - https://git.io/Jfg1w
<azonenberg>
Woo, down to 17 tickets for v0.1 on scopehal
<azonenberg>
R&S driver - fsedano, how's that going?
<azonenberg>
Serializing trigger config - I plan to work on that tonight
<azonenberg>
Equivalent time sampling, force trigger, auto trigger - no blockers, but i'll be doing other stuff first
<azonenberg>
VCD import - if anybody is looking for a project that's a good self-contained one. If not, I'll probably bang it out next weekend or something
<azonenberg>
LeCroy serial trigger - the hard part on this is the UI glue for handling all of the control characters and such in a pretty fashion
<azonenberg>
fx2lafw driver: xzcvczx did you say you were going to work on that?
<azonenberg>
i forget
<azonenberg>
I2S decode: another good starter ticket, we have test data ready to go
<azonenberg>
mjgerm has a closed PR with code that parses i2s but outputs it as sample objects, i think an analog waveform makes a lot more sense. But his code might be a good building block
<azonenberg>
LeCroy WaveSurfer 3000 channel interleaving: this is blocked on me getting into the lab at work where the WaveSurfer is. I'll be there some time in June and plan to work on it then
<azonenberg>
MIPI DSI ECC: another good small/starter ticket for somebody
<azonenberg>
MSO5000 timebase: Degi, you were working on that right?
<azonenberg>
Digilent SDK driver: on deck, I plan to work on that as soon as I've finished a few more rough edges on the Pico driver
<azonenberg>
Siglent 1000x-e: GenTooMan, any status updates on that?
<azonenberg>
CSV import timestamp: another good easy ticket for somebody
<azonenberg>
then finally, #433 will require going through all drivers and making them sanity check the *IDN? and complain if you try to use the driver on an incompatible instrument
<azonenberg>
and #383 i'm thinking of turning into a bit of a refactoring around the amplitude/peak to peak filter to make it selectable mode or something
<GenTooMan>
azonenberg, Still very much a work in progress nothing exciting like it working correctly.
<azonenberg>
Ok, no worries
<azonenberg>
considering i havent even started the digilent driver and i wanted that for v0.1, you're far from the bottleneck :)
<d1b2>
<mubes> Hmmm...I'd like to have digital channels on the SDS2000X+ working, but that needs Siglent to ship the probe. Hopefully this week we can move forward with that. I think the majority of the code is already in, but pretty untested.
<azonenberg>
mubes: yeah well considering i havent even started the digilent SDK stuff, i think you've got a fair bit of time
<azonenberg>
mainly i'm hoping to find someone to take on the "easy" tickets like the mipi ecc
<d1b2>
<mubes> It would be nice to test against SDS5K too (I have someone with one who can test)...so let's see how the time progresses. Did I see there was talk of a 'doze installer? That would really help him, he's not super-comfy building from scratch.
<azonenberg>
There is talk of that. As well as a msys2 package
<azonenberg>
Not sure how far any of that has gone
<azonenberg>
I know GyrosGeier was working on debian packaging (speaking of which, anything you need from me at this point? status?)