Recent searches
Search options
Tonight's quick ngscopeclient dev fix: GPU accelerating the demo scope.
It now runs quite a few times faster than before (and is faster to process subsequent filter blocks on, since the input data is now GPU resident).
Not super critical but a nice quality-of-life fix since I use the demo scope as a data source for development pretty often.
@azonenberg Is there a doc anywhere that goes over how to support a new scope? I played with an experiment a while ago to make the most accessible scope possible (an Arduino nano + a single Python script) and would be interested to see how that would go with ngscopeclient. I looked back then but didn't see much.
@Lee_Holmes Not currently. We have (probably slightly out of date by this point) developer docs on the website but they're mostly just doxygen, there's not a lot of higher level meta-information yet.
In summary it's basically create a new class derived from SCPIOscilloscope that connects to your scope via a SCPITransport (UART is probably the simplest if you're using an arduino as the capture hardware).
By default it will want to send a *IDN? at startup to identify the scope but other commands are up to your driver to implement.
To actually register the driver so it can be used, add an AddDriverClass() line in scopehal.cpp where we register all the other drivers.
@Lee_Holmes Right now the dev team (mostly me, plus a few infrequent contributors writing a patch here and there but not very active) are busy chasing bugs and working on packaging in preparation for the v0.1 release we wanted to have out last December.
Once that ships, there's a bunch of refactoring to do to fix some legacy technical debt from years ago that needs to be addresses. Lots of things to do.
The big problem we're currently having is that while we have people sending PRs for specific scope drivers, protocol decodes, and bug fixes from time to time, nobody is really working on the core platform itself (or the GUI) other than me. And that's what needs the most work.