<_whitenotifier-a>
[scopehal-apps] azonenberg closed issue #369: Add close menu item - https://git.io/JG2Bb
nelgau has quit [Ping timeout: 272 seconds]
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 245 seconds]
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 264 seconds]
<xzcvczx>
azonenberg: will do
<xzcvczx>
azonenberg: also i may have missed it but did you have an opinion on only having a subset of the possible sdks rather than requiring them all to build pico-bridge?
<azonenberg>
xzcvczx: They're packaged separately on Windows?
<azonenberg>
on Linux it's a single package for everything
<xzcvczx>
no its not
<xzcvczx>
they are all seperate debs
<azonenberg>
interesting, i just apt-get install picoscope
<azonenberg>
and didnt check what else it pulled in
<xzcvczx>
yeah thats the gui
<xzcvczx>
so it pulls them all in
<azonenberg>
ah ok
<azonenberg>
I think it's reasonable to have all of them as dependencies for now
<electronic_eel>
hmm, so it is quite fast into glscopeclient, compared to other scopes
<azonenberg>
Yes. Throughput is 5x faster than the fastest LeCroy I've tested
<azonenberg>
in terms of Mbps of waveform data
<azonenberg>
and 40x faster than the Tek MSO6 which is the fastest non-lecroy i've tested
<azonenberg>
The Agilent MSO6034A is quite good when latency dominated at small memory depths, hitting 66 WFM/s
<azonenberg>
but gets bandwidth limited as memory depth increases, maxing out at 32 Mbps
<azonenberg>
probably cpu performance
<azonenberg>
the tek mso6 hits 61.6 Mbps, my older lecroy SDA hits 147, and my newer lecroy is 400
<azonenberg>
the picoscope hit almost 2.5 Gbps
<electronic_eel>
do they have proper triggers in hardware or do they cheat by doing some triggers in their software?
<electronic_eel>
i mean the more complex triggers
<azonenberg>
Triggering is full digital in the FPGA afaik
<azonenberg>
on processed adc samples
<azonenberg>
Right now glscopeclient only supports simple level triggers
<azonenberg>
the full suite is going to take more work but they have pretty complex triggering capability
<azonenberg>
I do not think there is protocol trigger support though
<azonenberg>
But i suspect the hardware could do it given firmware support
<azonenberg>
And yeah i just checked... with eight channels running right now at 1M points over ethernet (40G to network core, 10G to lab desktop, then bottlenecked on pcie 2.0 x1)
<azonenberg>
I'm getting 12-15 WFM/s
<azonenberg>
Network load is 1.5-1.6 Gbps
<azonenberg>
And with all sample data on screen (zoomed out fully), my 2080 Ti is using 8% of PCIe bandwidth and about 31% of the GPU capacity
<electronic_eel>
pico should develop a 40G or 100G ethernet product line...
<electronic_eel>
or maybe team up with you
<azonenberg>
my gpu is in the lowest to second lowest performance bin lol
<azonenberg>
And I would love if they at least launched a 10G product line. I've hinted at that already
<azonenberg>
If i ever quit my day job and go to work for pico, you bet that's going to be my focus :P
<azonenberg>
But short term i'm focusing on probes. There's already been hints of a joint project to make a power rail probe along the lines of the RP4030 or N7020A
<azonenberg>
No action has been taken on either side but both parties are interested
<azonenberg>
the plan would be for me to design an open source prototype and then potentially collaborate to make a fork that fits their active probe interface
<azonenberg>
We haven't worked out details of how that would happen yet. My current top priority probe wise is the ~6 GHz active diff probe
<electronic_eel>
cool, the proper power rail probes available are expensive, but useful
<azonenberg>
and the delay there is waiting on 3D printed prototypes
<azonenberg>
Yeah I love my RP4030
<azonenberg>
i just wish i had a few more to see severa lrails
<azonenberg>
One that fit a picoscope would be awesome because it's 8 channels
<azonenberg>
and 12 bit resolution
<azonenberg>
So i could use it to see lots of lower bandwidth power stuff while leaving the lecroys free for higher speed stuff
<azonenberg>
Anyway, the diff probe comes first
<azonenberg>
And i still have to fine tune the AKL-PT1
<azonenberg>
In parallel with all this i'm also tweaking the SMA footprints from my test board
<azonenberg>
I need to ping sonnet support some time this week with my initial simulations and VNA/TDR data
<azonenberg>
and see if they can help me tune the launch simulations to better reflect reality
<azonenberg>
All of my probes will benefit from more tightly impedance matched connectors
<electronic_eel>
why do the connector manufacturers not publish optimized launch geometries for different stackups? i guess it would help connector sales if the board developer just could pick a well optimized layout from their pool. especially if one of the premium mfgs does this while the cheap ones don't
<azonenberg>
They publish HFSS models and expect you to simulate
<azonenberg>
but the cheapest HFSS version costs like 3x what sonnet's fully decked out suite costs
<electronic_eel>
hmm, so they expect that their customers are fully equipped with that kind of software, or hire a contractor to run sims and create the geometries
<azonenberg>
Correct
<azonenberg>
Generally people don't do multi-GHz circuit design on a shoestring budget like i do :p
<azonenberg>
Or if they do, it's for something that's reasonably tolerant of a slighlty imperfect match
<azonenberg>
like, you can get away with a lot if you're just running pcie or something digital
<azonenberg>
or if it's RF communications, a little bit of return loss just reduces your range slightly
<azonenberg>
But for test equipment i'm aiming for maximal flatness
<azonenberg>
But like, the launch I used on the AKL-PT1 on the oshpark stackup is still below -15 dB to 6 GHz
<azonenberg>
this is what they look like time domain
<azonenberg>
the AKL-PT1 launch is blue, the cheap Samtec is black, and the fancy Rosenberger is brown
xzcvczx has quit [*.net *.split]
Stary has quit [*.net *.split]
asy_ has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
Bird|ghosted has quit [Remote host closed the connection]
Bird|ghosted has joined #scopehal
Stary has joined #scopehal
xzcvczx has joined #scopehal
kbeckmann has joined #scopehal
asy_ has joined #scopehal
gruetzkopf has joined #scopehal
bvernoux has joined #scopehal
_florent_ has joined #scopehal
<_whitenotifier-a>
[scopehal] enjoy-digital opened issue #494: CSV Import issue with floats (same comma both used as separator and decimal point). - https://git.io/JGrDx
<electronic_eel>
https://github.com/anthonix/ffts is quite dead, so should we merge the stuff required for scopehal in your fork?
Degi has quit [Ping timeout: 272 seconds]
<GyrosGeier>
my plan was to do the initial packaging and then slowly hand that over to someone else
<GyrosGeier>
I suspect your plan was to do the same
<GyrosGeier>
ideally, a fork would be maintained by someone who actually uses the package to an extent that they can fix bugs
<GyrosGeier>
my current mood is "I should give up my job and live in a commune somewhere and do open source work all day", but that isn't realistic
<GyrosGeier>
so my OSS time is rather limited
<electronic_eel>
GyrosGeier: yeah, i also have limited time available for open source stuff and similar hobbies
<electronic_eel>
i also don't have the time and knowledge to really work on ffts. it is just that properly packaging it requires patches, yours and the one i linked
<electronic_eel>
the question if we want to begin merging them in one repo (yours? or does azonenberg want to create one?) or if we want to keep separate patches
<GyrosGeier>
on Debian, we generally keep the patches separate in the package
<GyrosGeier>
and drop them when upstream integrates them
<GyrosGeier>
if you look at the .debian.tar.xz file, there are a few more in there
<electronic_eel>
yeah, fedora keeps necessary patches in a similar way too. but the intent is always trying to get them merged upstream first
<electronic_eel>
so, to me that sounds like you prefer to keep separate patches and not "maintain" a ffts fork, even in a minimal sense
<GyrosGeier>
yeah, ideally someone else will start a fork and merge our patches
<GyrosGeier>
but it'd absolutely make sense to use the same patches if we can
<GyrosGeier>
the biggest obstacle IMO is testing
<GyrosGeier>
specifically, the lack of it
<electronic_eel>
do you already have published debian packages for scopehal / glscopeclient somewhere?
<GyrosGeier>
the ffts package is already uploaded as well
<GyrosGeier>
the -1 version doesn't work, the -2 version will not compile on !amd64
<electronic_eel>
thanks, i will take a look (and maybe steal some patches if necessary or helpful)
<GyrosGeier>
I kind of cheated and used the autoconf build system instead of the cmake one
<GyrosGeier>
that solves a lot of problems I'd have with crosscompiling otherwise
<electronic_eel>
autoconf doesn't really appeal to me, i clearly prefer cmake
<GyrosGeier>
I needed two years until I felt at home in autoconf
<electronic_eel>
time i prefer to spend on something else instead...
<GyrosGeier>
its biggest power is that they had cross compiling as a use case from the start
<electronic_eel>
with cross compiling you mean cross-arch, so compile for arm64 on a x86_64 cpu?
<GyrosGeier>
both
<GyrosGeier>
basically, they look for a compiler for the current target architecture first, and then run tests that use that
<electronic_eel>
is cross compiling something like scopehal really that important to invest that much effort in it?
<GyrosGeier>
for scopehal, no
<GyrosGeier>
for ffts, people will ask
<electronic_eel>
you can get pretty decent arm boxes these days if you want
<GyrosGeier>
the problem with cmake is less a technical one, but more a way they organized their community
<GyrosGeier>
accepting lots of scripts that assumed that you were doing native builds
<GyrosGeier>
so if I wanted to cross compile I'd have to prepare a file that overrides all the test results
<GyrosGeier>
which is a non-starter for upgrades
<electronic_eel>
cross compiling always seemed very much effort to me to get right, requiring much work on all levels of the stack. i don't really see the usecase that justifies that
<GyrosGeier>
with the right tools, it's surprisingly simple
<GyrosGeier>
when I use autotools, I can just say "./configure armhf-linux", and get $CC set to a compiler that targets ARM
<GyrosGeier>
for anything that's just a library or just a program, with no custom build steps involving programs that need to be compiled first, you're already done then
<electronic_eel>
yeah, but when the original developer of a software doesn't want to deal with autoconf issues all day and uses cmake instead, then it becomes more of an issue if i understand you correctly
<GyrosGeier>
yes
<GyrosGeier>
it also doesn't help that a number of cmake advocates went out and submitted lots of patches "upgrading" the build systems
<electronic_eel>
at $dayjob we threw a big party a few years ago when the last package using autotools was converted to cmake...
<GyrosGeier>
IMO, cmake isn't much of an improvement, that's the most annoying thing
<GyrosGeier>
m4 sucks as a language because it has weird quoting rules
<GyrosGeier>
so it got replaced with a language that has other weird quoting rules
<GyrosGeier>
what would have made sense would have been one narrowly scoped system that can only build libraries and executables
<GyrosGeier>
and that consumes purely descriptive project files
<GyrosGeier>
it only needs a project manager who says no to scope creep
<GyrosGeier>
you can't have convenient general-purpose tools
<GyrosGeier>
any general-purpose tool will spawn an ecosystem of support libraries to make it convenient, which creates a userbase that can only interact with the top layers and is scared of what lurks at the bottom
<electronic_eel>
cmake isn't perfect, but since we moved everything to cmake the time required for dealing with build system issues went down considerably
<GyrosGeier>
at some point someone writes a new tool that is convenient to use in the base install, with an extension API that allows bolting on additional use cases, which then spawns an ecosystem of extensions to make it general-purpose
* GyrosGeier
sings "it's the circle of life"
<GyrosGeier>
the build system issues are now with the distribution maintainers :P
<GyrosGeier>
at least scopehal fits the standard mold
<GyrosGeier>
so I have some hope that cross-compiling will work with just the standard overrides
<GyrosGeier>
in Debian, we tend to get bug reports for that
<bvernoux>
azonenberg, do you have done an update on the footprint for starshipraider\boards\probes\sma-test ?
<bvernoux>
azonenberg, I ask that as I'm interested to do a footprint to rule them all ;)
<bvernoux>
azonenberg, combining different SMA footprint in one
<_whitenotifier-a>
[scopehal] azonenberg commented on issue #494: CSV Import issue with floats (same comma both used as separator and decimal point). - https://git.io/JGoSk
<azonenberg>
bvernoux: Current status is that I have 6 GHz VNA and 16 GHz TDR measurements of my board
<azonenberg>
waiting for derek to give me 26 GHz VNA measurements of his
<azonenberg>
Once I get that data I'll reach out to Sonnet support with our measurements and my simulations and see if they have tips on getting more accurate simulations
<azonenberg>
then plan a second iteration
<azonenberg>
not sure if you saw my TDR data but there's fairly significant impedance mismatches at the connectors
<azonenberg>
especially the lower cost ones
<azonenberg>
I think i can correct for it, but i have to figure out how much to correct by
<bvernoux>
azonenberg, ha yes great
<bvernoux>
azonenberg, do you have updated your footprint for the 901-10510-2 ?
<bvernoux>
It is interesting to have feedback with the tolerance depending on the fab
<bvernoux>
I have 10x 901-10510-2 I plan to do some PCB for test but it will be better if you have fixed the footprint (I could compare with mine)
<azonenberg>
I have not updated any of the footprints yet
<azonenberg>
Waiting on the full data
<azonenberg>
I know there are mechanical issues but i actually want to tune the impedance slightly too
<azonenberg>
18 is connector with CPWG full length, 19 has microstrip between
<azonenberg>
so it looks like the mismatch dip at the connector/transition is a bit larger, but then it also seems that the microstrip is slightly too high impedance
<bvernoux>
ha yes Samtec is clearly crap in comparison ;)
<azonenberg>
I think this can be greatly improved with proper launch design though, that's the thing
<bvernoux>
with lot of reflections too
<azonenberg>
I think my simulations just weren't accurate enough
<azonenberg>
But I don't want to be going to support until i have all the data i'm going to be getting
<azonenberg>
Hence waiting for derek's s-parameters
<bvernoux>
yes it is interesting to match such "low cost" Samtec connector as it is identical to some very cheap SMA from other brand which cost <0.5USD/unit
<azonenberg>
I mean, i know it's never going to be as good as the Rosenberger
<azonenberg>
the question is how good *can* I get?
<azonenberg>
how close
<bvernoux>
yes unfortunately manufacturer does not provide the matching details on such connectors
<azonenberg>
They provide HFSS models and assume you're simulating the whole board in HFSS
<bvernoux>
I think the only one to provide such details is Southwest Microwave with very nice App Note/Report with different tests
<bvernoux>
but I do not want to use Southwest Microwave connectors anymore as I was very disappointed by the ones bought on Ebay ;)
<azonenberg>
Yeah i really like the Rosenberger
<bvernoux>
maybe they could be used with center pin soldered anyway but it is not really interesting to use such big connectors if they requires to be soldered ...
<bvernoux>
I have received a RF board it is fun as the CPWG does not have any via ;)
<bvernoux>
the trace is not very long but it is clearly not a good practice for a big RF manufacturer
<bvernoux>
I think the worst is some eval board for RF using the cheap Samtec connector which are intended to go up to 14GHz+
<azonenberg>
lol
<azonenberg>
meanwhile in my testing with CPWGs missing even one via can be a HUGE difference
<bvernoux>
yes it is like a joke for an eval board which cost >200USD ;)
<azonenberg>
if you recall the AKL-PT2 original prototypes with the big notch at 5.8 GHz
<bvernoux>
yes I remember
<bvernoux>
yes CPWG is very sensitive to via spacing/size ...
<bvernoux>
it is why I'm asking what will be the perf on the eval board I have received and where they have "forgotten" via for CPWG ... even if the critical trace length is less than 7mm but on an other traces Bypass length is 2x2cm
<bvernoux>
on the good side they have used 142-0771-831 Powell_Inc or
<bvernoux>
901-10511-3 Amphenol RF connectors which are very good (even if they are awfull to solder)
<azonenberg>
Yeah I'm looking forward to getting the 901-10510-2 tuned further
<electronic_eel>
azonenberg: just finished the first build of the fedora-packaged glscopeclient. i just have to polish the build dependency list a bit
<electronic_eel>
my first plan was to do it the "right" way by packaging each lib separately, but the way the build system is currently organized makes this very hard
<bvernoux>
I still need to compare the datasheet as it seems exactly identical to 901-10510-2
<bvernoux>
but a bit less expensive with same spec
<electronic_eel>
so i opted to use a more pragmatic approach for now and do a recursive git checkout of scopehal-apps and compile that
<electronic_eel>
but before it has a chance to be accepted by fedora upstream this must be changed
<electronic_eel>
but i think it would be better do do this not for individual disto packaging alone, but allow to split the buildsystem in general
crabbedhaloablut has joined #scopehal
<_whitenotifier-a>
[scopehal] enjoy-digital commented on issue #494: CSV Import issue with floats (same comma both used as separator and decimal point). - https://git.io/JGopt
<crabbedhaloablut>
Has the move from freenode->Libera been documented somewhere on github?
<kc8apf>
azonenberg: work is finally settling on lab equipment. How well supported is Tektronix MSO54 by scopehal?
<_whitenotifier-a>
[scopehal-apps] xzcvczx opened pull request #374: Use cmake option to set c++ standard - https://git.io/JGKY7
<azonenberg>
electronic_eel: We'll worry about that later
<azonenberg>
kc8apf: tek mso5/6 is reasonably well supported, but not super performant or reliable. Their SCPI stack hangs a lot
<azonenberg>
Pico and LeCroy are the two most stable platforms right now
<kc8apf>
So for a 2GHz scope, we'd be looking at LeCroy
<azonenberg>
Yeah
<azonenberg>
WaveRunner 9204 would be a good choice. or is it 9254?
<azonenberg>
I know they have 1 and 4 GHz SKUs but forget if the middle is 2 or 2.5
<azonenberg>
They're 8 bit, 20 Gsps on all channels or 40 Gsps interleaved
<azonenberg>
AFAIK it's basically the WaveRunner 8000 series acquisition system repackaged with a slightly bigger LCD and faster PC motherboard
<azonenberg>
I've used both the 1 and 4 GHz WaveRunner 8000s and currently have a 4 GHz in my fleet, they're solid scopes that perform very well w/ glscopeclient
<kc8apf>
relayed
<azonenberg>
The other option to consider would be the WavePro 254HD which is the 12 bit offering in the same general class
<azonenberg>
Those are lower sample rate (10 Gsps on all channels interleaved to 20 Gsps on 2ch) but are also available with extremely deep memory, up to 2.5 Gpoints
<azonenberg>
actually derp, my bad. The WaveRunner 9254 is the same sample rate, 10/20. The 9254M is the 20/40 Gsps version
<azonenberg>
WaveRunner 9000 is 16M points/channel interleaved to 32, 9000M is 64M/channel interleaved to 128M, with no upgrades available beyond that
<azonenberg>
And I guess the one other possible model to consider would be the WaveRunner 8208HD which is 10 Gsps, 50M points memory, 12 bit, 2 GHz, but 8 channels
<azonenberg>
The WaveMaster/SDA series starts at 4 GHz so that's off the table, and I don't think any of the HDOs go past 1 GHz
<kc8apf>
leaving it up to the EEs
<kc8apf>
There had been some talk of using glscopeclient so I wanted to make sure they knew level of support
<azonenberg>
Yeah I've been talking to some apps engineers at tek about potentially getting a loaner for testing their new firmware launching shortly
<azonenberg>
but havent heard anything lately
<azonenberg>
it does work, it's just slow and occasionally hangs :p
* GenTooMan
watches his communication go wrong over and over again ... repeat repeat mutter. "So it's currently crashing yep it is."
<_whitenotifier-a>
[scopehal-apps] azonenberg closed pull request #374: Use cmake option to set c++ standard - https://git.io/JGKY7
<_whitenotifier-a>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JGKzi
<_whitenotifier-a>
[scopehal-apps] xzcvczx dfa06c9 - Use cmake option to set c++ standard
<_whitenotifier-a>
[scopehal-apps] azonenberg 68d2138 - Merge pull request #374 from xzcvczx/cmake_cxx11 Use cmake option to set c++ standard
<_whitenotifier-a>
[scopehal] azonenberg commented on issue #494: CSV Import issue with floats (same comma both used as separator and decimal point). - https://git.io/JGKzS
<electronic_eel>
azonenberg: fedora currently doesn't have clFFT packaged. packaging that for use with glscopeclient is on my todo. is there an easy way to test if clFFT works in glscopeclient? i mean beyond the message about it not being available on startup.
<azonenberg>
electronic_eel: If it detects clFFT and OpenCL at startup, it will attempt to use clFFT for the fft, channel emulation, and de-embed filters
<azonenberg>
One issue i'm running into is that really huge ffts seem to fail to run
<azonenberg>
maybe opencl work group size limits or something
<azonenberg>
i need to fall back to software in that case
<electronic_eel>
do you have a demo data file with a data set size that works reliably with clFFT for you?
<azonenberg>
Ping me in a couple hours after work and i'll see what i can dig up
<electronic_eel>
i still haven't done any work getting my rigol 4000 scope to work with scopehal, so i'm a bit limited in creating data myself
<electronic_eel>
no hurry, i'm going to bed now and can maybe work on this tomorrow evening or on the weekend. so i don't need that file before then