<d1b2>
<copper280z> I have a potentially silly question, how do I delete nodes in the filter graph (on a mac)?
<d1b2>
<azonenberg> RenderForAnalysis is the only one that's ever called
<d1b2>
<azonenberg> RenderForDisplay is dead code left over from glscopeclient
<d1b2>
<azonenberg> guess we never got rid of it
<d1b2>
<azonenberg> RenderForAnalysis draws to an offscreen buffe
<d1b2>
<azonenberg> buffer*
<d1b2>
<azonenberg> You don't. As of now, filter nodes are reference counted, when the last reference goes away they vanish. if you have any other filters using the output or any views displaying them, etc, they'll persist
<d1b2>
<azonenberg> sometimes we leak references and they become undeletable, there are known bugs around this
<d1b2>
<azonenberg> A major refactoring to fix this is planned
<d1b2>
<johnsel> okay so it's just draw some polygons, analyze them, and that is it
<d1b2>
<johnsel> real drawing is already done via Vulkan through some whatever
<d1b2>
<johnsel> that's about what I got from David but he's out partying for the next hour still or so
<d1b2>
<johnsel> his answers were a little vague lol
<d1b2>
<johnsel> but makes sense
<d1b2>
<johnsel> where would you prefer the new dependency @azonenberg it's just a single header file and some unit tests
<d1b2>
<azonenberg> correct
<d1b2>
<azonenberg> make a contrib directory for it if we dont have one, i guess?
<d1b2>
<copper280z> Got it, thanks!
Degi has quit [Ping timeout: 246 seconds]
<d1b2>
<azonenberg> The long term plan is to have bidirectional reference tracking (so each node knows not only where its inputs come from, but who is consuming its output)
Degi has joined #scopehal
<d1b2>
<azonenberg> which will enable you to simply delete a node on cue by telling each consumer "sorry, i'm going away" and disconnecting those inputs
<d1b2>
<copper280z> That sounds like a nice change, but also potentially annoying to implement. 🙂 I have another question, unrelated to that. Using the csv stream driver to get data from orbcat via netcat, it seems like scopehal isn't consuming the data as fast as it's coming in, and something (netcat?) is buffering. Leading to the displayed data being up to several minutes old, if I run for long enough. I haven't tried socat yet, so maybe that works
<d1b2>
better?
<d1b2>
<azonenberg> How fast are you pushing data
<d1b2>
<azonenberg> ?
<d1b2>
<azonenberg> The filter graph currently cannot run more than one iteration per display frame (architectural limitation we plan to eliminate eventually) in ngscopeclient, although if you are running headless in your own raw C++ it can be as fast as you want
<d1b2>
<azonenberg> So you can't pull more than 60 updates per second on a 60 Hz monitor from an instrument
<d1b2>
<azonenberg> For now, unless you need very high rate streaming, you're probably best off rate limiting in your firmware
<d1b2>
<azonenberg> (if you do, you might be better off thinking of your data source as an oscilloscope not a scalar data source)
<d1b2>
<azonenberg> Which comes with a different driver model that captures blocks of data rather than single values, and is limited (in the current architecture) to $videoframerate blocks per second rather than samples per second
<d1b2>
<azonenberg> (blocks can be arbitrarily large, limited only by the 4GB Vulkan memory allocation cap and your available VRAM)
<d1b2>
<johnsel> we have src/imgui for scopehal-apps
<d1b2>
<azonenberg> That's a submodule though
<d1b2>
<azonenberg> i figure having one contrib directory for anything we're going to just import
<d1b2>
<azonenberg> or did you plan to submodule it?
<d1b2>
<johnsel> up to you really
<d1b2>
<johnsel> I can see value in submoduling it
<d1b2>
<azonenberg> if the lib is decently large or we might want to update in the future i say submodules, we already use them heavily
<d1b2>
<azonenberg> i mostly vendor trivially tiny things like the base64 coder
<d1b2>
<johnsel> it is going to be used by scopehal though
<d1b2>
<azonenberg> So submodule in scopehal
<d1b2>
<johnsel> it only has vkftt, log and xptools as submodules
<d1b2>
<johnsel> we could introduce it as another
<d1b2>
<johnsel> it's a pretty small lib though, header file only
<d1b2>
<johnsel> we could grab a copy and dump it somewhere too
<d1b2>
<azonenberg> yeah submodule it for now
<d1b2>
<johnsel> though we have no place for that either
<d1b2>
<johnsel> understood
<d1b2>
<johnsel> I didn't get very far though today
<d1b2>
<johnsel> but will try to get back to it this week
<d1b2>
<johnsel> at least I understand the code now
<d1b2>
<johnsel> I also made some tickets for docs not doing what they should
<d1b2>
<johnsel> so we're getting those more up to date if/when someone picks them up
<d1b2>
<johnsel> I wanted to move on to cairo first though
<d1b2>
<johnsel> if nobody picks it up I will myself
<d1b2>
<johnsel> but maybe we have someone with extra time on their hands willing to do some easy work
<d1b2>
<azonenberg> Yeah docs need a lot of updating
<d1b2>
<azonenberg> i need to redo a lot of screenshots with recent UI changes
PlasmaHH has joined #scopehal
<PlasmaHH>
Hi, went through the docs but got a bit overwhelmed, found nothing but thought maybe I missed it: with ngscopeclient can I (out of the box) fully decode (pam3 -> 4bt3 descrambling -> ethernet frames ) 10base-t1l / apl data?
bvernoux has joined #scopehal
<d1b2>
<azonenberg> Not currently. We have decoding for 10baseT, 100baseT1 (given a directional coupler to split the tx and rx paths), 100baseTX, 1000baseX, and 10GbaseR
<d1b2>
<azonenberg> i don't have any 10baseT1L hardware to get test waveforms from
<d1b2>
<azonenberg> if you file a ticket on the tracker as a feature request and send me waveform data as a scopesession, I'll see what I can do
<azonenberg>
PlasmaHH: (whoops i thought you were messaging from the discord side at first)
<azonenberg>
anyway, you do need to split the tx/rx paths in hardware for the data to be useful
<azonenberg>
what's your measurement setup look like?
<PlasmaHH>
azonenberg: yeah, directional coupler etc.... I have not yet any measurement setup, can select from a few tek scopes or picoscope or rigols ... generally at the very start of thinking about it
<d1b2>
<copper280z> I’m not exactly sure how fast, but probably at least 50kHz. The firmware right now is just a tight loop that pushes out a sine/cosine waveform. I misunderstood the implications of scalar data, I assumed no buffering would ever happen, and it would pick the most recent value. An oscilloscope model is definitely a better match for this sort of case. I already looked at the demo oscilloscope driver and I think I can put something
<d1b2>
together, I’ll give it a shot and see.
PlasmaHH has quit [Ping timeout: 252 seconds]
PlasmaHH has joined #scopehal
<d1b2>
<bvernoux> Yes we can plan a chat on IRC or Here in PM
<d1b2>
<david.rysk> I’m around but kinda busy. Chatted a bit with @johnsel about this and there are two outstanding concerns prior to packaging: 1. Cairo, since it pulls in a lot of sub dependencies that are annoying to package correctly 2. Path handling for resources which are needed at runtime
<d1b2>
<azonenberg> so we don't buffer in scopehal
<d1b2>
<azonenberg> but if there's buffering in orbcat or the socket or something en route to the csvstream driver
<d1b2>
<azonenberg> it's only going to get popped as fast as we query
<d1b2>
<azonenberg> you could absolutely write a "flushing csvstrean" driver easily that would sit in a loop and pop data as long as it can find any each AcquireData() call
<d1b2>
<azonenberg> and return once it stops getting data or something
<d1b2>
<copper280z> Got it, I suspected that, and tried to turn off buffering at the pipe, but my bash isn’t all that strong so I’m not sure it actually did what I thought. 😅
<d1b2>
<azonenberg> Yeah if you write data to a pipe it has to go somewhere
<d1b2>
<azonenberg> the proper fix for your use case i think would be to explicitly make the driver throw away inbound data every read call
<d1b2>
<azonenberg> I actually wonder if that makes sense to do in the vanilla csvstream driver
<d1b2>
<azonenberg> since this is the main intended use case
<d1b2>
<azonenberg> File an issue for it and we can discuss
<d1b2>
<copper280z> Will do, might be in a few hours though.
<d1b2>
<copper280z> Thanks!
<d1b2>
<azonenberg> No rush i have a lot to catch up on anyway since i've been busy at $dayjob this week
<_whitenotifier-1>
[scopehal-docs] Johnsel opened issue #87: Documentation: Ubuntu and Debian HTML pages have double line breaks so apt-get install x \ ... (next line) is treated as a new command, which fails - https://github.com/ngscopeclient/scopehal-docs/issues/87
<d1b2>
<david.rysk> #72 was fixed for me, I was hoping that @svenpeter42 could retest 🙂