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
<d1b2> <josHua> I have a DHO4000 but not a MSO
<d1b2> <josHua> I did use some recent ngscopeclient with my dho4000 to get it to do an FFT on something single channel, I have no idea if that replicates the conditions you want
<d1b2> <rapzak_> Working on enable more channels in multimeter as an option:
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #scopehal
<d1b2> <azonenberg> @rapzak_ so the one thing we have to watch out for there - which may need some API changes
<d1b2> <azonenberg> is that the original multimeter concept had a single readout and a mux, because e.g. my scope based DMM option on the wavesurfer 3000 series worked like that
<d1b2> <azonenberg> so we need to make sure we don't break support for that kind of use case
<d1b2> <azonenberg> (every so often, adding a new instrument is going to involve making API changes to handle flexibility for things we hadn't anticipated)
<d1b2> <azonenberg> also sorry i havent been around much, been a ton of work travel and then i seem to have got sick with something just when i had a week home lol
<d1b2> <azonenberg> keep up the good work
<d1b2> <rapzak_> so the one thing we have to watch out for there - which may need some API changes --> I am trying to take in into considerations.. i think there only has been small changes for now, and if only 1channel is defined i hope it will not break, however maybe look a litle different in gui layout
balrog has quit [Ping timeout: 248 seconds]
balrog has joined #scopehal
<d1b2> <azonenberg> yeah. Just saying, if you are going to have to change the api
<d1b2> <azonenberg> a) make sure you do it in a way that encompasses both your new use cases and the existing instruments
<d1b2> <azonenberg> and b) maybe do some research for what else is out there that we don't yet have drivers for, but might want to support in the future
<d1b2> <azonenberg> so we can futureproof and not have to change it too often
^Dan has joined #scopehal
^Dan has quit [Remote host closed the connection]
<d1b2> <rapzak_> ~ I have a PSU with multimeter... 🫣
pirate has quit [Ping timeout: 244 seconds]
<d1b2> <upupa.epops> I'm getting back (after a very very long hiatus) to trying to get the OWON scope to work, but I'm having trouble getting ngscopeclient not to hang after adding stuff to the filter graph. Adding any node seems to deadlock the program, is this a problem with my build or am I missing something?
<d1b2> <upupa.epops> adding the demo scope does work fine but as soon as I add a node it hangs
<d1b2> <rapzak_> Does the log give any clue?
<d1b2> <upupa.epops> nope, i can debug it tho and it's hanging on the mutex cpp //FilterGraphExecutor.cpp (start at line 98) //Block until they're finished while(true) { unique_lock<mutex> lock(m_completionCvarMutex); m_completionCvar.wait(lock, [this]{return m_allWorkersComplete;});
<d1b2> <upupa.epops> oh i have a feeling this is some GPU stuff
<d1b2> <upupa.epops> the worker threads are hanging on the vulkan activity mutex it appears
<d1b2> <upupa.epops> may be a problem with my drivers or something
<d1b2> <upupa.epops> nvm they are also hanging on the m_workerCvar mutex
<d1b2> <upupa.epops> hmm
<d1b2> <rapzak_> I hope you find it 🙂
<d1b2> <upupa.epops> yup it appears to be GPU stuff, because if the thread that's hanging on the vulkan mutex were to run the deadlock disappears
<d1b2> <upupa.epops> going to try to find what's holding the lock
<d1b2> <upupa.epops> probably a driver issue or something because I just recently reinstalled Ubuntu
<d1b2> <rapzak_> b) maybe do some research for what else is out there that we don't yet have drivers for, but might want to support in the future so we can futureproof and not have to change it too often --> To my research most of the DMM only have 1 set of terminals and therefore only really matters to do 1 channel with the prim/sec measurement... however a few seems to be able to measure voltage and current.. this can be done by adding 2 channels as i showed
<d1b2> with prim and sec streams. A couple has option to set in a card in the back like the agilent data acq mux and adds 10 more channels, again i think this can be handled. Some of the instruments start to have sample rate of 10ksps and maybe also 10ksp of memory, there they may seem to look a litle more like a simple scope... I had the same doubt for this for my hardware, right now i try implement my device under both instrument clases, so dependt on the
<d1b2> task i can chose if i want single value or a buffer of values tranfered... i even think they consider triggers on the bigger dmm's
<d1b2> <rapzak_> Doing my best....
<d1b2> <rapzak_> from chatgpt, not thinking all is correct, and i have browsed some of the models..:
<d1b2> <rapzak_> Table of Multimeters Supporting Dual Measurement Multimeter Model Type Primary Measurement Secondary Measurement Fluke 289 Handheld AC/DC Voltage, Current Frequency, Resistance Fluke 87V Handheld AC Voltage Frequency Keysight 34461A Bench Voltage, Current, Resistance Frequency, Period Keithley DMM6500 Bench Voltage, Current, Resistance Temperature, Frequency Rigol DM3068 Bench AC/DC Voltage,
<d1b2> Current Frequency, Resistance Hioki DT4282 Handheld AC Voltage, Current Frequency, Temperature Fluke 8846A Bench Voltage, Current, Resistance Frequency, Capacitance 🔹 Examples of Dual Measurements Fluke 87V & Fluke 289 → When measuring AC voltage, the meter also shows the frequency of the waveform. Bench Meters (Keysight, Keithley, Rigol, etc.) → They can measure voltage & frequency, resistance & temperature at the same time.
<d1b2> Keithley DMM6500 → Supports temperature as a secondary measurement along with electrical parameters.
<d1b2> <upupa.epops> oh welp the origin of my problem is this commit: https://github.com/ngscopeclient/scopehal/commit/fbb74272744b45db7fca6b339e5ebd054dfe9f08 but it seems this is very recent so I presume I just got unlucky and pulled between some interesting changes 😉
<d1b2> <upupa.epops> it appears the g_vulkanActivityMutex is tried to be acquired with an exclusive lock in the executor threads while it's share-locked by Session.cpp line 3330, so of course it blocks there forever
<d1b2> <azonenberg> It's possible there's a bug, i was fixing some concurrency issues recently
<d1b2> <azonenberg> Let me dig into that
<d1b2> <azonenberg> The intent is that any vkDeviceWaitIdle call should be exclusive with all other vulkan activity
<d1b2> <azonenberg> but i may have missed something that could lead to a deadlock
<d1b2> <azonenberg> It looks like FilterGraphExecutor.cpp:262 should have been a sharted_lock
<d1b2> <azonenberg> @upupa.epops try that on your end and see if it fixes the problem
<d1b2> <azonenberg> we should only be using exclusive locks if we're going to be doing something that is global to the entire vulkan device like a swapchain creation
<d1b2> <azonenberg> i'm building it locally and will do some testing on my end then push the fix if it seems to be OK on my side
<d1b2> <azonenberg> but please check on your end and confirm
<d1b2> <azonenberg> diff index 297b1391..60c13018 100644 --- a/scopehal/FilterGraphExecutor.cpp +++ b/scopehal/FilterGraphExecutor.cpp @@ -259,7 +259,7 @@ void FilterGraphExecutor::DoExecutorThread(size_t i) FlowGraphNode* f; while( (f = GetNextRunnableNode()) != nullptr) { - lock_guard<shared_mutex> lock(g_vulkanActivityMutex); + shared_lock<shared_mutex>
<d1b2> lock(g_vulkanActivityMutex); //Make sure the filter's inputs are where we need them auto loc = f->GetInputLocation();
<d1b2> <upupa.epops> yup that's perfect :)
<d1b2> <upupa.epops> it appears to run fine but I don't have any real device to test so just using the demo scope