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
Degi has quit [Ping timeout: 272 seconds]
Degi has joined #scopehal
<_whitenotifier> [scopehal] chille opened pull request #909: Multimeter: Added modes for resistance, capacitance, continuity and diode test - https://github.com/ngscopeclient/scopehal/pull/909
<_whitenotifier> [scopehal] chille opened pull request #910: SCPITransport: Added dynamic rate limiting - https://github.com/ngscopeclient/scopehal/pull/910
<_whitenotifier> [scopehal] chille edited pull request #910: SCPITransport: Added dynamic rate limiting - https://github.com/ngscopeclient/scopehal/pull/910
<d1b2> <chille0417> Haleluja! Finally got ngscopeclient working on my computer. I was missing the package mesa-vulkan-drivers. 🦄
<d1b2> <azonenberg> wait you didnt have it working before??
<d1b2> <chille0417> Nope, ngscopeclient didn't start at all. Even "vulkaninfo" just gave me an error.
<d1b2> <chille0417> @azonenberg I'm trying to use SCPITransport::SendCommandImmediateWithRawBlockReply(). Is this some kind of standardized SCPI way of sending raw data? My OWON HDS200 sends data with a slightly different header.
<d1b2> <chille0417> I get four bytes of header: 0x4C 0x02 0x00 0x00. Then I get 588 bytes of data. 0x0000024C == 588. So it seems that the header is the length stored as a 32bit little endian integer.
<d1b2> <chille0417> It seems like the R&S and Tektronix drivers are using that function.
<d1b2> <miek__> yeah, it's for an IEEE 488.2 definite length arbitrary block response
<d1b2> <chille0417> Hmm... okay... then OWON is doing something weird. 😦
<d1b2> <chille0417> Do we care about compiling on big-endian systems, or can i just: char tmplen[4]; uint32_t len2 = (uint32_t)tmplen;
<_whitenotifier> [scopehal] fredzo opened pull request #911: Oscilloscope download progress API - https://github.com/ngscopeclient/scopehal/pull/911
<_whitenotifier> [scopehal-apps] fredzo synchronize pull request #765: Rich UI support for StreamBrowserDialog on oscilloscopes - https://github.com/ngscopeclient/scopehal-apps/pull/765
<d1b2> <fredzo_72653> @azonenberg this is the PR for the GetDownloadState() API discussed earlier : https://github.com/ngscopeclient/scopehal/pull/911 It comes with an implementation for DemoOscilloscope and Siglent and Rigol drivers. Other driver will inherit from the default implementation that does not show a progress bar (until implemented on their side).
<d1b2> <fredzo_72653> @josHua I pushed the corresponding method call to your branch, so you'll have to checkout my branch (https://github.com/fredzo/scopehal/tree/oscilloscope-download-progress-api) of scopehal to compile this version of StealBrowserDialog. Good news is it comes with Rigol driver progress bar implementation, so you should be able to check it out with your DHO4000 😉
<d1b2> <fredzo_72653> Here is what it looks like on a 1Mpts capture with 2 analog channels and 16 digital channels pour my SDS2104X HD:
<d1b2> <josHua> ok cool, I just took a look at that branch, I have some comments but also I just got back from racing a bike and I am very tired so I am going to have a shower and then have a nap and try to be productive in the afternoon and evening
<d1b2> <josHua> that is extremely cool looking. I have ideas for streamlining it a little more UI-wise but I have a few other things I do need to do today too
<d1b2> <fredzo_72653> I think my next step will be to add Power Supplies to the SteamBrowserDialog
<_whitenotifier> [scopehal-apps] fredzo synchronize pull request #765: Rich UI support for StreamBrowserDialog on oscilloscopes - https://github.com/ngscopeclient/scopehal-apps/pull/765
<d1b2> <fredzo_72653> @azonenberg for digital channel properties in StreamBrowserDialog, we would show the digital threshold value:
<d1b2> <fredzo_72653> For now this parameter is not cached on most scope drivers, so we cannot call GetDigitalThreshold() in the Render method of the dialog. Should we cache that value in the drivers that implement this method ?