<GenTooMan>
normal docs are about 7-8% coverage, a lot of people have taken HP and Xerox to task regarding "the metric" they demanded. Regardless the issue as usual is "pages" just sounds nice but tends not to be accurate.
<xzcvczx>
well tbh i dont really blame the printer mfgs there, its a very simplified thing but its arguably the easiest metric for laymen to pass
<xzcvczx>
parse
<GenTooMan>
yeah that's why they created it. As for pass that's funnier than parse. "Laymen pass" ... :D
<xzcvczx>
you shall not parse
<azonenberg>
xzcvczx: re nice self describing filter names, that is actually something i need to work on in glscopeclient
<azonenberg>
if you make a chain more than 2-3 filters long the names get untenable
<azonenberg>
i need to start shortening them
<azonenberg>
I also ideally would not have a SetDefaultName() function in every single filter
<azonenberg>
it would be nice if there was one implementation in the Filter class that did all the work for you, and would truncate names with ...'s when they got more than a configurable length, perhaps set in preferences
<xzcvczx>
fair enough, but please dont try and come up with some fancy names for them in the menu so that it takes 20x as long to actually find what you need because you dont know app-specific lingo
<azonenberg>
lol
<azonenberg>
No I'm definitely not going to do that :p
* xzcvczx
gives azonenberg a cookie
<xzcvczx>
(a strictly necessary cookie so you can't reject it)
<azonenberg>
lol
* azonenberg
noms on the session cookie
<azonenberg>
noopwafel: you had a picoscope 3000 series right? no other families?
* xzcvczx
tracks azonenberg's life
bvernoux has quit [Read error: Connection reset by peer]
tnt has quit [Ping timeout: 246 seconds]
tnt has joined #scopehal
monochroma has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
kbeckmann has joined #scopehal
monochroma has joined #scopehal
<_whitenotifier-3>
[scopehal-pico-bridge] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J36Pc
<_whitenotifier-3>
[scopehal-pico-bridge] azonenberg closed issue #8: FlexRes support for 6000E series - https://git.io/J3wIF
<_whitenotifier-3>
[scopehal-pico-bridge] azonenberg commented on issue #8: FlexRes support for 6000E series - https://git.io/J36Pa
<_whitenotifier-3>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/J36PV
<_whitenotifier-3>
[scopehal] azonenberg f82840b - PicoOscilloscope: added initial model ID detection. Began groundwork for FlexRes support.
<_whitenotifier-3>
[scopehal] azonenberg e3a06c3 - Initial clientside implementation of FlexRes for Pico
* xzcvczx
adds 22 to azonenberg's commit
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #454: Pico: when using FlexRes, not all channels and sample rates are available - https://git.io/J36Xp
<_whitenotifier-3>
[scopehal] azonenberg opened issue #454: Pico: when using FlexRes, not all channels and sample rates are available - https://git.io/J36Xp
<azonenberg>
hoooo boy this is going to be fun
<azonenberg>
i need to handle all kinds of situations where you enable a channel, change sample rate, or change ADC mode
<azonenberg>
that can lead to oversubscribing hardware resources
<azonenberg>
And the question is then, how to handle these cases?
<azonenberg>
I think i'm going to have the most recently changed setting take precedence
<azonenberg>
then downgrade other settings as needed to make a legal config
<xzcvczx>
i think that can also lead to confusion thos
<xzcvczx>
though
<xzcvczx>
as then people are like, huh i set these 5 settings and a bunch changed "randomly" on me
<azonenberg>
Yeah thinking a bit more i think i can just hide illegal modes
<azonenberg>
so for example if you have 2 channels active and 5 Gsps sample rate selected
<azonenberg>
it won't let you turn on any more channels until you pick a <= 2.5 Gsps sample rate
<xzcvczx>
maybe a tooltip to say that as well
<xzcvczx>
or some sorta descriptive text
<xzcvczx>
i hate it when using software and being locked out of modes and having no idea why
<azonenberg>
That will be a later improvement. first goal is to not crash the driver by allowing you to pick invalid configs :)
<xzcvczx>
then again im a bit of an idiot
<xzcvczx>
fair neough
<GenTooMan>
xzcvczx, reminds me of a question I asked a psych major, "Which would you rather be a Moron an Idiot or an Imbecile", because they had just had questions on that in class. Oh well I was hoping they would over think the question.
<GenTooMan>
on topic the wave form stuff is a bit weird, I'm attempting to handle order and it seems the code spits out a set of commands then reads the results latter.
<azonenberg>
If the scope handles it (not all instruments' firmware does)
<azonenberg>
it's much faster to queue up a bunch of commands then read replies back to back
<azonenberg>
vs lock-step sending a command, waiting for a reply, then sending the next
<azonenberg>
especially if attached via USB where you have a 1ms TDMA latency between every round trip
<azonenberg>
USB2*
<azonenberg>
i think usb3 improved on this a bunch
<azonenberg>
The same thing is true when using TCP/IP over laggy connections like a VPN
<azonenberg>
the less round trips, the better
<azonenberg>
if you look at the LeCroy driver, I went so far as to read waveforms then arm the trigger before i've even parsed the response
<azonenberg>
so that the scope can be acquiring data in parallel with glscopeclient converting the raw adc samples to an AnalogWaveform object doing all of the int8 to fp32 scaling etc
<d1b2>
<david.lenfesty> perhaps, in retrospect, picking an F103 wasn't a great choice for the active probe interface
<d1b2>
<david.lenfesty> also, probably able to get back at it over the next bit. School wiped the floor with my mental health but I'm back to work so I should be able to carve out some consistent time
<azonenberg>
Ok
<azonenberg>
I have the two boards you sent me but have not touched them yet
<azonenberg>
Nor have i tried to source parts for the other one
<azonenberg>
which... might be difficult
<xzcvczx>
ffs st just release you damn products from preview rather than having more webinars
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #455: Add #ifdef guards to disable all AVX optimizations on non-x86 platforms - https://git.io/J3ifb
<_whitenotifier-3>
[scopehal] azonenberg opened issue #455: Add #ifdef guards to disable all AVX optimizations on non-x86 platforms - https://git.io/J3ifb
<xzcvczx>
wheres the manual avx stuff?
<azonenberg>
xzcvczx: off the top of my head the LeCroy driver, eye pattern, de-embed/channel emulation, FIR, and FFT filters use it
<azonenberg>
TavyCats is already working on it, they're trying to get scopehal to compile on ARM
<azonenberg>
Just filing the ticket for tracking purposes
<xzcvczx>
are compilers rather terrible at using avx instructions?
<azonenberg>
They can vectorize simple things like a loop that just adds numbers together (at least if you give it some hints)
<azonenberg>
but a lot of times I find myself doing more complicated things like interleaving multiple iterations of a loop, mixing vector and scalar math, etc
<azonenberg>
the eye pattern for example has a short bit of scalar stuff then processes ~8 samples in a block vectorized, then goes back to scalar at the end
<azonenberg>
although i think it might be possible to flatten some of that scalar stuff w/ avx512 gather/scatter?
<azonenberg>
Generally I start by writing everything in C++, optimize if I see it getting slow
<azonenberg>
then if it's easily vectorizable and does a lot of repetitive number crunching i consider moving to opencl and/or avx
<xzcvczx>
i am still surprised this cpu has avx
<azonenberg>
AVX2 has been around since Haswell, AVX1 is even older
<azonenberg>
I use AVX2 in most cases and i think i have one or two filters that use AVX512 if available
<azonenberg>
Which is much rarer, it's on enthusiast/server grade Skylake cores but i think is making its way into mainstream now
<xzcvczx>
hmmm whats the avx2 flag? avx2? or some other weird one?
<xzcvczx>
doesn't avx512 still bring computers to their knees?
<azonenberg>
avx2
<azonenberg>
avx512 has several subflags depending on the exact variant, it has subsets you can implement
<xzcvczx>
>_< i dont think i got avx2 then
<azonenberg>
And mixing avx512 with other stuff willy nilly can be slow
<sorear>
avx is ancient BUT disabled by fuses in intel's cheapest skus
<azonenberg>
But if you do a lot of avx512 in a tight loop it's quite fast
<azonenberg>
the FIR filter, for example, makes heavy use of the AVX512 FMA instruction
<sorear>
what will be fun is in 0-2 years when the off-patent opteron64 clones start showing up, those won't have avx but will have almost everything else
<azonenberg>
I can probably fine tune the implementation more but it's already quite a bit faster than the non-avx version
<xzcvczx>
hmmm i am surprised i haven't run into any avx2 instructions
<azonenberg>
Default configuration for most compilers is to not use them
<azonenberg>
for compatibility
<xzcvczx>
but dont you have hand optimised avx2?
<azonenberg>
glscopeclient should compile and run on basically any x86-64 right now so i dont use any of the newer instructions in generated code by default
<azonenberg>
Yes, using __attribute__("avx2") which tells the compiler that specific function can use avx instructions
<azonenberg>
then i do a runtime cpuid check and only call that implementation of the cpu supports it
<azonenberg>
Nothing wrong with having avx instructions in a binary running on a non-avx capable CPU as long as you never call them
<xzcvczx>
oh nice
<azonenberg>
Some of the more numerically intensive filters like the FIR actually have four versions
<azonenberg>
generic C++, AVX2 (8 way vectorized), AVX512 (16 way vectorized), and OpenCL
<azonenberg>
Right now I always use OpenCL if you have a compatible GPU unless you run with the --noopencl switch, then prefer AVX512, then AVX2, then fall back to generic
<azonenberg>
Long term i'd like to actually benchmark on end user systems
<azonenberg>
have it figure out for each filter what implementaiton is fastest
<azonenberg>
maybe you have a really nice cpu and a pretty generic gpu and for some filters avx is faster
<xzcvczx>
lol well i use generic as i dont have any other support
<azonenberg>
Yeah, the point is that i wanted binaries that will be as portable as possible
<azonenberg>
rather than having to recompile for each target
<azonenberg>
one x86 binary that figures out what it can use at run time is much better
* xzcvczx
gives azonenberg another cookie for making it run on 4.2
<_whitenotifier-3>
[scopehal] azonenberg pushed 3 commits to master [+0/-0/±4] https://git.io/J3iCS
<_whitenotifier-3>
[scopehal] azonenberg 7ef42f3 - PicoOscilloscope: added CanEnableChannel() logic for 6000 series. See #454.
<_whitenotifier-3>
[scopehal] azonenberg 3306987 - PicoOscilloscope: report channels as enable-able if they're already enabled
<_whitenotifier-3>
[scopehal] azonenberg 818260f - Clarified comment for CanEnableChannel()
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J3iCH
<_whitenotifier-3>
[scopehal-apps] azonenberg e2710f8 - OscilloscopeWindow: fixed bug where adding a new channel failed to refresh the channels menu and could potentially allow bank conflicts
Tost has joined #scopehal
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J3igP
<_whitenotifier-3>
[scopehal] azonenberg closed issue #454: Pico: when using FlexRes, not all channels and sample rates are available - https://git.io/J36Xp
<_whitenotifier-3>
[scopehal] azonenberg opened issue #456: Pico: Support for channel attenuation - https://git.io/J3igH
<_whitenotifier-3>
[scopehal] azonenberg assigned issue #456: Pico: Support for channel attenuation - https://git.io/J3igH
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #456: Pico: Support for channel attenuation - https://git.io/J3igH
<_whitenotifier-3>
[scopehal] azonenberg opened issue #457: Pico: Support for digital channels - https://git.io/J3igF
<_whitenotifier-3>
[scopehal] azonenberg assigned issue #457: Pico: Support for digital channels - https://git.io/J3igF
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #457: Pico: Support for digital channels - https://git.io/J3igF
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J3iN6
<_whitenotifier-3>
[scopehal] azonenberg 7f89b79 - LeCroyOscilloscope: removed clearing of waveforms in Stop() as this makes more sense to do outside the driver
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 4 commits to master [+0/-0/±5] https://git.io/J3iNH
<_whitenotifier-3>
[scopehal-apps] azonenberg fe21a8d - Added "DEBUG BUILD" text to title bar if _DEBUG is defined. Added default _DEBUG define for debug configuration
<_whitenotifier-3>
[scopehal-apps] azonenberg 04f0a2c - OscilloscopeWindow: clear pending waveforms when stopping the capture
<_whitenotifier-3>
[scopehal-apps] azonenberg 80f0fa7 - WaveformArea: fixed a few things that should have cleared persistence but didn't
<azonenberg>
fsedano: How's the R&S driver coming along? Haven't seen any PRs from you in a while, but not sure if that's a good or bad sign
<d1b2>
<fsedano> Hey - it’s just a sign of my day work taking all my time during week 🙂 I’ll continue on the weekend
<azonenberg>
No worries. What's the current status? What works/what's left to do?
<azonenberg>
Right now I'm hoping to have RTM3000 and PicoScope 6000 series support reasonably complete and stable for the v0.1 release. Which doesn't have any kind of timeline yet, but I'm hoping we can finish all of the relevant stuff some time this summer
<azonenberg>
At the moment there are 25 open tickets against scopehal-apps and 29 against scopehal that are tagged as v0.1
<azonenberg>
so you're far from the bottleneck :)
<d1b2>
<fsedano> Triggers are missing and support for digital channels. That, together with protocol decoding not working on analog channels makes not ideal to decode. I’ll try more stuff on the weekend
<d1b2>
<fsedano> Basic operations work fine now - change levels, offset, data is fine now, no more corruption or hangs once we fixed the capture
<azonenberg>
Great
<d1b2>
<fsedano> It’s usable - it wasn’t before, so we’re not bad
<azonenberg>
When you get back to it, you should be able to just apply a threshold at 50% on the analog channels and get digital data to run a decode on
<d1b2>
<fsedano> Yea.. just looks cumbersome, on the scope UI you apply the thresholds on the decoder itself, so (at least for me) is unintuitive
<azonenberg>
There is a pending ticket for adding some UI glue to infer a threshold filter any time you try to run decodes on an analog channel directly
<azonenberg>
It's actually the oldest open ticket on the repo, lol. Just over two years
<Degi>
lmao
<azonenberg>
I'll gladly accept a PR for it if somebody figures out a nice user interface and writes all the glue code
<azonenberg>
I've just got my hands full with other stuff and haven't had time to write it
<azonenberg>
And given the laundry list of other projects i'm working on, and having a kid on the way, i doubt that situation will change soon
<azonenberg>
I'm trying to focus my efforts on writing driver code for scopes I personally own, writing decodes and filters that I expect to use at work, general UI improvements since I'm mostly the only one doing that
<azonenberg>
and coordinating everyone else's development
<azonenberg>
noopwafel: So after this past few days of dev the picoscope 6000 driver is vastly improved and almost at the point of usability
<azonenberg>
So we might want to start thinking about what refactoring might be needed to start patching other instrument families into the code
<azonenberg>
and how this is going to look architecturally
<noopwafel>
so I was thinking about doing a first pass at 3000 support by just #ifdeffing
<noopwafel>
(not something to merge obviously)
<noopwafel>
in the hope of at least making it clear whether there's any major API differences - I don't think there are
<azonenberg>
are you using the ps3000 or ps3000a api?
<azonenberg>
it appears that most of the APIs have two versions, the base and the A which is the more modern/featureful version
<azonenberg>
keeping the A for everything is probably best
<noopwafel>
ps3000a
<noopwafel>
from memory, they correspond to different hardware?
<azonenberg>
hmm, i'm not sure - 6000 and 6000a are both for 6000 series
<azonenberg>
it's possible you have to keep ps3000 for some of the older hardware?
<azonenberg>
anyway, as a first pass
<azonenberg>
my suggestion is that you ifdef the bridge and patch in the api code as needed
<azonenberg>
but use that as a testbed to work on getting support in the PicoOscilloscope class
<azonenberg>
for model detection etc
<azonenberg>
the bridge should hide most of the differences between models so it should be pretty easy
<azonenberg>
the main things i expect to be model specific are the logic to check whether you can enable channels or sample rates or memory depths based on what's turned on right now
<noopwafel>
so the picoscope 3000 docs say: 3204/3205/3206, 3224/3424, 3425. and the A API docs list a different set.
<azonenberg>
ah, ok
<azonenberg>
So we might have to support both, lovely
<azonenberg>
The 6x2xE series are the only ones with FlexRes right?
<noopwafel>
similarly the ps6000a api says 6000E and the ps6000 prog guide at least *looks* like it's for the older ones
<azonenberg>
Hmm, interesting
<noopwafel>
(the ps6000 prog guide is also last updated 2016)
<azonenberg>
6000A is totally undocumented
<azonenberg>
I've been using the 6000 series guide and then going off the header files lol
<azonenberg>
to figure out how to use it :p
<noopwafel>
oof
<azonenberg>
it's mostly worked so far
<azonenberg>
6000A docs are coming but last time i checked not ready for release yet
<azonenberg>
i've pinged their engineers a few times when i had issues
<noopwafel>
anyway, my picoscpi hack was for 3000a
<azonenberg>
Ok
<noopwafel>
and I've written a lot of side channel stuff against this API, I don't think there's anything unclear
<azonenberg>
So yeah, let's see about getting 3000a support in the bridge and the PicoOscilloscope class even if hacky
<azonenberg>
then go from there
<azonenberg>
also it looks like the 5000 series scopes are FlexRes too, 8 to 16 bit resolution capable depending on config
<azonenberg>
So i'll want to get my hands on one of those to test at some point
<noopwafel>
I'm hoping you can basically just add switch statements in a bunch of places, bridge-side
<azonenberg>
Yes that is my hope
<azonenberg>
Most apis are only called once or twice in the codebase
<azonenberg>
so a wrapper layer within the bridge seems like it'd be more trouble than it's worth
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #335: Improve "conditional halt" system to support filtering of waveforms - https://git.io/J3Pz5
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #335: Improve "conditional halt" system to support filtering of waveforms - https://git.io/J3Pz5
<azonenberg>
noopwafel: thinking a bit more rather than just doing ifdefs, how hard would it be to add a command line argument to pick the API to use at run time?
<azonenberg>
Are there compile time conflicts with having >1 API present?
<noopwafel>
well, I was thinking of just #ifdefs as a quick hack
<azonenberg>
ah ok
<azonenberg>
if we can have everything in one binary that would be great
<azonenberg>
That would mean instead of ps6000d we could rename the bridge to something more generic and only have one
<noopwafel>
exactly
<noopwafel>
that would be the nicest approach
<noopwafel>
in the worst case it needs a bit more abstraction in places
<azonenberg>
my original plan was a generic SCPI server layer and then implementations per API
<azonenberg>
but the abstraction i think will be so thin that a bunch of switch statements will work
<azonenberg>
BTW, as far as segmented memory is concerned, it's not supported yet
<azonenberg>
but my plan is to expose it the same way as the partially implemented support in the lecroy driver is
<azonenberg>
namely, segments are just considered waveforms
<azonenberg>
there will be some new APIs to configure it, but waveforms will come off the scope exactly the same whether they came in segments or a single block
<azonenberg>
also see #335
<noopwafel>
that's pretty much exactly what they are anyway
<azonenberg>
yeah
<noopwafel>
streaming is more interesting :)
<azonenberg>
I think we will be able to do some really powerful stuff if we add filtering capabilities combined with segmented memory
<azonenberg>
so we could quickly search through thousands of waveforms and display only the ones meeting some criteria
<azonenberg>
for extra fun maybe we could even align them to do software post-triggers
<noopwafel>
you can now imagine me trying to do usb debugging with the picoscope software
<azonenberg>
but to start, filtering on decodes will be a good starting point
<azonenberg>
Lol
<azonenberg>
they dont even have a usb decode, do they?
<noopwafel>
manually searching for that one segment with the relevant packets .. :P
<noopwafel>
they have usb1.1
<noopwafel>
which I tried using this once.. :) it was not fun
<azonenberg>
ah ok 1.1 but not 2.0
<noopwafel>
but yes, it would be really nice to have
<azonenberg>
yeah i want to be able to do things like filtering on bulk transfers to device 3 endpoint 1
<azonenberg>
This is of course on top of the filtering you can already do in the protocol analyzer view
<azonenberg>
Which is decently fast after my recent optimizations
<noopwafel>
so the one thing which is annoying to support is the downsampling
<azonenberg>
I've got a dataset for work right now with over half a gigasample per channel (split across multiple waveform segments obviously) and something like 300K protocol decode events in the analyzer view
<noopwafel>
which can be useful in some circumstances but I think just isn't worth considering in the design atm
<azonenberg>
yeah downsampling on a picoscope i dont see as being useful
<azonenberg>
Streaming decimated data then pulling full res later would be super useful for e.g .a slow rigol
<azonenberg>
to get an overview of a waveform before pulling the whole thing over many seconds of delay
<azonenberg>
but if you have the bandwidth its not worth it
<noopwafel>
anyway, I am likely not going to look at this today
<azonenberg>
Yeah no worries
<noopwafel>
not home, have phdthesis/introduction.tex open in vscode
<azonenberg>
also i just checked
<azonenberg>
Applying a filter to the 300K packet dataset currently takes maybe a second or two to find all of the "read SFDP" transactions
<azonenberg>
I'm sure i could optimize it more, i havent bothered yet as it's fast enough for my purposes
<noopwafel>
but but feel free to ping me in a couple of days (or even tomorrow)
<azonenberg>
yeah i'm not in a hurry, i just wanted to let you know that the bridge and driver is reaching a level of maturity that it's no longer a bad idea for you to start hacking on it
<noopwafel>
that is great to hear
<azonenberg>
There's still missing features but it's reasonably stable and working well, to the point that i'm confident implementing the remaining features can be done without major architectural work
<azonenberg>
and honestly at this point we need to start adding support for more models to find the problems in the abstractions etc
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #336: Protocol analyzer: allow "data" column to be displayed as ascii, hex, or ascii+hex dump format - https://git.io/J3PVl
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #336: Protocol analyzer: allow "data" column to be displayed as ascii, hex, or ascii+hex dump format - https://git.io/J3PVl
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #337: Protocol analyzer: allow filtering based on the data column - https://git.io/J3PVK
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #337: Protocol analyzer: allow filtering based on the data column - https://git.io/J3PVK
Tost has quit [Ping timeout: 265 seconds]
juli9610 has joined #scopehal
Tost has joined #scopehal
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #458: Add "cycle to cycle" vs "global" switch to measurements where applicable - https://git.io/J3Xjh
<_whitenotifier-3>
[scopehal] azonenberg opened issue #458: Add "cycle to cycle" vs "global" switch to measurements where applicable - https://git.io/J3Xjh
<_whitenotifier-3>
[scopehal] azonenberg opened issue #459: Add measurement for phase/delay (selectable output in angle or time units) between two waveforms - https://git.io/J31eO
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #459: Add measurement for phase/delay (selectable output in angle or time units) between two waveforms - https://git.io/J31eO
<_whitenotifier-3>
[scopehal] azonenberg opened issue #460: Add measurement for gain between two channels - https://git.io/J31eK
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #460: Add measurement for gain between two channels - https://git.io/J31eK