<azonenberg>
@mubes: anyway sounds like that would be a perfect application for command queueing
<azonenberg>
being able to have a background thread play set commands every 50ms while the UI is unblocked
<azonenberg>
this would also potentially allow for some filtering to remove redundant commands
<azonenberg>
so say you send three commands in a row to set the vertical scale while scrolling on the axis
<azonenberg>
only the first and last will execute
<azonenberg>
because we can tell it if you see >1 set scale commands in sequence, you can delete all but the most recent
<d1b2>
<mubes> Yep. Iirc the pacing interval is set at 50mS or so. It's only a major issue for 'bulk setup' kinds of stuff and they have committed to fix it. We can do a Nagle-style batching then with ';'.
<d1b2>
<mubes> In general giving the scope interface its own task and dispatch capability would speed things up and make them easier to maintain though. One thing we could look at is initially downloading a 'thin' representation of the waveform (e.g. every 8th value) which is good enough for display purposes and then fleshing that out with the full sample set if it's to be retained.
<azonenberg>
yeah thats already been discussed. but hard to use for decoding etc which is the main use case for glscopeclient
bvernoux has joined #scopehal
<d1b2>
<mubes> Sorry, not keeping up with the group! Doesn't work for decode at all, just for nice pretty pictures and the illusion of better performance. However, I suspect that data volume isn't the limiting factor...if you look at the graph in the manual it's flat across quite a few data sizes before it starts to dip. At least for those sizes volume isn't the constraint. Something else is.
<azonenberg>
yes its definitely firmware
<azonenberg>
miek: hey, when you get a chance
<azonenberg>
can you send me some agilent/keysight/rigol bin files?
<azonenberg>
i'm doing some refactoring of the import logic and need some test cases to make sure i didn't break anything
XMPPwocky has joined #scopehal
massi has joined #scopehal
<azonenberg>
GyrosGeier: Hey, so i talked to Pico and one of their Linux guys is interested in seeing what it would take to get their driver/software packages into debian non-free
<azonenberg>
Can you PM me an email address so i can put you two in touch to discuss them becoming a maintainer for the package?
massi has quit [Remote host closed the connection]
<d1b2>
<louis> @azonenberg I've been working on some first-order stuff (using the DSCope + glscopeclient, actually 😄 ) and haven't started on the control flow / data plane unification yet. But I'm getting annoyed by the delay and low WFM/s with this control flow code so I'll get around to it sooner or later 😛
<azonenberg>
Ok thats fine. Just want to make sure none of my upcoming stuff is going to step on you and vice versa
<azonenberg>
One thing i am doing may break the driver though. the channel type is going to be moved from properties of the channel to properties of the stream
<azonenberg>
and width will be moving from a channel property to properties of a digital bus only as it makes no sense anywhere else
<azonenberg>
i will also add a new channel type "digital bus" to avoid confusion between vectors and single bit digital signals
<azonenberg>
that will be happening over the next few evenings and probably require retooling of the MSO channel support in every scope driver
<azonenberg>
but relatively minor and i will attempt to make all the changes myself in a non-breaking manner
<azonenberg>
The reason is that i need to be able to have filters that output both digital and analog streams
<azonenberg>
e.g. a CSV import
<azonenberg>
and right now that is not possible in the current model. a scope can have digital and analog channels but a filter cannot
<azonenberg>
Also, the AKL-PT5 probe mounting feet just shipped from oshpark
<azonenberg>
As did the PRBS generator
<azonenberg>
So i should get both of those late this week