<_whitenotifier-1>
[scopehal-apps] azonenberg 7a37744 - Updated to latest scopehal
<d1b2>
<chille0417> I'm in the process of buying some equipment to be able to do automated testing and similar stuff. A ThunderScope is high on my wishlist. This of course lead me to look at the ngscopeclient project. Now I'm trying to understand exact what this software could be used for. The information on the website leaves a lot to the imagination... 1) Have I understood it correctly that the name ngscopeclient is a bit misleading, as the software is
<d1b2>
actually meant to be used with any test equipment, and not just an oscillocope? Would it still be suitable for a more complex product that can do a little bit of everything, like a Bus Pirate? 2) Is there any documentation about what the different parts of the project does and how they interact with eachother? (ngscopeclient, libscopehal, libscopeprotocols, scopehal-apps, etc) 3) Even if I'm not going to use ngscopeclient for my automated testing, I'm
<d1b2>
thinking that maybe the best way to solve my problems would be to write a driver for ngscopeclient, and then use the API from my own application. Any comments on this? 4) Is there any reference implementations or documentation on how to use the API? 5) Is there an API to any other language, like Python? Even if I prefer C++ instead of Python, I still can't deny the fact that it's nice to use an interpreted language with no need to compile the code.
<d1b2>
6) Is there any documentation on how to write a driver? 7) Any plans to release an AppImage or similar?
<d1b2>
<azonenberg> Ok so, wall of text 🙂 one thing at a time...
<d1b2>
<azonenberg> 1) Yes. The name is a placeholder, one day we want to get an actual marketing/branding person to come up with a better name. But that costs money
<d1b2>
<azonenberg> first there was "scopeclient", all software graphics, in like 2011, and slow as tar. Never publicly released but it's in git history i think if you dig alllll the way back
<d1b2>
<azonenberg> then opengl-accelerated glscopeclient, from like 2015-20 or so
<d1b2>
<azonenberg> actually i think closer to 2022
<d1b2>
<azonenberg> then we ported to vulkan and did a big frontend rearchitecture giving ngscopeclient, which is the current frontend and we plan to stick with for a long time
<d1b2>
<azonenberg> Yes, it's meant to be used with all kinds of test equipment. For the most part it's currently an analysis and decoding tool (capabilities for pushing waveforms out are limited) but we plan to build that out in the long term
<d1b2>
<azonenberg> (e.g. we can control external function generators but not do full arbitrary waveform synthesis)
<d1b2>
<azonenberg> 2) We need to work on that. In short... libscopehal is the low level hardware drivers and base classes everything relies on, libscopeprotocols is all of the standard filter graph blocks (protocol decodes, math functions, measurements, etc)
<d1b2>
<azonenberg> scopehal-apps is the repository for officially supported tooling that calls out to the libraries. Right now this is just ngscopeclient
<d1b2>
<azonenberg> 3) That is very much an intended workflow, the one thing to keep in mind is that the project is still at v0.x level maturity, i.e. breaking API/ABI changes may happen at any time (we don't do it without good reason but there are a number of major refactorings in the pipeline)
<d1b2>
<azonenberg> Starting at v1.0 there will be much strong api/abi stability guarantees
<d1b2>
<azonenberg> but that's a ways out
<d1b2>
<azonenberg> 4) There are Doxygen-compatible comments in headers of most of the core classes, but I don't think we currently have any tooling to generate browsable HTML/PDF doc from that. It's on the TODO
<d1b2>
<azonenberg> We have some old bitrotted example code that needs to be rewritten, there are currently no good example applications
<d1b2>
<azonenberg> 5) As of now, no. It's on the longer term list of things to look into (as well as python/lua/whatever scripting to automate the ngscopeclient gui itself)
<d1b2>
<azonenberg> 6) Not currently. Also on the list. We've focused on writing end user documentation as that's higher priority for growing the user base (there's many more users than devs) and even that has been challenging given the amount of work to do and the size of the team
<d1b2>
<azonenberg> 7) There are plans to have automated packaging flows producing windows MSI, macos whatever, and linux deb/rpm packages from every commit as part of the CI pipeline (and eventually use this to cut releases)
<d1b2>
<azonenberg> They're at varying stages of completeness so far, although people are actively working on it
<d1b2>
<chille0417> Okay, that answared most of my questions. Thank you!
<d1b2>
<chille0417> About the capabilities to push a waveform out. What do you mean with limited? Is it possible at all to push out a waveform? Is it possible to push digital I/O or static analog values? I'm thinking more about the API. If I'm going to do automated testing I will mostly likely need to send arbitrary data that I generated myself in some way. It coule be something simple like controlling a few digital outputs to switch some relays to reroute
<d1b2>
signals between different test equipment.
<d1b2>
<azonenberg> So we have API support for switch matrixes already
<d1b2>
<azonenberg> This is implemented as a series of channel objects representing inputs and outputs
<d1b2>
<azonenberg> and paths you can create between them
<d1b2>
<azonenberg> So far all of the testing has been on buffered matrixes (i.e. FPGA based switching rather than relays) but i'll gladly help you create any missing APIs for things we don't currently have
<d1b2>
<azonenberg> obviously the api lets you control things like power supply voltage and current setpoints
<d1b2>
<chille0417> Okay, cool.
<d1b2>
<azonenberg> or function generator wave shape, frequency, amplitude, etc
<d1b2>
<azonenberg> automated testing is very much a core use case so any features you're missing we want to know about
<d1b2>
<azonenberg> Another thing we have planned for the long term, but not yet implemented
<d1b2>
<azonenberg> is the ability to export a filter graph you design in the GUI to some sort of file you can use from external code
<d1b2>
<azonenberg> Whether it's literal C++ code to instantiate the filters and wire them together, or some kind of yaml/json/xml/whatever representing the connectivity that you can load via the API, is TBD
<d1b2>
<azonenberg> but we want you to be able to design an experiment in the gui and export it in some way to headless API test cases
<d1b2>
<chille0417> Btw, to name some of the equipment I intend to use:
<d1b2>
<chille0417> I just ordered a Hantek 365B USB multimeter, which already have the protocol reverse engineered with open source software. If it works good I'm probably going to buy a few more.
<d1b2>
<chille0417> The Riden power supplies. Should be quite easy as I think it is documented by the manufacturer.
<d1b2>
<chille0417> Bus Pirate 5/6. The new binary protocol is a work in progress. But it could probably be a good idea to team up with Ian and implement a driver for ngscopeclient at the same time. That would be a pretty good way to test the new binary procotol.
<d1b2>
<chille0417> I'm running Ubuntu 24.04 and successfully compiled everything. However, when I try to start ngscopeclient I get the following: [22:29:53 chille@chille-desktop:~/scopehal-apps/build/src/ngscopeclient] ./ngscopeclient ERROR: glfwGetRequiredInstanceExtensions failed, code 0 ((null))
<d1b2>
<chille0417> (I'm using the system-provided Vulkan packages)
benishor has quit [Quit: tah tah!]
<d1b2>
<chille0417> I use the built in GPU in my Intel 14900k CPU (UHD Graphics 770). It is supposed to support Vulkan 1.2 and have drivers included in the Linux kernel. lspci says that the i915 driver is used. vulkaninfo says: ERROR: [Loader Message] Code 0 : vkCreateInstance: Found no drivers! Cannot create Vulkan instance. This problem is often caused by a faulty installation of the Vulkan driver or attempting to use a GPU that does not support Vulkan.
<d1b2>
ERROR at ./vulkaninfo/./vulkaninfo.h:458:vkCreateInstance failed with ERROR_INCOMPATIBLE_DRIVER
benishor has joined #scopehal
<d1b2>
<azonenberg> Hmm. well that's a GPU driver issue one way or another, nothing we can do about that on our side if even vulkaninfo fails
<d1b2>
<johnsel> on that note
<d1b2>
<johnsel> vmware gpu acceleration
<d1b2>
<johnsel> totally broke ngscopeclient
<d1b2>
<johnsel> also maybe weird question
<d1b2>
<johnsel> but I feel like this is the only place I can ask it
<d1b2>
<johnsel> am I the only one with a box for bad cables
<d1b2>
<johnsel> not bad is not functioning
<d1b2>
<johnsel> but as in naughty cables
<d1b2>
<johnsel> like, just bad in the sense that pop up when I don't need them, not be findable when I do, have weird connectors I only need once in a decade
<d1b2>
<johnsel> that kind of bad
<d1b2>
<johnsel> but it is a dedicated box
<d1b2>
<johnsel> and they do go there
<d1b2>
<johnsel> they sometimes come out too, but I'll be honest, I've stuck more in than taken out over their lifetimes
<d1b2>
<azonenberg> i have a dedicated box just for cursed usb cables in particular
<d1b2>
<johnsel> I was so worried everyone would think I'm crazy for a sec there
<d1b2>
<johnsel> not that I'm not
<d1b2>
<azonenberg> like this one. or A male to C female. or A male to A male
<d1b2>
<johnsel> but that is another point
<d1b2>
<johnsel> those are just gender non-conforming
<d1b2>
<chille0417> I'm installing the Vulkan SDK manually now.
<d1b2>
<azonenberg> not the A male to barrel jack :p
<d1b2>
<johnsel> I don't think we can put those in a bad box anymore (not that we ever should have done that with people)
<d1b2>
<johnsel> He's an airplane
<d1b2>
<johnsel> what was that stupid right-ish joke about it
<d1b2>
<johnsel> I'm an attack helicopter
<d1b2>
<johnsel> he's the attack helicopter of the bunch
<d1b2>
<johnsel> now you're going to laugh @azonenberg
<d1b2>
<johnsel> but I have a device
<d1b2>
<johnsel> let me make a pic
<d1b2>
<johnsel> that takes that exact cable
<d1b2>
<chille0417> And this is actually the only GPU I have ever had that just works perfect. I've been running Linux for around 25 years now. But who knows, maybe I don't even have the GPU drivers installed and thats why everything works so great. 🙃
<d1b2>
<azonenberg> intel iGPUs should have native vulkan out of the box on any remotely recent kernel
<d1b2>
<azonenberg> also, just a note, i've seen some claims in some channel or forum that we require vulkan 1.3
<d1b2>
<azonenberg> that is not the case, to the best of my knowledge we require 1.0. some features fall back to less efficient or CPU-based alternatives without 1.2
<d1b2>
<azonenberg> but if you find anything that breaks on older vulkan versions, let me know
<d1b2>
<johnsel> Cleaned with a solvent it did not like btw
<d1b2>
<johnsel> Everything is not horribly gross in my house
<d1b2>
<chille0417> Too bad I have 24 cores and the Vulkan SDK default to compile on only one core...
<d1b2>
<johnsel> I think that's from our docs
<d1b2>
<azonenberg> our docs should say 1.0 as minimum with 1.2 preferred. i dont even know if we use any 1.3-only features
<d1b2>
<azonenberg> i know we have a bunch of device extensions we use when available, e.g. 8/16/64 bit integer support is not required by the spec but widely supported
<d1b2>
<azonenberg> but we have fallbacks for all of those
<d1b2>
<johnsel> anywya
<d1b2>
<chille0417> @azonenberg FYI: I just scp:ed build/src/ngscopeclient to another computer and added libscopehal.so, libscopeprotocols.so, libglfw.so and libyaml-cpp.so. And it seems to work. So I think is should be pretty easy to make an AppImage.