<ablu>
azonenberg thanks for the input. That certainly gave me good context for the code I was looking at! I am trying to get the Glasgow's digital signal analyzer applet to live stream to something where I can view and decode the signals live (rather than dumping to file only).
<azonenberg>
Makes sense. Well i'm all for a glasgow driver, i would probably implement that as a scope
<azonenberg>
one thing to note is that we currently do not have good support for multi-bit digital signals. arbitrary complex types like protocol events are fine
<azonenberg>
but n-bit digital signal is a type we don't support well at the moment, i have ideas but they're invasive enough it's also a v0.2 thing
<ablu>
What does protocol events mean in this context? 🤔
<azonenberg>
ablu: so the way our object model for waveforms works is, a waveform can be sparse or uniform
<azonenberg>
a uniform waveform is a series of samples of arbitrary type at fixed intervals with no gaps
<azonenberg>
a sparse waveform is a series of samples of arbitrary type with arbitrary, monotonic start times and durations
<azonenberg>
in other words, each sample covers a window in time which begins at or after the end of the previous sample
<azonenberg>
there may be gaps
<azonenberg>
but no overlap is allowed
<azonenberg>
so for example if you have readings of an ADC at a fixed rate that's a uniform waveform
<azonenberg>
if you have average temperatures irregularly sampled, that's a sparse
<azonenberg>
analog waveforms have the sample type as a float32, e.g. a UniformAnalogWaveform is just an alias for UniformWaveform<float>
<azonenberg>
digital waveforms have the sample type as bool
<ablu>
Ah yeah, makes sense. I saw that in the code. Just wasn't sure whether "protocol event" was a specific term from the code. Thanks for the input!
<azonenberg>
and protocol decode waveforms, which are basically always sparse (the object model allows uniform but it would make little sense in most cases), have arbitrary C++ object type
<azonenberg>
so you might have an I2CSample object that could represent a start condition, a stop condition, a device address, a byte of data, etc
<azonenberg>
anyway, so there is probably still some legacy code we havent fully removed (maybe) that represented digital waveforms as a vector<bool> at each sample
<azonenberg>
this had horrible performance and wasn't gpu compatible so it got scrapped
Degi has quit [Ping timeout: 265 seconds]
<azonenberg>
the tentative near-term plan for digital vectors is to have a uint64 per sample to support up to 64 bits
<azonenberg>
and then figure out what to do about >64 bit vectors in the future :p
<azonenberg>
(probably packed multiple uint64s per sample)
<azonenberg>
basically its going to be a tradeoff between wasting memory on e.g. an 8-bit or 2-bit vector
<azonenberg>
but also making it straightforward to render and parse arbitrary width digital signals
<azonenberg>
this is still a somewhat open architectural question
<ablu>
Thanks! Will try to find some time to keep toying around :). But probably should go back to sleep right now...
<d1b2>
<vk2seb> Any interest/opposition to adding support for multichannel USB soundcards to scopehal? I've been thinking about working on this at some point both for my QA403 audio analyzer, and the Tiliqua platform
<d1b2>
<vk2seb> I imagine it could exist as a generic HAL compatible with any such device, maybe just with some presets to load standard amplitude calibrations for specific models
<d1b2>
<azonenberg> feel free to pick it up if you're interested
<d1b2>
<david.rysk> probably a good use case for portaudio or rtaudio
<d1b2>
<azonenberg> or if we switch our backend from glfw to sdl3 in v0.2 i think they have an audio backend we can use
<d1b2>
<david.rysk> ah yeah there is that too
<d1b2>
<azonenberg> Which is kinda why i had this tagged as a v0.2 thing if we were gonna go that route anyway
<ablu>
Ok, I managed to display some digital waveforms. But they reset on every acquire cycle (based my code off the sample oscilloscope where that makes sense). Is there any example how I can just grow the waveform forever (or make the waveforms display next to each other)?
<ablu>
Or phrased differently: I just want to keep recording new samples into the current view without resetting.
<d1b2>
<aleksorsist> Happy to throw you a ThunderScope PVT unit to use for development if you start working on this
<d1b2>
<aleksorsist> I'm keenly interested in a lighter, beginner friendly scopehal client and will happily support anyone working on one
<dingwat>
since none of the power supplies or multimeters I have are supported in ngscopeclient, what functionality does ngscopeclient offer for automation/sequencing? Specifically, I want to step through different voltages/currents on a power supply and make measurements with two or more multimeters at each step (debugging a broken Keithley 2700). I'm not aware of any open-source project out there that would do this, am I missing something?
<azonenberg>
ablu: So, if you look at how the socketcan driver works, we do support a sort of continuous-append mode there
<azonenberg>
There are limits as to max memory depth and such, you can't grow *forever* (the somewhat hard limit on most platforms is 4GB per waveform with the current architecture due to how Vulkan does SSBOs)
<azonenberg>
but you can certainly append to an existing one up to a point
<azonenberg>
dingwat: We can do this
<azonenberg>
basically you need to create a scalar representing the set point (right now the only option is probably the "scalar stairstep" filter
<azonenberg>
feed that into the power supply channel block
<azonenberg>
then you can use e.g. the x-y trend block to plot measurements of the mutlimeter reading vs the PSU setting
<azonenberg>
the stairstep filter outputs a pulse every time it updates, you can use the scalar pulse delay filter to delay this to provide a trigger signal
<azonenberg>
look at my blog on how i did the characterization on the 48V IBC for an example, that's actually what i created it for
<azonenberg>
in my case i was sweeping an active load's current setting while measuring other stuff vs load current
<azonenberg>
but i believe PSU channels should have set point scalar inputs as well
<azonenberg>
(if not, it's trivial for me to add)
<d1b2>
<azonenberg> I would also love a tablet frontend one day (I think phone is technically possible at least for shallow memory but the UX is likely to be very challenging, while table is actually plausibly useful)
<d1b2>
<azonenberg> and given how well apple silicon runs ngscopeclient I think a nice iPad would actually work very well for scopehal stuff
<d1b2>
<azonenberg> It would just need a complete frontend rewrite to be touch centric
<d1b2>
<aleksorsist> Oh yah, iPad pro has thunderbolt so that's quite exciting to me
<d1b2>
<azonenberg> There's that but you could also run ts.net on a PC and be walking around the lab or something
<d1b2>
<azonenberg> holding the ipad and streaming a subset of data over wifi
<d1b2>
<azonenberg> also things like remote controlling power supplies and meters and stuff with it
<d1b2>
<azonenberg> there's a ton of use cases i just cant be bothered to learn iOS development to make it happen
<d1b2>
<aleksorsist> I'll definitely try to make it happen eventually, given TS does well enough
<d1b2>
<aleksorsist> (and manages to get out of development hell)