<d1b2>
<johnsel> also @david.rysk [cmake] CMake Error at CMakeLists.txt:138 (find_path): [cmake] Could not find LIBFFTS_INCLUDE_DIRS using the following files: ffts.h
<d1b2>
<johnsel> when I use vs code with the cmakelists and mingw64
<d1b2>
<david.rysk> did you install ffts?
<d1b2>
<david.rysk> or rather, how did you install it?
<azonenberg>
(ffts can't die soon enough, lol)
<d1b2>
<david.rysk> I looked into it, not all that easily
<d1b2>
<azonenberg> @david.rysk maybe that can be your next cleanup project lol
<d1b2>
<david.rysk> fftw is awfully heavy 🙂
<d1b2>
<azonenberg> yes but it'd only be a dependency for tests
<d1b2>
<david.rysk> also its cmake scripts have annoying bugs
<d1b2>
<johnsel> I followed your instructions, copy pasted them
<d1b2>
<azonenberg> for non-test it would just be 100% vkFFT
<d1b2>
<johnsel> if it's in there I did
<d1b2>
<david.rysk> let me see...
<d1b2>
<johnsel> using mingw64 cmd line it does seem to work
<d1b2>
<johnsel> you could try yourself with vs code if you want
<d1b2>
<david.rysk> oh, it doesn't work from vscode?
<d1b2>
<johnsel> correct
<d1b2>
<david.rysk> hm
<d1b2>
<johnsel> plain mingw works but not in vs code
<d1b2>
<johnsel> probably some mingw64 shedazzle not set right
<d1b2>
<johnsel> I'll check for msys2 support as well
<d1b2>
<johnsel> or just run w/ gdb on the end result of my plain build
<d1b2>
<david.rysk> so it's basically looking for ffts/ffts.h
<d1b2>
<david.rysk> ...you're sure you're calling the correct cmake/
<d1b2>
<david.rysk> ?*
<d1b2>
<johnsel> oh uh
<d1b2>
<johnsel> weirdly enough it's working now
<d1b2>
<johnsel> I did clean out the folder just now
<d1b2>
<david.rysk> there are separate cmake's for mingw, ucrt, clang
<d1b2>
<johnsel> maybe something cached wrong
<d1b2>
<david.rysk> aaah yeah
<d1b2>
<johnsel> nah vs code can scan for gcc-s and it find mingw64 and knows what it is
<d1b2>
<johnsel> must have been cache
<d1b2>
<johnsel> @azonenberg I'm thinking about adding support for NanoVNA/LiteVNA and TinySA
<azonenberg>
Sounds good
<d1b2>
<johnsel> they are both pure USB devices though
<d1b2>
<johnsel> would it make sense to introduce some libusb transport?
<d1b2>
<johnsel> something that can talk to the generic libusb/winusb/etc drivers
<d1b2>
<johnsel> a bridge is possible too, but I personally rather just integrate it in scopehal directly
<d1b2>
<johnsel> I also have a SmartScope which is a cheapo open-source scope with also direct libusb calls and some kind of wacky protocol
<azonenberg>
There's arguments for both
<azonenberg>
i really like having network transparency for everything
<d1b2>
<johnsel> Right, in general me too, is it relevant for these $200 devices though? I just plug in the cable
<d1b2>
<david.rysk> is there an existing lib for it?
<d1b2>
<johnsel> I would never consider using them remotely
<d1b2>
<johnsel> there are some desktop applications, python libraries etc
<d1b2>
<azonenberg> i mean a $200 specan sounds like the kind of thing i'd buy a handful of and scatter around the lab
<d1b2>
<azonenberg> and want to access headlessly from anywhere
<d1b2>
<azonenberg> so yes
<d1b2>
<johnsel> actually I'm misremembering, LiteVNA and TinySA use serial ports with a custom protocol
<d1b2>
<azonenberg> oh if its serial then its trivial to provide network transparency via socat and the lan transport
<d1b2>
<azonenberg> you can just use the uart scpitransport if local
<d1b2>
<johnsel> I have such a bad memory
<d1b2>
<david.rysk> yeah that's fairly typical because of drivers
<d1b2>
<johnsel> I used to have a great memory, but then some things happened
<d1b2>
<david.rysk> (and the lack of wanting to write one)
<d1b2>
<johnsel> anyway yeah then we have the transport handled
<d1b2>
<azonenberg> this is why all of my hardware is going to be ethernet connected :p
<d1b2>
<david.rysk> there are a few things where direct makes sense
<d1b2>
<david.rysk> thunderscope is one of them
<d1b2>
<david.rysk> basically if you're moving large volumes of information and adding network will add latency
<d1b2>
<johnsel> Yeah DMA to SCPI is not great
<d1b2>
<azonenberg> yeah but we can handle microseconds of latency we just want throughput
<d1b2>
<david.rysk> (yes there are ways around it, but imo you should have both options)
<d1b2>
<azonenberg> thunderscope can do their thing
<d1b2>
<johnsel> you're copying that datastream so many times at that point
<d1b2>
<azonenberg> all of my gear is going to be native 10GbE
<d1b2>
<david.rysk> RDMA isn't well standardized
<d1b2>
<johnsel> I was playing with that actually but haven't gotten it to work, but I think I may have more success with LitePCIe DMA
<d1b2>
<johnsel> (my current FPGA lacks support for now)
<d1b2>
<johnsel> anyway that is an aside
<d1b2>
<johnsel> for ThunderScope it's not a huge problem but with our next projects we're looking at 50+GBit/s DMA
<d1b2>
<johnsel> copying that a few times is less viable
<d1b2>
<david.rysk> how practical is RoCE at this point?
<d1b2>
<johnsel> It's expensive
<d1b2>
<johnsel> we're definitely looking at growing a networking stack though but you either have to pump 80Gbit/s (for FASTSCOPE) over the connection and do software triggering (what ThunderScope does right now)
<d1b2>
<johnsel> or you need to start building some gateware to do that in the fpga instead
<d1b2>
<johnsel> but PCIe is a free interface in principle, ThunderBolt/USB4 adds 10s of euros, going to something with RoCE you're looking at 100s of euros in network interfaces for the host side, and even on the fpga side I've seen paid IP that implements it (as opposed to the free 10/40/100gbe IP that you normally get)
<d1b2>
<johnsel> that reminds me did you validate your design yet?
<d1b2>
<johnsel> actually what we want is to RDMA from the FPGA to the GPU directly
<d1b2>
<azonenberg> which design
<d1b2>
<azonenberg> i have 10G MAC/PCS in FPGA working reliably and have for a while. still working on building out 25/40/100G IPs
<d1b2>
<johnsel> haha right, the one that is the testbed for the new US+ designs
<d1b2>
<johnsel> I meant the PCB design itself
<d1b2>
<azonenberg> No. The board is about 90% done and got shelved when my base-T1 media converters arrived
<d1b2>
<azonenberg> i've been bringing up those and working on a scopehal PAM3 CDR filter instead
<d1b2>
<johnsel> Aaah okay, once you validate it I'll see if I can make a derivative
<d1b2>
<johnsel> throw off all the networking stuff
<d1b2>
<johnsel> and route out some PCIe and FMCs
<d1b2>
<azonenberg> It's also got a microcontroller that is 0.5mm pitch which is pushing limits for oshpark
<d1b2>
<azonenberg> i need to decide if i want to keep that as the actual MCU
<d1b2>
<azonenberg> or put it in a corner as a test and then have a separate stm32h7 for the stuff i actually want to work
<d1b2>
<azonenberg> (as in 0.5mm BGA)
<d1b2>
<johnsel> I mean if it's pushing the limit you may be better off switching it out with something reliable. Wouldn't be great if your 500USD board failed on account of a microcontroller
<d1b2>
<azonenberg> Well it depends on the definition of fail
<d1b2>
<johnsel> sure, fail to do what you want
<d1b2>
<azonenberg> it would still prove the FPGA was alive but a bunch of GPIOs on the optics would be inaccessible
<d1b2>
<azonenberg> this whole board is an exercise in what i can get away wtih on oshpark
<d1b2>
<azonenberg> no sane person would put a ku+ on a 4 layer PCB
<d1b2>
<azonenberg> but anyone who calls me sane is clueless or lying :p
<d1b2>
<johnsel> you know it
<d1b2>
<david.rysk> A lot of people I know don't use oshpark because they aren't as price competitive as they used to be with JLC and similar vendors having popped up
<d1b2>
<johnsel> I didn't even realize it was 4
<Darius>
let us say "adventurous" :D
<d1b2>
<johnsel> you're... yeah
<d1b2>
<johnsel> adventurous is a good word lol
<d1b2>
<azonenberg> I try to support US PCB fab where I can and only go to china where it's completely unreasonable to have it done domestically
<d1b2>
<azonenberg> Like my more complex designs where US fabs quote me $6700 for a prototype
<d1b2>
<david.rysk> The problem you run into is... yeah, US fabs aren't set up for small run complex work
<d1b2>
<david.rysk> and seem to not be terribly interested in that
<d1b2>
<azonenberg> oh they are. but usually its coming from national security sectors that arent price sensitive
<d1b2>
<azonenberg> at all
<d1b2>
<david.rysk> I hear about similar issues around machining, and jlc/pcbway/others have gotten into that business too
<d1b2>
<azonenberg> if your board is ITAR or something, they don't have to compete with china on price
<d1b2>
<azonenberg> because you cant legally send it there
<d1b2>
<azonenberg> So they'll charge as much as they want and you'll pay it
<d1b2>
<david.rysk> More like I've known people who have tried to go to US manufacturers and can't get them to call back
<d1b2>
<david.rysk> (for non-ITAR type work)
<d1b2>
<david.rysk> meanwhile shops are closing up due to lack of business, well.
<d1b2>
<david.rysk> kinda difficult when you make people jump through hoops...
<d1b2>
<azonenberg> yeah i actually was just talking with a friend about how the semiconductor folks are getting all this sexy chips act funding and PCB fab seems to be getting less attention
<d1b2>
<azonenberg> guess what your chips arent any good if you dont have boards to put them on
<azonenberg>
The invalid channel name warning is likeyl from some refactoring i did a while back that produced a non-backward-compatible change to a few filters
<azonenberg>
(session still load but the port in question no longer exsists)
<azonenberg>
it shouldnt crash though
<d1b2>
<johnsel> and where exactly is lib\scopehal\EyeMask.cpp EyeMask::RenderInternal's output being used?
<d1b2>
<johnsel> I put some random values in but it doesn't seem to affect the eye mask
<azonenberg>
It's being used in pass/fail testing of eye patterns
<azonenberg>
it only affects the mask hit rate scalar output on the eye filter
<azonenberg>
(Which is probably not being displayed in the old scopesessions because that output didnt exist at the time)
<d1b2>
<johnsel> and to be sure, that's the only usage of cairo right now?
<azonenberg>
Correct
<azonenberg>
But yeah RenderInternal is never drawn for display
<d1b2>
<johnsel> the rendering is done separately? Not off the cairo context?
<azonenberg>
We used to have RenderForDisplay and RenderInternal
<azonenberg>
Correct
<d1b2>
<johnsel> Alright, understood
<azonenberg>
In glscopeclient we had one render function that did color and alpha blending for display (in cairo, then to a GL texture which got blitted over the eye)
<d1b2>
<johnsel> Yes that threw me off, void EyeMask::RenderForDisplay( still exists
<azonenberg>
and another that did B&W for mask pass/fail testing
<d1b2>
<johnsel> right right right
<azonenberg>
yeah thats dead code AFAIK
<d1b2>
<johnsel> so you refactorered that not so cleanly
<azonenberg>
well no
<d1b2>
<johnsel> just call the internal function now
<azonenberg>
we deprecated glscopeclient
<azonenberg>
not all of the code that glscopeclient called got removed apparently :p
<azonenberg>
ng never used that function but it had to stay until gl was removed
<azonenberg>
so its not that i refactored uncleanly as the refactoring never took place
<d1b2>
<johnsel> right that's what I meant by did not refactor it very cleanly :p
<d1b2>
<johnsel> I mean you took the effort to point it to the internal function
<azonenberg>
both of them did afaik
<d1b2>
<johnsel> that counts as refactoring in my book :p
<azonenberg>
they called the same internal function and just had differnet cairo context config
<azonenberg>
but i could be wrong
<d1b2>
<johnsel> well if you're sure it's legacy code we can say you didn't refactor it instead of did a quick & dirty one
<d1b2>
<johnsel> haha
<azonenberg>
delete it and see if it still builds :p
<d1b2>
<johnsel> I'll clean it out then
<d1b2>
<johnsel> there's not refrences to it I saw just now
<d1b2>
<johnsel> is there something vaguely useful for plotting the hitrate?
<azonenberg>
drag from the output in the filter graph view and select "measure" in the popup menu
<azonenberg>
that hit rate is the only visible indication of the mask behavior
<d1b2>
<johnsel> aah nice
<d1b2>
<johnsel> it's a scalar
<azonenberg>
yeprealsitically i'd probably
<azonenberg>
realistically i'd probably draw the cairo-generated output to a file and your version
<azonenberg>
and if they're identical or nearly so call it good
<d1b2>
<johnsel> yeah I had vaguely hoped that that was possible with the graph but alas
<d1b2>
<johnsel> My first reaction is that data just doesn't exist in there becase this was made with an older version of ngscopclient. Could be wrong though
<d1b2>
<johnsel> Either way I feel like I am nlocked for the moment by this
<d1b2>
<david.rysk> @azonenberg what are your thoughts on disabling the annoying #pragma message from yaml-cpp by #define message(ignore) before including and #undef message after?
<d1b2>
<david.rysk> it gets really very annoying
Kerr has quit [Quit: Bye.]
<azonenberg>
not sure what message you're talking about as i dont see it on my gcc version?
<d1b2>
<david.rysk> it happens only on Windows due to this
<_whitenotifier-7>
[scopehal-apps] azonenberg 202cbb5 - Merge pull request #692 from d235j/find-all-fonts Find all fonts and provide a sorted list
<_whitenotifier-5>
[scopehal] azonenberg opened issue #859: socketcan: use SO_TIMESTAMPING and/or SO_TIMESTAMP if available to get more precise packet arrival time data - https://github.com/ngscopeclient/scopehal/issues/859