<azonenberg>
If this turns out to overcorrect it will be easy to just make it even skinnier next time
<azonenberg>
But i think this is good enough to order
<azonenberg>
In sim it's flat +- 1 dB to 3.35 GHz, then peaks at about +1.7 dB above nominal, ad 3.85 GHz, then falls off to -3 dB at 7.5 GHz. In reality the falloff will be faster, based on the measurements of the actual prototype
<azonenberg>
So i'm expecting around 4-5 GHz -3 dB BW
<azonenberg>
Which will make it a great pairing for my current scope
<azonenberg>
The +1.7 dB of peaking ignores dielectric and copper losses, so i expect IRL it will be flatter than this
<azonenberg>
It would be funny if it turns out the enig and fr408 losses actually null out the peaking and give me flatter response, lo
<azonenberg>
Red is circuit theory sim of that same design (no field solver geometry) using vishay s-parameters for the resistors, ideal transmission lines between resistors and for the tip needle, and extracted data from the test board for the GCPW
<azonenberg>
I think it's a pretty good fit out to 4 GHz or so, then it starts diverging for reasons i don't yet understand
<azonenberg>
Blue is the same as red, but with field solver sim of the proposed attenuator inserted between attenuator and GCPW
<azonenberg>
At this point, i expect actual board performance to be as close to blue as red is to pink
<wbraun>
Don't some scope probes use deposited films Azonenberg?
<wbraun>
Does that have significant performance advantages?
<azonenberg>
wbraun: if i had my way, and no limit on budget
<azonenberg>
i would make the attenuator a custom 1202 sized resistor on an alumina substrate
<azonenberg>
flip chip construction like the ones i use now, probably thin film nichrome, and laser trmmed just like the vishay ones
<azonenberg>
but with a long aspect ratio of 0802 or 1202 instead of 0402 to reduce the parasitic C between the terminals and flatten the response
<wbraun>
flip chip? Is the restive element on the bottom side of the chip?
<azonenberg>
Yes
<azonenberg>
the alumina is purely for support
<azonenberg>
the film and terminals are on the same side of the resistor and the end caps are not plated like a standard chip resistor
<azonenberg>
this cuts the parasitic C between terminals roughly in half and reduces ESL too
<azonenberg>
My only problem is the terminals are still too close together. They make a 500 ohm version but the shunt capacitance is way too high for it to be usefully flat
<wbraun>
it has an interested input section with lots of stub thingies
* azonenberg
looks
<azonenberg>
interesting, but yeah i cant see enough to know whats going on exactly
<azonenberg>
anyway another potential option, less accurate but cheaper, would be screen printed carbon ink
<azonenberg>
i looked into this, it was beyond my budget, so i didn't even bother figuring out tolerances etc
<wbraun>
would / could you screen print it directly on the PCB?
<wbraun>
I wonder if that can be lasered too
<azonenberg>
Yes. these are commonly used for stuff like rubber dome keyboards as a contact surface, as well as for resistors. I expect they are laserable
<azonenberg>
what vishay does uniquely vs most other thin film resistors, in the FC series, is trim from the edges vs notching it
<azonenberg>
So no big spikes w/ lots of L
<azonenberg>
Anyway, at this time i think i've optimized the attenuator as much as i can
<azonenberg>
the resistors are just about touching
<azonenberg>
the rolloff isnt too bad now and the rolloff completely cancels out the peaking from the 200 ohm resistor
<azonenberg>
which leaves me with the resonant spike from the tip
<azonenberg>
Which i'm hoping this filter will fix
<wbraun>
How much of this can be designed from first principles / maxwells equations and stuff and how much of it is bizarre things that only a field solver can figure out?
<azonenberg>
The spacing of the resistors is "as close as i can make it given mechanical constraints". there's like 100um between the component bodies
<azonenberg>
and i'm playing fast and loose with tolerances, if two adjacent R's both hit the upper bound of the tolerance band they will collide
<azonenberg>
i'm gambling most of them will be closer to the midrange
<azonenberg>
(mechanical not electrical tolerances)
<azonenberg>
and field solvers are just maxwell's equations
<azonenberg>
so it depends on how much time you have on your hands :p
<azonenberg>
The simulation i did is actually mostly circuit theory using ideal transmission line segments between measured S-parameters for the resistors and the GCPW
<azonenberg>
and an ideal line for the probe tip that i chose parameters for by starting with a closed form approximation for impedance of two cylindrical conductors, then tweaking to match the VNA data
<azonenberg>
The only field solver geometry in the latest design is the filter circuit
<azonenberg>
which is literally just a short length of mismatched line
<azonenberg>
Soooo hmm, terminology question
<azonenberg>
What would you call a class for something that takes in one or more scope channels and zero or more parameters, but doesn't necessarily have an output?
<azonenberg>
i'm trying to move some stuff from the "filter" class into a new base class that Filter and Trigger derive from
<azonenberg>
so i can use common UI code for configuring complex triggers like pattern/protocol triggers, and protocol decodes/filters
<azonenberg>
But first i have to come up with a name for it
<azonenberg>
Bird|otherbox lain wbraun monochroma any ideas?
<NeroTHz>
that is already a significant improvement on the first version you showed me
<azonenberg>
Red = simplified simulation of that same board, using Vishay S-parameters for the passives, ideal transmission lines for the stubs between them and the tip, and VNA data from an older prototype for the GCPW
<azonenberg>
Blue = same as red but with sonnet sim of the filter inserted
<azonenberg>
between attenuator and gcpw
<azonenberg>
It's +/- 1 dB flat past 4 GHz
<NeroTHz>
the prototype is without the filter right?
<azonenberg>
Prototype in pink has no filter, correct
<NeroTHz>
that looks promising
<NeroTHz>
you really are making progress with this thing
<azonenberg>
Red is simplified model of pink. Same circuit, just a low order model of it
<azonenberg>
vs experimental data
<azonenberg>
And blue is red plus the filter
<azonenberg>
The version of the filter i showed you before seems to have been a little too aggressive
<azonenberg>
this version has the width of the low-impedance section toned down from 800 to 600 um (50 ohm line is 300)
<azonenberg>
actually i think 310
<NeroTHz>
the good thing is that it means you are also pretty robust to manufacturing tolerance
<azonenberg>
Yeah. Also, all of these sims and prototypes are on FR408HR not RO4350B
<azonenberg>
i'm considering sticking with FR408HR for the next production probe batch, just paying for impedance control vs using a cheap fab
<azonenberg>
the rationale being that the high freq loss actually helps flatten the response
<azonenberg>
past 4 GHz or so, it will be lossier but that's not a huge problem given that the BW is rolling off for other reasons anyway
<azonenberg>
But i'll make that decision once i have experimental data from the next prototype
<NeroTHz>
I don´t think you should go to rogers
<NeroTHz>
FR408 seems to be good enough for this application
<azonenberg>
The kickstarter probes were RO4350B
<azonenberg>
and immersion silver
<azonenberg>
because i was trying to squeeze every bit of performance out to fight losses i didn't understand at the time
<NeroTHz>
no point going to the expense of rogers though, it´s a few GHz design that isn´t ultra-precision RF metrology or something
<azonenberg>
Now that i understand the three main mechanisms in play, i can engineer it to go lower cost
<azonenberg>
And yeah. I'm still using rogers for MAXWELL because that's a huge 19" rackmount mainboard
<azonenberg>
it's only high speed digital but i have some really long diffpairs and want to keep losses low
<azonenberg>
I've already done the math and the loss margins with 408HR were uncomfortably tight on the 40G pairs
<NeroTHz>
makes sense
<azonenberg>
also $2M of keysight gear, lol nice. Not a cart you want to stop suddenly :p
<azonenberg>
What is it?
<azonenberg>
scope? vna?
<azonenberg>
assuming scope since your vnas are all R&S?
<NeroTHz>
110 GHz scope + a very fast AWG that may or may not be officially anounced yet
<azonenberg>
Niiiice
<azonenberg>
also did you see the sims i ran yesterday showing those 3 main effects decomposed?
<azonenberg>
(i linked them in the channel but forgot if you were here or not)
<NeroTHz>
was just a demo unit though, unfortunatly we are not gonna get the 110 GHz one. probably the 70 GHz version. no dicking around with 1 mm connectors
<NeroTHz>
I saw some intermediates pass by
<NeroTHz>
with like just the filter giving you that 2 db attenuation?
<azonenberg>
First one is an ideal 450 ohm Zo probe across a 50 ohm line, vs the same probe with a tip needle consisting of 8.5mm of 226 ohm line (best experimental fit to measured data, after slightly tweaking a closed form approximation for the tip geometry - no 3d solver)
<NeroTHz>
interesting, you can really see how the partial effects influnece overall performance
<azonenberg>
Second one is ideal series string of 200-200-50 ohms vs adding 600um of 50 ohm line between them
<azonenberg>
third one is ideal series string vs using vishay s-parameters
<azonenberg>
And yeah. This was very eye-opening to me to decompose the individual things
<NeroTHz>
yeah I can imagine
<azonenberg>
on top of this you have standard frequency dependent losses in dielectric and conductors
<NeroTHz>
it is very interesting to see them so nice like this
<azonenberg>
yeah i had done field solver modeling before
<azonenberg>
then i made one portion at a time non-ideal to isolate the impact of it
<NeroTHz>
yeah, it´s nice to see that the math does work out in a sense
<azonenberg>
The resistor parasitics i already understood well, and had already modeled in isolation
<azonenberg>
The original design of the kickstarter probe, 100, 4*75, 50 ohms in series, was based on modeling of this sort
<azonenberg>
75 ohms is almost perfectly flat but has very slight capacitive peaking, 50 has rolloff due to ESL, and 100 and up have peaking due to the parallel C
<azonenberg>
this string is, in the absence of any stub between resistors, flat +/- 0.07 dB to 10 GHz
<azonenberg>
the problem is, it's physically impossible to manufacture
<azonenberg>
because that model assumes zero distance between ports of each resistor
<azonenberg>
and as near as i can tell, the ports are at the edges of the nichrome element on the resistor. Not the far sides of the gold pads
<azonenberg>
which gives you a minimum of about a 250 μm stub between the S2P port and the closest place you can put another component
<azonenberg>
My latest prototype has 600 μm of total stub length which makes the resistor bodies about 100 μm apart on average. I'm playing tight with mechanical tolerances, at the max material dimensions the components would physically intersect by a bit
<NeroTHz>
yeah, that is usually where the port edge is de-embedded to in these simulations
<azonenberg>
but i'm ok with binning resistors by physical size if i have to to make this work :p
<NeroTHz>
in these measurements*
<azonenberg>
since this design is SO sensitive to the stub length
<azonenberg>
i had like an extra 0.2 dB of loss in one sim when i added 100 μm of extra spacing between resistors lol
<azonenberg>
anyway i don't fully grok *why* those tiny stubs hurt my response so badly, since they're so short compared to lambda. But simulation and experimental data both agree that the effect is there
<azonenberg>
and then the final effect that i only started realizing was a problem very recently was the probe tip. It's a high-Z line which is actually i think a good thing
<azonenberg>
my gut feeling is that having tip Z >> 50 ohms means instead of getting a huge reflection off the 500 ohm probe resistor, i get a zero-length reflection right at the T junction, most of the power goes straight ahead and some is split off to the tip
<azonenberg>
then there's a second reflection ~8mm down off the tip
<azonenberg>
But it's actually less intrusive to the DUT than if that ~8mm stub were 50 ohms
<azonenberg>
you agree?
<NeroTHz>
Does sonet come with a ´equivalent model´ generator? it might be usefull to just look at getting you a equivalent model of both the resistors (from s-param) and the stubs, which might clarify the impact of the stub. and it´s the cascade effect that can make electrically small things have big impact
<azonenberg>
Vishay publishes equivalent models for the resistors
<NeroTHz>
yeah, I think that is true (the high-impedance line thing)
<azonenberg>
It's a series inductor of negligible value at these freqs
<azonenberg>
then an ideal R of the target value in parallel with 26.2 fF
<azonenberg>
The C is basically the only non-ideality that matters for my purposes
<azonenberg>
Anyway, going back to the tip
<azonenberg>
After thinking more, looking at S21 only, the tip is essentially a stepped impedance line
<azonenberg>
It's ~8.5mm long and i was thinking that i'd get a quarter wave null at about 8 GHz. Which is true
<azonenberg>
but it seems like i also get a resonant peak around 3.75
<azonenberg>
Which is what the (intentional) stepped line i added after the attenuator is intended to prevent
<NeroTHz>
I went on a trip last weekend with my gf
<azonenberg>
It feels like the whole west coat of the US is on fire. According to the latest map i saw from the EPA, the cleanest air *in the entire state* was "unhealthy for sensitive groups"
<azonenberg>
Most of the state ranged from "unhealthy" to "hazardous"
<azonenberg>
Hence going to the park in gas masks
<NeroTHz>
twas very much #JustEngineeringThings because we both decided going to the pumped hydro station was more interesting than the waterfalls nearby
<azonenberg>
Lolol
<NeroTHz>
damn, that is intense
<NeroTHz>
we spent more time looking at the 380 kV transformers than we did looking at the actual tourist attractions lol
<azonenberg>
Most of this is from distant fires, just blowing over on the wind, but there was a small fire maybe 50-100m across just a few miles from me, close to lain and monochroma
<azonenberg>
We got lucky and it was contained quickly - the winds were low so it spread slowly
<NeroTHz>
hopefully they get that under control, around here it is not too much in the news because we have our own local shitshows going on, but it´s quite crazy what is going on there
<azonenberg>
and a helicopter just happened to be going overhead when it started
<azonenberg>
they were flying back to base after dropping somebody off at the hospital across the water
<azonenberg>
and saw smoke, they had some extra gas so they got lower and investigated
<azonenberg>
then called it in
<azonenberg>
A couple of nearby houses were put on alert to be prepared to evacuate if it got out of control, but it never reached that point
<NeroTHz>
that heli saved a lot of people and money
<azonenberg>
Luckily there weren't too many other fires nearby so they were able to get lots of people to fight it. They had all 3 fire engines in the (small) city plus a couple more from neighboring cities
<azonenberg>
Yeah. Dumb luck
<azonenberg>
Apparently a bit of rain is supposed to come next week, which is very much needed at this point
<azonenberg>
i can't remember the last time it's rained more than a few drops. May? Early June?
<azonenberg>
Our summers are usually dry here but this one has been hotter and drier than normal
<NeroTHz>
around here news right now is mostly just about covid rates goign back up (schools just opened, so it´s kinda expected, the hope is that it can just be kept manageable so schools can stay open) and a celeberty-naked-pictures-scandal
<azonenberg>
lol
<azonenberg>
yeah schools around here are i believe remote the rest of the calendar year
<azonenberg>
then they'll decide what the plan is for the spring half
<NeroTHz>
makes sense
<azonenberg>
i'm doing a remote first aid refresher this weekend too that would normally have been in person. It's good to get some practice in, but hard to really drill on a lot of this stuff without a patient you can touch
<NeroTHz>
here a lot of child psychologists are saying that the damage to kids of not having healthy social contacts for such an extended period of time could really ´damage´ them for life, far more so than adults
<azonenberg>
my wife is gonna be sick and tired of me taking vital signs and bandaging her by the end of it
<azonenberg>
lol
<NeroTHz>
haha I poor her ;p
<azonenberg>
and yeah it definitely is going to have significant long term fallout. Both emotionally and at a more high level societal level
<NeroTHz>
don;´tknow where that ¨I¨ came from in my last message
<azonenberg>
one thing i suspect is that a lot of companies will realize the majority of their work can be done remotely just fine, they already have the kinks worked out
<azonenberg>
and they just won't go back to the office, ever
<azonenberg>
or they will at a much reduced scale
<NeroTHz>
yeah, indeed. Children really need social contacts to develop their social skills, and taking that away from them for a year is going to have huge effects I think
<NeroTHz>
but indeed, for a lot of companies this has been a great ´forced test´ of remote working
<NeroTHz>
so in that regard I think almost all companies will embrace remote working more than ever
<azonenberg>
I further suspect that this might lead to a more general migration away from urban areas for two reasons
<NeroTHz>
which is nice
<azonenberg>
1) covid has shown how vulnerable they are to disease spread, lots of peopel in close proximity
<azonenberg>
and 2) many people like myself only live in/near cities because they are forced to do so in order to access employment
<azonenberg>
remove that restriction and i suspect a fair number of people will move to more rural locations
<NeroTHz>
Iḿ not 100% sure on that last part, I think while there will be more remote work, there will still be forced local work
<azonenberg>
not that i personally will be moving, i've spent way too much money and time on this lab already. But if this had happened five years ago
<azonenberg>
and of course, it's not going to be the end of cities
<azonenberg>
but my thought is, most tech/knowledge work can be done remotely, obviously with exceptions for stuff requiring access to lab facilities
<NeroTHz>
I do think it will help a lot with travel time, I really notice how there is just less traffic because lots of people work from home
<azonenberg>
retail, healthcare, etc can be done anywhere there are people aka customers
<NeroTHz>
while it can physically be done remotely, I notice myself that I´m far more productive when I can talk to colleagues in person a lot
<azonenberg>
My ideal is having a physical workplace available here and there. I'd routinely be at work physically and IMing a colleague in the next room
<azonenberg>
because neither of us needed to get up from our desks to discuss it
<NeroTHz>
so I don´t think switching to a full-remote thing is a great idea, at least for me
<azonenberg>
It's nice to see people over lunch etc, but it doesnt impact productivity a ton
<azonenberg>
Yeah it's very much person/job specific
<NeroTHz>
it does for me personally
<azonenberg>
I honestly find that physical access to coworkers creates more temptation to socialize rather than getting the job done
<azonenberg>
lol
<NeroTHz>
true, but I think that is good sometimes
<azonenberg>
Yeah
<NeroTHz>
I notice this - while when I´m at work I socialize more, I also notice that when I do work I´m more effective, and I get stuck on problems far less because I can just go bother a colleague and ask them, bounce ideas off of them, etc
<azonenberg>
Makes sense
<NeroTHz>
so the hours I do work are more efficient, and the net-result is that I get more actual work done (but again, this is gonna be different for everyone)
<azonenberg>
I guess it also depends on the company/facility. In my case $dayjob is a consultancy and different people are often working on different projects, so there's relatively few people at the office to physically collaborate with on a given project
<azonenberg>
we're also a global company and very often i'm partnered with a manager in another state and another engineer in a different country or something
<azonenberg>
So me being at home or in seattle when the manager is in virginia, my coworker is in madrid, and the customer is in georgia doesn't really change how we communicate
<NeroTHz>
it´s not really that different for me thouhg, we pretty much all work on our own little projects and research. In fact it´s rather odd that my specific project has more than 1 person actively working on it, and even then it´s isolated - one guy does chip design, I do antenna design/pcb design, etc
<NeroTHz>
indeed, then it makes little difference for you
<azonenberg>
Where being in the office *is* valuable for me is helping to train the more junior folks
<azonenberg>
showing them hands on lab skills etc
<azonenberg>
That's hard to do remotely
<NeroTHz>
indeed
<NeroTHz>
I´m myself working with the local lab manager to really overhaul the lab work flow, better train juniors, do some lectures on techniques, etc
<azonenberg>
Yeah i'm working on doing that at $dayjob too. We lost a bunch of senior folks and have a lot of newer people that need to be brought up to speed
<azonenberg>
so i've done a lot of remote trainings but there's a ton of stuff that you really have to get hands on to do
<NeroTHz>
yeah, there is stuff you just can´t quite explain without showing it and having others touch/hold
<azonenberg>
Yeah agreed
<azonenberg>
I'm looking forward to being able to do training sessions and hackathons outside of work
<azonenberg>
i actually have a conference/classroom space set up in my house that was intended for doing this
<NeroTHz>
indeed. We still have quite a few training sessions but it´s harder to set up and smaller groups
<azonenberg>
There's no projector yet although i have the computer and screen
<azonenberg>
there will eventually be a whiteboard behind it so i can roll it up and draw stuff, or pull it down and project
<azonenberg>
then more whiteboards are already on the shorter walls to the sides
<NeroTHz>
I have started to prefer glassboards over whiteboards, but glassboards are a bit more expensive and more finiky with respect to markers
<azonenberg>
The intent is to be able to do small group training/tutoring here, doing lecture/discussion stuff in here and then moving to the lab for hands on
<NeroTHz>
oh and glassboards are a disaster if you want to take a picture of what is on them lol
<NeroTHz>
I would suggest a slight table-upgrade too ;p
<azonenberg>
These are high end, porcelain coated steel i believe
<azonenberg>
and i might do a small upgrade but i also wanted to get a small couch in here so me and my wife could watch movies on the projector screen
<azonenberg>
the plan was to have it be reconfigurable as a conference room, classroom, or media room depending on the needs
<azonenberg>
So a folding table is nice because it gets out of the way easily
<NeroTHz>
that makes sense.
<NeroTHz>
my experience is just that folding tables aren´t very rigid and move around a lot
<azonenberg>
Yes, it's not super rigid. But that's the price you pay for reconfigurability
<azonenberg>
it's not something you'd be using for precision work
<azonenberg>
That will be in the lab
<azonenberg>
Those tables are 3mm thick steel plate tabletops and are rated to hold something like a thousand kilos each
<azonenberg>
They are "folding" in that if you remove a couple of bolts the legs do fold up
<azonenberg>
But when opened up and secured, they do not move
<NeroTHz>
hmm that is nice
<azonenberg>
I've climbed on them while pulling cables in the overhead tray
<azonenberg>
No perceptible motion
<azonenberg>
i can lean on the table while looking under a microscope and not see significant motion either
<azonenberg>
they're quite heavy especially with equipment on tip which provides good passive vibration damping
<NeroTHz>
ok, then they are a lot more sturdy than the similar style of table I´m familiar with
<NeroTHz>
I´m used to them shaking and moving all around whenever you look at them the wrong way
<azonenberg>
if i grab them firmly and shake hard with both hands, the solvent bottles slosh around a little bit
<azonenberg>
But i have to be actively trying to shake it
<azonenberg>
is this heavier construction than the tables you're used to?
<azonenberg>
(The fact that i have a 16U rack full of test equipment on top of each one probably helps stabilize it too)
<NeroTHz>
yeah it is
<NeroTHz>
it looked like those fold-up camping tables
<azonenberg>
The one in the classroom is
<azonenberg>
The lab tables are far more solid
<azonenberg>
NeroTHz: btw i'm puzzling over what to call a component in scopehal, looking for ideas
<azonenberg>
It's an entity in the library that can accept one or more instrument channels as inputs, as well as zero or more scalar configuration values
<azonenberg>
Trigger and Filter will both be derived from it
<azonenberg>
The rationale being, i want to use the same user interface code for setting up pattern/protocol triggers as i already have for protocol decodes/filters
<azonenberg>
So a Filter is a whatever-we-call-it that outputs a new waveform
<azonenberg>
a Trigger has no outputs and is fed to an Oscilloscope to configure the acquisition
<azonenberg>
but both are conceptually still "something that has channels and configuration settings"
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+2/-0/±4] https://git.io/JU8fu
<_whitenotifier-f>
[scopehal] azonenberg 946189e - Refactoring: moved a bunch of common functionality from Filter class to new FlowGraphNode class
azonenberg_work has quit [Ping timeout: 260 seconds]
azonenberg_work has joined #scopehal
juli965 has joined #scopehal
DanRoh has joined #scopehal
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]
maartenBE has quit [Ping timeout: 260 seconds]
maartenBE has joined #scopehal
<azonenberg>
noopwafel: ping
<azonenberg>
And anybody else i guess... i'm thinking more about the object model for triggers and such
<azonenberg>
So my plan is, FlowGraphNode is the highest level base class. It represents any entity in the flow graph that can accept inputs from scope channels
<azonenberg>
Filter inherits from FlowGraphNode, then all protocol decodes, math functions, and other filters inherit from Filter
<azonenberg>
Statistic inherits from FlowGraphNode and then has AverageStatistic, MinimumStatistic, etc derived from it
<azonenberg>
Finally, Trigger inhertis from FlowGraphNode
<azonenberg>
but there are also multiple levels of hierarchy here
<azonenberg>
In particular, EdgeTrigger represents a rising/falling/any edge
<azonenberg>
But I'm thinking that many other classes will inherit from that
<azonenberg>
for example, a PulseWidthTrigger makes sense to inherit from EdgeTrigger since it's looking for multiple edges with a min/max delay between them
<azonenberg>
We can then have the UI code for the draggable trigger level arrow just check for any EdgeTrigger and not care about what type it actually is
<azonenberg>
thoughts?
<electronic_eel>
how would a protocol specific trigger be hooked into this? like a triggering on a i2c address or something like that
<azonenberg>
electronic_eel: It would be a new class derived from Trigger
<azonenberg>
Since Trigger inherits from FlowGraphNode you can use the same auto-generated dialog like you would for a filter to hook up arbitrarily many trigger inputs and configuration settings
<azonenberg>
How you access that dialog is still up in the iar, i need to think about the best UX for that
<azonenberg>
in the air*
<azonenberg>
The plan is to rip out all of the current triggering APIs in Oscilloscope and instead just have a SetTrigger function that takes a polymorphic Trigger* instance
<azonenberg>
it will then use RTTI to figure out what you gave it
<azonenberg>
and send the appropriate instrument specific commands
<electronic_eel>
the FlowGraphNode, is it limited to one channel or one instrument, or can it cover multiple channels over multiple instruments?
<azonenberg>
A FlowGraphNode accepts one or more StreamDescriptors
<azonenberg>
a StreamDescriptor is an OscilloscopeChannel and a stream index (normally zero for hardware acquisition channels, but can be nonzero in special cases like an I/Q channel on a SDR)
<azonenberg>
An OscilloscopeChannel describes a single channel and points back to the instrument it's part of
<azonenberg>
A FlowGraphNode has a ValidateInput method that checks if a given StreamDescriptor is legal to use as an input. This can include verifying type, e.g. it's not sane to use an eye pattern as the input to an I2C decode
<azonenberg>
or verifying that the source of a trigger is a physical input rather than a filter
<azonenberg>
Or verifying that all inputs to a trigger came from the same instrument
<azonenberg>
the configuration dialog only shows legal inputs for each filter input, so the dropdown for different inputs may have different items in it
<azonenberg>
Additionally, a FlowGraphNode accepts zero or more FilterParameter's (to be renamed soon probably, since they're not just for filters anymore)
<azonenberg>
This is a scalar variant type which consists of a type, a unit, and a value
<azonenberg>
so for example you can have a float that measures volts, or an int that measures Hz, or a unitless boolean, or a filename, or an enum
<azonenberg>
So EdgeTrigger has a single channel input "in", and a single parameter "type" which is an enum {rising, falling, any}
<azonenberg>
as well as a parameter "level" which is a float in volts
<electronic_eel>
is one "value" enough? an address or byte pattern to search for could be a small array or similar
<noopwafel>
I'm kind of assuming that would be a valid type
<noopwafel>
since filename was an example
<noopwafel>
the StreamDescriptor is nice
<noopwafel>
I like
<electronic_eel>
that would be a string. not all addresses are nicely encoded as strings
<noopwafel>
so one of my examples was: boolean combinations of triggers
<noopwafel>
my thought was to implement this as a Trigger which had a bunch of Trigger children
<noopwafel>
but then the parent Trigger would *not* have any StreamDescriptor
<azonenberg>
actually "array of file names" is even a valid parameter type
<azonenberg>
noopwafel: It's legal to have a FlowGraphNode that happens to not have any inputs
<noopwafel>
but making it 'zero or more StreamDescriptors' would fix this
<azonenberg>
it's a vector which can be empty
<noopwafel>
ok, cool
<azonenberg>
but yes for complex pattern triggers i expect we'd have one trigger object that described a combinatorial operator of some sort
<azonenberg>
and then one for each of the sub-conditions
<azonenberg>
same for sequence trigger
<azonenberg>
lecroy lets you have a trigger that arms on condition 1 and executes on condition 2
<azonenberg>
it actually allows up to 4 stages
<azonenberg>
The complex part is there's limitations on what you can put in each stage. it looks like you cannot use protocol triggers for example
<azonenberg>
in a multistage trigger
<noopwafel>
mm, you'd have to have a way to add limitations or something
<azonenberg>
Yeah
<noopwafel>
I guess generally: the driver is going to have to feed info back to the UI
<azonenberg>
well i alredy have the ValidateInput method
<azonenberg>
so most likely what i'm going to have to do is, for the complex trigger types like pattern/sequence, create one base class that is used to set up the UI but can't be instantiated
<azonenberg>
then a derived class LeCroySequenceTrigger, say, which overrides ValidateInput() to only allow legal triggers for each stage
<noopwafel>
I was going to say, can you make the driver be a factory for these
<azonenberg>
So i'm still working out the object model
<noopwafel>
I think that would be flexible enough
<noopwafel>
right, just trying to think along :)
<azonenberg>
One of the unsolved problems is how to decide how to create triggers
<azonenberg>
Here's my thoughts so far
<azonenberg>
There will be a name-to-instance factory pattern like i have for filters, drivers, and transports (speaking of which i want to try refactoring that out to a common base class)
<azonenberg>
DynamicCreatable or something, idk
<azonenberg>
anyway, then each driver will have a method that returns a list of trigger types yo ucan use with it
<azonenberg>
which the UI will use to populate a dropdown in the config dialog
<azonenberg>
That much i am sure of
<azonenberg>
the tricky part is the compositions of multiple triggers
NeroTHz has quit [Read error: Connection reset by peer]
<azonenberg>
let's say LeCroyOscilloscope reports SequenceTrigger as a legal type, how do i know that this SequenceTrigger can accept a level or width trigger but not an I2C trigger in the first stage?
<noopwafel>
obvious approach is to have the same 'list of trigger types' on a combination-trigger object?
<azonenberg>
while say in MAXWELL, the same SequenceTrigger might be fine with I2C in the first stage
<azonenberg>
So i think there will have to be multiple levels going on for composited triggers
<azonenberg>
a base class that's just an interface the UI understands
<azonenberg>
and a derived class for the specific instrument
<azonenberg>
that adds the relevant limitations
<azonenberg>
So LeCroyOscilloscope will report LeCroySequenceTrigger as a possible trigger type
<noopwafel>
I was assuming that most drivers would create a derived class for most things
<azonenberg>
which knows that I2CTrigger is not a legal input to the first stage
<azonenberg>
But the glscopeclient UI just knows LeCroySequenceTrigger is a SequenceTrigger
<noopwafel>
makes sense
<azonenberg>
and uses ValidateInput() on that trigger to figure out what partiuclar inputs are legal for it
<azonenberg>
So i think that's the model i'm going to do, just have to work out some implementation details
<azonenberg>
I'm starting out with simple edge and pulse width triggers
<azonenberg>
and i'll implement all of that and see how the model "feels"
<azonenberg>
Do you folks agree that this is a logical next step?
<azonenberg>
in terms of the overall progression of the software i mean
<azonenberg>
advanced triggering is definitely a big hole
<noopwafel>
I think definitely good to try implementing it, if you have the cycles, and this generally sounds workable to me
<azonenberg>
the other big item on my list as far as missing features is timebase/trigger offset
<azonenberg>
right now there is no way to control when in the acquisition the trigger happens
<azonenberg>
there actually is a method in Oscilloscope for it
<azonenberg>
but no UI to call it
DanRoh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]