<d1b2>
<rapzak_> Hi, just being new here 🙂 - I hope i am not going to be too much anoying for you guys... I tried this great software just 20min ago... How do i delete an added block? - Delete buttom seems not to work and i can not drag it out of the screen?
<d1b2>
<rapzak_> Next question is: I have some custom made DAQ, based in RP2040 with usb... If i like to implement this into this software, what will be the most easy way? I have not implemented the usb interface yet in the board.... i am talking about 4 (maybe 8)channels (24bit) with a max sample rate of 20khz... It there some SCPI devices there will be more easy to structure it from?
<d1b2>
<azonenberg> As of now, filter blocks are reference counted
<d1b2>
<rapzak_> I hope in this, the interface binding is kind of and addon, not like in the sigrok where everything has to be compiled together
<d1b2>
<azonenberg> they self-delete when the last waveform view, filter, measurement, etc. using them is removed
<d1b2>
<azonenberg> (sometimes this fails, there are known bugs)
<d1b2>
<azonenberg> We're busy trying to get version 0.1 out the door soon, but hopefully as we work on 0.2 we'll be able to improve on this. There's a lot of backend cleanup to do before that can happen
<d1b2>
<azonenberg> If you can implement USBTMC or CDC-ACM (i.e. usb-serial) on the firmware and provide a scpi-ish API it's straightforward to make a driver for it
<d1b2>
<azonenberg> It's not super well documented but we do support plugins for drivers, filters, and transports
<d1b2>
<azonenberg> there is no API/ABI stability, so you have to compile the plugin against a specific version of libscopehal and only use it there (similar to how linux kernel drivers only work with the kernel they were compiled against). Longer term as we get to a version 1.0 release we hope to start offering stable ABIs
<d1b2>
<azonenberg> but that's a long ways out
<d1b2>
<rapzak_> This is some of the blocks i can not remove... just for your info 🙂
<d1b2>
<azonenberg> so the RMS, uart, and waterfall should go away once you remove the waveform views and delete the measurement. if not, that's a a bug (but a low priority one given we plan to completely rip out and rewrite the offending code)
<d1b2>
<azonenberg> the export filter is impossible to remove without closing the session and making a new one
<d1b2>
<azonenberg> tl;dr since the export has no outputs, it would normally self-delete instantly
<d1b2>
<azonenberg> in order to work around this, there's an ugly hack that creates a reference to it and never frees it
<d1b2>
<azonenberg> which makes it stick around and be useful but as a side effect makes it impossible to get rid of
<d1b2>
<azonenberg> (these are just some of many examples of why the entire internal ownership/data model around filters needs to be ripped out and redone... the days before v0.1 release is just not the time to make that happen)
<d1b2>
<rapzak_> USBTMC was my first idea to use, but was seeing sigrok was not supporting this... and during my investigation your tool came around 🙂
<d1b2>
<rapzak_> no problem 🙂
<d1b2>
<azonenberg> We support serial (via either real RS232 ports, usb-uart chips, or cdc-acm virtual uart to firmware), raw TCP sockets, VICP and LXI VXI-11 framing, and probably a few others too
<d1b2>
<azonenberg> and USBTMC
<d1b2>
<rapzak_> USBTMC is just more great to avoid the comport setting
<d1b2>
<azonenberg> i have no idea what usbtmc is like on the firmware side of things, on Linux (the only platform we support it for host side) it just shows up as a /dev/usbtmc device
<d1b2>
<azonenberg> We don't currently support USBTMC on Windows, because AFAIK windows doesn't have native USBTMC support, you need a device specific driver for it
<d1b2>
<rapzak_> arhh it was on windows sigrok did not support it
<d1b2>
<azonenberg> yeah that's probably why
<d1b2>
<azonenberg> CDC-ACM should be natively supported by window's standard com port driver
<d1b2>
<rapzak_> but i think i made a test program, where it enumerated on windows
<d1b2>
<azonenberg> but i'm not a windows dev personally
<d1b2>
<azonenberg> so i dont really know a ton about the driver stack there
<d1b2>
<rapzak_> im just a hardware guy so not knowing to much of either 😦
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
bvernoux has quit [Quit: Leaving]
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
<d1b2>
<azonenberg> oh interesting there is a standard USBTMC driver from IVI?
<d1b2>
<azonenberg> if you can find any documentation for how to talk to it from a Windows application (i.e. what devices this driver exposes to userspace) we can add support for it
<d1b2>
<azonenberg> or at least, one of our windows devs can :p
Stary has quit [Ping timeout: 265 seconds]
Stary has joined #scopehal
<d1b2>
<rapzak_> It seems there still is some changes there has to be made with zdiag to enable it, so not 100% standard
<d1b2>
<rapzak_> the stackoverflow link there is some more info in that
<d1b2>
<rapzak_> for now i think i will implement scpi on ethernet (over usb)
<d1b2>
<azonenberg> That sounds like a lot of hassle compared to CDC-ACM which should be a much simpler protocol (no need for TCP/IP in your firmware)
<d1b2>
<azonenberg> it should use a built in Windows driver and show up as a serial port, you can ignore the baud rate settings and use it as default since it's not a physical uart
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #scopehal
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
ALTracer has quit [Read error: Connection reset by peer]