00:24 <d1b2> <lle_bout> hi, what is scopehal exactly? is it an UI for TM over the network? Or is it something more? What kind of capabilities does it create compared to using the TM device as-is?

00:32 <d1b2> <lle_bout> Rigol MSO5000 (my scope) seems so slow to work with according to the docs, why?

02:17 <d1b2> <azonenberg> So, to clarify terminology: the entire project consists of the instrument hardware abstraction library (libscopehal)

02:18 <d1b2> <azonenberg> a suite of math functions and protocol decodes (libscopeprotocols)

02:18 <d1b2> <azonenberg> then two different frontend GUIs: glscopeclient (GTK + mix of Vulkan and OpenGL, being deprecated soon and no longer actively developed), and ngscopeclient (ImGui + Vulkan, current dev focus but still missing a few features)

02:19 <d1b2> <azonenberg> You can use either GUI or write custom C++ code to interface directly to the libraries

02:24 <d1b2> <azonenberg> As far as capabilities go, the GUI allows you to acquire waveforms from the instrument and then process them on a full sized PC display vs squinting at a tiny phone/tablet sized display

02:24 <d1b2> <azonenberg> you can do all kinds of more advanced protocol decodes and processing that especially cheap scopes don't have, for example decoding SPI flash traffic up to a wireshark-style table decode with addresses and data bytes

02:24 <d1b2> <azonenberg> or even ethernet and PCIe given a high enough BW scope

02:25 <d1b2> <azonenberg> You can also save the waveforms for offline analysis and study them later when your scope is doing something else, or send them to a coworker to help troubleshoot something

02:26 <d1b2> <azonenberg> You can also remote control other instruments (power supplies, multimeters, loads, function generators, etc) under a single GUI and even do multi-instrument analysis

02:26 <d1b2> <azonenberg> things like calculating efficiency of a voltage regulator by measuring voltage and current in vs out

02:27 <d1b2> <azonenberg> As far as performance goes, while the PC side is extremely fast (we GPU accelerate rendering and a lot of the DSP, like FFTs), your usable analysis speed is going to be limited by how fast the scope can push data to the PC

02:28 <d1b2> <azonenberg> and a lot of the cheap rigol/siglent type instruments are not designed with this in mind. the CPU is just too slow and/or code too unoptimized, so it can take tens to hundreds of ms, if not seconds, to pull a single waveform off the scope

02:28 <d1b2> <azonenberg> (But once you have the raw sample data on your PC you can scroll around, zoom, decode, etc. at full speed clientside, since you're not interacting with the hardware anymore)

19:36 <_whitenotifier-6> [scopehal-apps] shardus4 forked the repository - https://github.com/shardus4

21:57 <_whitenotifier-6> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://github.com/glscopeclient/scopehal-apps/compare/58fa0bb41e45...614289f81ce9

21:57 <_whitenotifier-6> [scopehal-apps] azonenberg 614289f - Updated to latest imgui, applied fixes to imgui-node-editor to match

22:06 <_whitenotifier-6> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/glscopeclient/scopehal/compare/7638b9ab3efb...8ca71dc62f7b

22:06 <_whitenotifier-6> [scopehal] azonenberg 8ca71dc - IBISParser: added checks for a few things we didn't yet handle such as "M" unit suffix

23:07 <d1b2> <lle_bout> @azonenberg Thanks I understand, so your software has full access to sample data and can add additional decoding for example which is very interesting for me considering how limited the decoding options are on an MSO5000 Rigol scope. In terms of optimization, since the Rigol scope can be accessed over SSH I wonder if it would be possible to modify the firmware to improve performance. I have been looking for a firmware modification initiative

23:07 <d1b2> on Rigol MSO5000 but havent found one yet. It seems obvious to me that the software on Rigol MSO5000 is a bit limited, for example the FFT function is so slow..

23:15 <azonenberg> I dont know how much you can do with the built in software just because the CPU is so wimpy

23:15 <azonenberg> generally the best option is to pull data off then do all the analysis clientside

23:15 <azonenberg> Yuo can also write your own decodes in C++ and chain them with exsting decodes

23:15 <azonenberg> for example it would be possible to create a decode for a usb-i2c bridge chip that takes in usb packets and outputs i2c packets, then chain the existing i2c eeprom decode on its output

23:16 <azonenberg> or create a decode for a spi dac that takes in spi packets and outputs an analog waveform you can then run any of the normal analog signal processing tools on