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
Degi has quit [Ping timeout: 272 seconds]
Degi has joined #scopehal
sgstair_ has joined #scopehal
sgstair has quit [Ping timeout: 268 seconds]
sgstair_ is now known as sgstair
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
ALTracer has quit [Ping timeout: 268 seconds]
bvernoux has joined #scopehal
Ekho has quit [Ping timeout: 256 seconds]
Ekho has joined #scopehal
<azonenberg> Ok so i think i'm going to be doing some work on the socketcan driver again to make it work with hardware timestamping
<azonenberg> And then I have to figure out a good way of fitting RF switch matricesm, optionally buffered, into the scopehal model
<azonenberg> in particular, there's two different types of device i need to consider
<azonenberg> the first is stuff like the switch matrix from minicircuits (on my shopping list but i dont have) which is basically a bunch of independent RF relays that let you route one of N ports to a common port, then often several copies of that circuit in one chassis
<azonenberg> The second is stuff like the trigger crossbar that are digital redrivers rather than relays
<azonenberg> in which case you often have config settings like input threshold and output drive level
<azonenberg> and you can have arbitrary topologies (e.g. one input routed to two outputs simultaneously)
<azonenberg> I'm wondering if it makes sense to expose each input and output of a switch matrix separately as a filter graph node
<azonenberg> and then let you just draw paths in the graph to configure the routing
<d1b2> <johnsel> I think that makes sense
<azonenberg> And then if the input or output is buffered
<azonenberg> the node would have properties for setting threshold/drive
<d1b2> <johnsel> The only problem would be if you’d try putting software filters in between
<azonenberg> That's handled by FlowGraphNode::ValidateInput()
<d1b2> <johnsel> You can consider a separate window for it
<azonenberg> ValidateInput on the node class would verify that the input was another port on the same switch matrix (and a valid source, e.g. if you have two 1:4 muxes in the same chassis its not valid to feed the input of one mux to the output of the other)
<azonenberg> So the graph would just not let you make the connection if it's not legal
<azonenberg> This is the same check we use to prevent you from passing, say, filter outputs to a trigger on an instrment
<d1b2> <johnsel> I think for clarity sake it can make sense to put it in a separate graph editor window
<azonenberg> So long term i want to support hierarchical graphs
<d1b2> <johnsel> But either works
<azonenberg> the grouping we have now is just the beginning
<d1b2> <johnsel> I like putting similar actions together, so software filters vs hardware routing I would probably split in separate windows
<azonenberg> Yeah we might support that eventually
<azonenberg> but i want to support mixing them eventually
<azonenberg> For example, suppose you have an i2c protocol decode
<azonenberg> and your scope has an i2c hardware trigger
<azonenberg> i want to allow you to route the output of the i2c scopehal filter block to the scope trigger
<azonenberg> which will, behind the scenes, configure the scope trigger with the same inputs, baud rate, etc as the software decode block
<azonenberg> its not literally running on the output of the scopehal filter but semantically, i think it makes sense to depict that way
<azonenberg> So for that sort of reason having everything in one graph makes sense
<azonenberg> Another thing i eventually want to support is "reference nets" in the graph editor
<azonenberg> basically, a purely-for-show line between a hardware output node and a hardware input node
<azonenberg> depicting an external cabled path
<d1b2> <johnsel> Yeah I don’t think it’s wrong, just a decision. Either works imo
<azonenberg> I dont yet know how i'll do it, but it's something on the distant radar
<azonenberg> also, not yet pushed/merged
<azonenberg> but i've started working on some "scopehal 101" tutorials for the manual, separate from the reference-type material we have now
<azonenberg> basically walking you through how to set up a session and do some basic config and analysis
<d1b2> <johnsel> Yeah that makes sense
bvernoux has quit [Quit: Leaving]