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