azonenberg changed the topic of #scopehal to: ngscopeclient, libscopehal, and libscopeprotocols development and testing | https://github.com/ngscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
<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
<d1b2> <david.rysk> yup
<d1b2> <david.rysk> also there's packaging
<d1b2> <johnsel> chip packaging is also pure magic
<d1b2> <johnsel> extremely exotic materials
<d1b2> <johnsel> but, @david.rysk
<d1b2> <johnsel> etc, you get the idea
<d1b2> <david.rysk> is msys2 installed / set up on this computer?
<d1b2> <david.rysk> I did not finish the packaging part, so builds will not be portable at the moment
<d1b2> <johnsel> yes, but it's not added to PATH I think
<d1b2> <johnsel> alright
<d1b2> <johnsel> it's on your radar though then?
<d1b2> <david.rysk> yeah
<d1b2> <johnsel> oh, @azonenberg found something you love
<d1b2> <johnsel> ERROR: Invalid channel name "data" in FlowGraphNode::SetInput() ERROR: Invalid channel name "data" in FlowGraphNode::SetInput() Assertion failed: node != __null, file C:\msys64\home\jamms\scopehal-apps\src\imgui\imgui.cpp, line 16007 Segmentation fault
<d1b2> <johnsel> reproduction: Open scopehal-testdata/pc/PCIe.scopesession offline twice in the same session
<d1b2> <johnsel> @azonenberg another bug
<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
<_whitenotifier-7> [scopehal-apps] MaxBareiss starred scopehal-apps - https://github.com/MaxBareiss
<d1b2> <johnsel> alright yeah with the understanding that there is no need to render anything even nothing but a software floodfill makes sense
<d1b2> <johnsel> I thought it was still rendering as well
<d1b2> <david.rysk> Ahhh I was under the same impression
<d1b2> <johnsel> hmm doesn't seem to get called even it seems
<d1b2> <johnsel> printf should work right?
<d1b2> <johnsel> @azonenberg quick ping
<d1b2> <johnsel> sorry I know you have told me all this already before and I should have made notes
vup2 has joined #scopehal
Degi_ has joined #scopehal
josuah has quit [Ping timeout: 264 seconds]
Degi has quit [Ping timeout: 264 seconds]
vup has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
<_whitenotifier-7> [scopehal-apps] rgov edited issue #621: macOS: Build with Homebrew-provided Vulkan dependencies - https://github.com/ngscopeclient/scopehal-apps/issues/621
<_whitenotifier-5> [scopehal-apps] rgov edited a comment on issue #621: macOS: Build with Homebrew-provided Vulkan dependencies - https://github.com/ngscopeclient/scopehal-apps/issues/621#issuecomment-1939713893
<d1b2> <johnsel> ok so more important than my debugging debacles (which I think I have under control now) is that I never get back a hitrate at all
<d1b2> <johnsel> always
<d1b2> <johnsel> Could you get/send me an offline BERT session?
<d1b2> <johnsel> I think that's the only thing that still triggers any functions in this class
<d1b2> <johnsel> and
<d1b2> <johnsel> if there is a yaml file attached to it?
<d1b2> <johnsel> You'd have to guide me a little here as I have no BER, and no YAML mask files either
<d1b2> <johnsel> right now the values are 0
<d1b2> <johnsel> data also seems empty
<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
<_whitenotifier-7> [scopehal] rgov opened issue #858: BK Precision 9103 power supply - https://github.com/ngscopeclient/scopehal/issues/858
<_whitenotifier-5> [scopehal] rgov edited issue #858: BK Precision 9103 power supply - https://github.com/ngscopeclient/scopehal/issues/858
<_whitenotifier-5> [scopehal] rgov edited issue #858: BK Precision 9103 power supply - https://github.com/ngscopeclient/scopehal/issues/858
<_whitenotifier-5> [scopehal] rgov edited issue #858: BK Precision 9103 power supply - https://github.com/ngscopeclient/scopehal/issues/858
<_whitenotifier-5> [scopehal] rgov edited issue #858: BK Precision 9103 power supply - https://github.com/ngscopeclient/scopehal/issues/858
<_whitenotifier-5> [scopehal] rgov edited issue #858: BK Precision 9103 power supply - https://github.com/ngscopeclient/scopehal/issues/858
<_whitenotifier-7> [scopehal] rgov edited issue #858: BK Precision 9103 power supply - https://github.com/ngscopeclient/scopehal/issues/858
<_whitenotifier-7> [scopehal] rgov edited issue #858: BK Precision 9103/9104 power supply - https://github.com/ngscopeclient/scopehal/issues/858
<azonenberg> offline bert sessions are not possible
<azonenberg> We dont have the serialization for bert data yet
<azonenberg> we only save the config. there's an open ticket for that
<azonenberg> Any eye pattern with a mask attached should show a hit rate
<d1b2> <johnsel> I don't have a mask file
<d1b2> <johnsel> or way to attach it to the filter
<azonenberg> There are masks in the masks/ dir of ngscopeclient
<_whitenotifier-7> [scopehal] rgov edited issue #858: BK Precision 9103/9104 power supply - https://github.com/ngscopeclient/scopehal/issues/858
<azonenberg> just select in the filter properties
<d1b2> <johnsel> hmm I closed everything out but let me check real quick
<d1b2> <johnsel> interesting
<d1b2> <johnsel> it only fills the data when I attach a mask
<d1b2> <johnsel> I'll have to figure out a failing mask for this but that's fine
<d1b2> <johnsel> thanks
<azonenberg> yeah there should be enough masks to pick from that one of them will fail any waveform
<azonenberg> and yeah if there's no mask it can't compute a hit rate
<azonenberg> so it makes no sense
<d1b2> <johnsel> I can understand the hit rate having no data
<d1b2> <johnsel> but it's hit rate & data outputs
<d1b2> <johnsel> the data output doesn't produce any values either until there's a mask selected
<azonenberg> the data output is the eye pattern itself
<d1b2> <johnsel> yep I see
<azonenberg> And that should work fine with no mask
<d1b2> <johnsel> the period and bit rate threw me off
<azonenberg> ah ok
<d1b2> <johnsel> oh no
<d1b2> <johnsel> miscommunication
<d1b2> <johnsel> it's not output data
<d1b2> <johnsel> and yes it should just send the eye pattern through
<d1b2> <johnsel> but apparently it does not
<d1b2> <johnsel> you or I can take a look at it, whichever you prefer
<d1b2> <johnsel> I am going to slowly dig my nest for the night
Degi has quit [Ping timeout: 256 seconds]
<azonenberg> OK yeah not a rush i'll be WFH and can help you with it more tomorrow afternoon or something
Degi has joined #scopehal
<d1b2> <johnsel> sounds good
<_whitenotifier-7> [scopehal] rgov edited issue #858: BK Precision 9103/9104 power supply - https://github.com/ngscopeclient/scopehal/issues/858
<_whitenotifier-7> [scopehal] rgov commented on issue #858: BK Precision 9103/9104 power supply - https://github.com/ngscopeclient/scopehal/issues/858#issuecomment-1940378406
<_whitenotifier-5> [scopehal] rgov edited issue #858: Manson (BK Precision) power supplies - https://github.com/ngscopeclient/scopehal/issues/858
<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
<d1b2> <david.rysk> C:/msys64/ucrt64/include/yaml-cpp/dll.h:22:65: note: '#pragma message: Defining YAML_CPP_API for DLL import' 22 | # pragma message( "Defining YAML_CPP_API for DLL import" ) | ^
<d1b2> <azonenberg> ok yeah that needs to be shut up lol
<d1b2> <azonenberg> (also speaking of shutting up warnings can you make codeql ignore vkfft?)
<d1b2> <david.rysk> ah yeah I should be able to
<d1b2> <azonenberg> yeah theres a ton of warnings about it lol
vup2 has quit [Ping timeout: 255 seconds]
vup has joined #scopehal
Kerr has joined #scopehal
<_whitenotifier-5> [scopehal] azonenberg 3939cc3 - Complete rewrite of PAMEdgeDetector with simple 0.5 UI based edge merging
<_whitenotifier-7> [scopehal] azonenberg pushed 2 commits to master [+0/-0/±3] https://github.com/ngscopeclient/scopehal/compare/ff20047ae44b...2f041b548919
<_whitenotifier-7> [scopehal] azonenberg 2f041b5 - PAMEdgeDetectorFilter: handle edge detection for arbitrary order PAM
Kerr has quit [Quit: Bye.]
josuah has joined #scopehal
bvernoux has joined #scopehal
<_whitenotifier-7> [scopehal-apps] azonenberg closed pull request #692: Find all fonts and provide a sorted list - https://github.com/ngscopeclient/scopehal-apps/pull/692
<_whitenotifier-5> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-apps/compare/1c6923bd8f6b...202cbb5d6f20
<_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
<_whitenotifier-7> [scopehal] azonenberg commented on issue #858: Manson (BK Precision) power supplies - https://github.com/ngscopeclient/scopehal/issues/858#issuecomment-1942328679
Kerr has joined #scopehal
Kerr_ has joined #scopehal
Kerr has quit [Ping timeout: 264 seconds]
bvernoux has quit [Quit: Leaving]
Kerr_ has quit [Quit: No Ping reply in 180 seconds.]
Kerr has joined #scopehal
Kerr has quit [Client Quit]
Kerr has joined #scopehal
Kerr has quit [Ping timeout: 264 seconds]
<d1b2> <david.rysk> does anyone have a spare usb-gpib adapter lying around? 🙂
<d1b2> <johnsel> I don't, but I did find that siglent makes one for 150 bucks
<d1b2> <david.rysk> I can get NI ones for $50 off eBay
<d1b2> <david.rysk> (or so)
<d1b2> <johnsel> seems to be on the cheap end of them
<d1b2> <david.rysk> sure they're discontinued, but there's linux-gpib support and that's all I need
<d1b2> <johnsel> oh the siglent ones seem to be for controlling siglent devices in fact not to connect scpi to host
<d1b2> <johnsel> so they're useless
<d1b2> <david.rysk> I just want a generic gpib adapter for older devices
<d1b2> <david.rysk> like 1980s and 1990s stuff
<Darius> I have seen a cheap project to USBify GPIB instruments
<d1b2> <david.rysk> oh?
<Darius> I haven't had cause to use it myself but looks cheap to make and well executed
<d1b2> <johnsel> that's usbtmc based though
<d1b2> <johnsel> not linux-gpib
<Darius> johnsel: sure but I would argue that is better since I am not using linux ;)
<Darius> talking to USBTMC is pretty trivial IME
<d1b2> <david.rysk> aaahhh I'd probably need one of each then 😛
<d1b2> <david.rysk> seems we support USBT
<d1b2> <david.rysk> USBTMC already*
<d1b2> <johnsel> yes
<d1b2> <johnsel> Darius: it depends on why david wants it ofcourse
<Darius> yes of course
<d1b2> <johnsel> if you want to do linux-gpib driver support usbtmc is not very useful
<d1b2> <david.rysk> we have linux-gpib driver support but I want to be able to test it
<d1b2> <johnsel> that's what I guessed