nelgau has quit [Read error: Connection reset by peer]
nelgau has joined #scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
<lain>
heads up: azonenberg caught some kind of flu and is canceling the scopehal call tomorrow
<lain>
he asked me to announce it here because he’s too exhausted to get to his lab computer :<
<d1b2>
<johnsel> Oh damn
<d1b2>
<johnsel> Miek would you be willing your barebones driver. It’d be a great help for me having just a stripped down driver that I can understand quickly
<d1b2>
<johnsel> @hansem @david.rysk @aleksorsist see above notice by lain
<d1b2>
<johnsel> Hope I am not forgetting anyone
<d1b2>
<johnsel> @bvernoux
<d1b2>
<johnsel> @hansemro
<d1b2>
<hansemro> @louis8374
<d1b2>
<johnsel> Iirc he was out of town, thanks though
<d1b2>
<hansemro> @johnsel I could probably trim down the Siglent scope driver and share that if it helps.
<d1b2>
<miek__> I started by copy and pasting the agilent driver, so it's not that barebones. I'll push it up in a bit anyway, just in case it still helps
<d1b2>
<johnsel> That would be great for me & anyone else ever implementing a driver from scratch. It would be very much appreciated by me, and helps the Thunderscope project. Given enough time I can do it myself after figuring out what it really needs. The only driver I can work through it’s paces while stripping is the Rigol one which isn’t great
<d1b2>
<johnsel> And I still need to write the scpi server and litepcie integration as well
<d1b2>
<johnsel> All in all, the simpler my starting point the better
<d1b2>
<johnsel> Can you wish him a speedy recovery from me btw?
<d1b2>
<johnsel> Or make that us
<d1b2>
<louis8374> ^
<d1b2>
<louis8374> thanks for the heads up
nelgau has quit [Read error: Connection reset by peer]
nelgau has joined #scopehal
nelgau has quit [Read error: Connection reset by peer]
nelgau_ has joined #scopehal
nelgau_ has quit [Remote host closed the connection]
<azonenberg>
Welp, just woke up to grab food after being asleep pretty much all yesterday. Definitely not gonna be up for the dev meeting but hopefully we can reschedule for later in the week
<_whitenotifier-3>
[scopehal] azonenberg af44efc - Filter serialization now includes X/Y axis units (important for things like memory filter which would otherwise default to time/voltage upon loading)
nelgau_ has quit [Remote host closed the connection]
nelgau has quit [Ping timeout: 252 seconds]
nelgau_ has joined #scopehal
nelgau_ has quit [Remote host closed the connection]
nelgau has joined #scopehal
<d1b2>
<jdryg> Hello all. I'm trying to build my first filter for ngscopeclient and the m_parameters interface for configuring the filter looks a bit limited. Are there any plans to add support for custom filter UI in the future?
<d1b2>
<jdryg> I'm still getting familiar with the code. What I did was to add a virtual bool DoCustomParameterUI(ImGuiContext* ctx) to the Filter class and call it before displaying the default parameter UI (in FilterPropertiesDialog.cpp).
<d1b2>
<johnsel> The person to really answer this is not around today but perhaps you can start by explaining your ultimate goal, what do you need that is missing to implement what specifically?
<d1b2>
<johnsel> The reason I ask is because the current filter properties relate back to fairly optimized internal processing, and it's pretty flexible
<d1b2>
<jdryg> Here is what I ended up with. The Parameters UI cannot be built with the current interface. I was just wondering if there are plans to support something like that in the future. That's why I asked.
<d1b2>
<jdryg> The dummy parameter at the end is needed in order to force ngscopeclient to call the virtual function I added.
<d1b2>
<johnsel> @azonenberg happens to be working on a spectrometer so perhaps some of the functionality can be added that you want. What you've shown however has many patterns that aren't really compatible with how things work in ngscopeclient
<d1b2>
<jdryg> As I said I'm not yet familiar with the code so I don't know what kind of optimizations you are talking about, but it's a bit difficult to express such parameter grouping with a simple map<string, FilterParameter>.
<d1b2>
<jdryg> You are probably right. I saw the azonenberg's spectrometer work and that was the reason I wanted to try ngscopeclient. But my use case is probably not compatible with ngscopeclient as you said.
<d1b2>
<johnsel> Well the driver is still barebones, and some of the properties you added will likely become properties at the driver level (which then bubbles up to the GUI)
<d1b2>
<johnsel> and our start acquisition button is on the top left
<d1b2>
<johnsel> I'd suggest discussing your feature requests either on GitHub or with him directly when he is no longer sick
<d1b2>
<johnsel> I'm sure he's more than willing to engage with you to get our of ngscopeclient what you want
<d1b2>
<jdryg> This is not an SCPISpectrometer because I couldn't find a way to add configurations parameters to such a class. I ended up creating a filter (this is not an actual device driver, this is a theoretical reflectance/transmittance spectrometer).
<d1b2>
<johnsel> I'm sure it's possible to implement it properly, but slapping some buttons on the GUI won't work for us. You're free to fork and do things your way though
<d1b2>
<johnsel> I'd highly suggest you come back in a day or 2 when Andrew can tell you about how plans to integrate the spectrometer device type and where you best start hooking into some or another driver
<d1b2>
<jdryg> Thanks!
<d1b2>
<johnsel> You are welcome, sorry I couldn't be more helpful at this time
<d1b2>
<jdryg> I just tried to and it works! Thanks for that. I'll remove the Start Acquisition button from my UI. I added it because I didn't know how to force the app to call the filter's Refresh method.
<d1b2>
<johnsel> Alright, well a filter is still not supposed to be an instrument source but I think I made that point already
nelgau has quit [Read error: Connection reset by peer]
nelgau has joined #scopehal
nelgau has quit [Read error: Connection reset by peer]
nelgau has joined #scopehal
<d1b2>
<azonenberg> Yeah you can create filter-only sessions this way. as far as custom UI goes, thats an open somewhat tricky architectural problem
<d1b2>
<azonenberg> we are trying to avoid having any gui dependencies in libscopehal and libscopeprotocols
<d1b2>
<azonenberg> so they can be used in headless test code, or bespoke tools for an end user application that might not be using imgui
<d1b2>
<azonenberg> while i would love more flexible interfaces for parameters, i think the direction we're going to go is some kind of declarative data model that describes how the gui should be built
<d1b2>
<azonenberg> which is then synthesized into widgets by the frontend
<d1b2>
<azonenberg> That is probably not happening before the v0.1 release though
<d1b2>
<jdryg> Thanks for the clarifications. I didn't think about 3rd party apps using libscopehal/etc. You are right, that's an unnecessary dependency.
<d1b2>
<azonenberg> For historical background, originally we had scopeclient which was GTK based and all software rendering
<d1b2>
<azonenberg> then glscopeclient which was GTK based with some opengl and opencl acceleration (partially converted to vulkan shortly prior to its obsolescence)
<d1b2>
<azonenberg> and now ngscopeclient which is imgui + vulkan
<d1b2>
<azonenberg> all sharing the same backend and during the transition period, often we'd have two tools in active use before the new tool had the full feature set of the old one
<d1b2>
<azonenberg> There's actually still a little bit of Cairo code left over in eye pattern hit testing that we are looking to move away from to fully decouple the two
<d1b2>
<azonenberg> So yeah. a better UI config for parameters is nice, for example i'd like to be able to group parameters without having to display them in alphabetical order like we do now
<d1b2>
<azonenberg> but doing it right is nontrivial
<d1b2>
<johnsel> Do you see a way to pull out the data @jdryg wants using the existing architecture though?
<d1b2>
<johnsel> From what I see he’s not looking for much beyond what you’d expect from a spectrometer
<d1b2>
<azonenberg> it absolutely could be done with our current architecture, but not with such pretty grouping of parameters
<d1b2>
<azonenberg> you'd have a parameter for number of layers
<d1b2>
<azonenberg> then add a hook for that parameter being changed
<d1b2>
<azonenberg> and use that to add/remove the layer specific parameters
<d1b2>
<jdryg> AFAIK usually wavelength coefs are read-only (or should be treated as such in the majority of cases). Thus they are "information" about the spectrometer instead of a parameter.
<d1b2>
<johnsel> I more meant the actual spectrometer functionality aside from how it looks in the gui
<d1b2>
<azonenberg> oh. i mean, filters can output waveforms of arbitrary data types
<d1b2>
<azonenberg> i dont see that being an issue
<d1b2>
<johnsel> Sure but this should be an instrument first
<d1b2>
<azonenberg> So i dont think so, i see this in the same category as the waveform generation filters we use for channel modeling
<d1b2>
<azonenberg> e.g. you generate a PRBS, then convert to NRZ or PAM4, apply a channel model, etc
<d1b2>
<azonenberg> this is just the optical equivalent of the same thing
<d1b2>
<azonenberg> a filter makes sense for this
<d1b2>
<azonenberg> (see TouchstoneExportFilter handling of m_portCount)
<d1b2>
<azonenberg> the only physical control the Spectrometer class provides is integration time, which makes no sense for a simulated reflection model anyway
<d1b2>
<jdryg> It might make sense if you want to simulate a shutter or saturation (based on a maximum integration time). 🙂
<d1b2>
<johnsel> I may be mistaking what @jdryg is planning to do here since he combined much in one picture, but it seems he wants to use the filter as starting piont (i.e. insert the dat athere)
<d1b2>
<johnsel> not going through scpispectrometer as a first input
<d1b2>
<jdryg> My initial goal was to be able to use the rest of ngscopeclient's filters (FFT, averaging, etc.) for manipulating reflectance/transmittance spectra from various layer stacks.
<d1b2>
<azonenberg> and thats completely fine
<d1b2>
<johnsel> where does the data come from?
<d1b2>
<azonenberg> like i said we support filter-only sessions for creating synthetic data
<d1b2>
<azonenberg> we have a whole suite of filters for time domain waveform creation
<d1b2>
<johnsel> sure synthetic data creation (or import from file)
<d1b2>
<johnsel> not from some usb or scpi device
<d1b2>
<jdryg> In a real application the data would come from a reflectance/transmittance setup using real hardware. I was more interesting in easily developing algorithms for such cases without needing a real hardware setup.
<d1b2>
<azonenberg> exactly
<d1b2>
<azonenberg> it sounds like he's creating a synthetic data source that outputs spectra
<d1b2>
<azonenberg> which is totally fine
<d1b2>
<azonenberg> you can then use a real spectrometer to feed the same filter graph later
<d1b2>
<jdryg> Exactly!
<d1b2>
<johnsel> that should work, assuming you don't diverge too much from existing types
<d1b2>
<jdryg> It works (more or less, haven't tested many filters yet). My issue was the filter's configuration UI. 🙂
<d1b2>
<jdryg> Btw, does the FFT filter expects equidistant points? Does it work with UNIT_PM/UNIT_COUNTS waveforms (haven't looked at the code yet)? Because it doesn't seem to work in my case.
<d1b2>
<azonenberg> FFT filter expects uniformly sampled input, i don't actually remember if it cares about units
<d1b2>
<jdryg> Ok. I'll take a look. Maybe I'll try adding a Non-Uniform DFT filter if I need it.
<d1b2>
<johnsel> you'll see it yourself but the fft is based on vkfft
<d1b2>
<azonenberg> note that i mean a UniformAnalogWaveform specifically, it won't take a SparseAnalogWaveform even if all samples happen to be equally spaced
<d1b2>
<jdryg> I see. That's why it doesn't work in my case.
<d1b2>
<azonenberg> (that will change eventually, for jitter analysis it needs to be able to handle "uniform ish" data that can have tiny differences in sample spacing... most likely this will involve just ignoring the timestamps and treating the data as uniform sampled at the average frequency or something)
<d1b2>
<azonenberg> but proper resampling would be nice to do eventually
<d1b2>
<jdryg> Thanks for all the info guys!
<d1b2>
<jdryg> Hope to find the time to continue developing the filter (it's hard/boring doing the same stuff for your day job and as a hobby 🙂 )
<d1b2>
<johnsel> ping @azonenberg btw
<d1b2>
<azonenberg> I thought i PM'd you about that yesterday?
<d1b2>
<johnsel> nah, another one
<d1b2>
<azonenberg> we had the firewall exception but not an outbound nat rule for that subnet
<d1b2>
<johnsel> or did you
<d1b2>
<johnsel> let me check
<d1b2>
<johnsel> hmm I may or may not have sleep-read that lol
<d1b2>
<johnsel> let me test it real quick
<d1b2>
<azonenberg> (i'm feeling a little bit better but still dealing with a screaming toddler who has never really been sick before and has concluded the world is ending as a result)
<d1b2>
<johnsel> awww poor thing
<d1b2>
<johnsel> life is pain 😦
<d1b2>
<johnsel> so Andrew remember that I said we should have our tfstate on S3 because it could be lost say in an accidental vm deletion?
<d1b2>
<johnsel> the orchestrator vm just committed sepukku
<d1b2>
<azonenberg> oh? deleted itself?
<d1b2>
<johnsel> yes, haha. Not sure yet why
<d1b2>
<azonenberg> ouch. how hard will it be to recreate?
<d1b2>
<johnsel> might be the secret var added
<d1b2>
<johnsel> not very hard, I still have everything locally
<d1b2>
<azonenberg> ah ok good
<d1b2>
<azonenberg> and yeah when i'm back 100% i'll work on setting up a ceph object gateway you can use
<d1b2>
<azonenberg> in the meantime i'm chasing a deadlock in FilterGraphExecutor
<d1b2>
<johnsel> thanks, that would be great
<d1b2>
<azonenberg> where all the worker threads have completed but the top level thread never gets notified that they've done so
<d1b2>
<johnsel> heh
<d1b2>
<johnsel> I'm pretty sure I made the orchestrator not deletable though
<d1b2>
<johnsel> oh that's just a extra popup in the gui
<d1b2>
<johnsel> useful
<d1b2>
<azonenberg> lol
<d1b2>
<azonenberg> so it doesnt stop you from nuking it via xapi?
<d1b2>
<johnsel> well xoa-api but sure
<d1b2>
<johnsel> oh man
<d1b2>
<johnsel> even worse, it did throw it out of the resource set
<d1b2>
<johnsel> so you now have a zombie vm lol
<d1b2>
<johnsel> you're welcome (but please reassign it to my resource set lol)
<d1b2>
<johnsel> ci-orchestrator that is
<d1b2>
<azonenberg> you're saying ci_orchestrator isn't part of your resource set now?
<d1b2>
<johnsel> correct
<d1b2>
<johnsel> you can nuke it too if that's easier
<d1b2>
<azonenberg> i think it's in the set now
<d1b2>
<johnsel> yep, thank you
<d1b2>
<azonenberg> so turns out not a deadlock just slow
<d1b2>
<azonenberg> and vtune isnt working on my office machine for some unknown reason
<d1b2>
<azonenberg> interesting, the same file loaded faster on the lab workstation. ok now i'm confused
<d1b2>
<johnsel> Are those vms?
<d1b2>
<azonenberg> no, bare metal. i think i was just sick and impatient and it was a larger dataset than i remembered :p