<d1b2>
<louis> First waves out of the DSLogic device 🙂
<d1b2>
<louis> @azonenberg want to take a look at the current state of https://github.com/602p/scpi-server-tools/tree/commandapi , which includes fixes for those issues you raised, and now also commands for digital threshold and hysterisis?
<d1b2>
<louis> I guess we need to decide if we're allowing overlapping digital and analog channel indices; if not this is fine, if we do allow them to overlap SetChannelEnabled and SetTriggerSource need to take isDigital also
<azonenberg>
Let's use a unified namespace
<azonenberg>
i.e. ID alone uniquely identifies which is which
<d1b2>
<louis> 👍
<azonenberg>
but we still need a way to tell if an ID is analog or digital so we know which commands are valid
<azonenberg>
so there has to be a method somewhere in the api to check
<azonenberg>
either in the parsing or a separate method
<azonenberg>
one to get the ID and one to check if the ID is analog or digital
<azonenberg>
I don't care one way or the toher
<azonenberg>
other*
<d1b2>
<louis> Currently we have bool GetChannelID(const std::string& subject, size_t& id_out, bool& digital_out); I would refactor that into bool GetChannelID(const std::string& subject, size_t& id_out) and a enum {ANALOG, DIGITAL, EXTERNAL_TRIGGER} GetType(size_t channel
<azonenberg>
That works
<d1b2>
<louis> Okie. I'll make those changes and push in a moment
<d1b2>
<louis> I have the DreamSourceLabs DSLogic talking, at least. Need to do some work to get it's trigger config working right.
<azonenberg>
What still has to be done trigger wise? supporting other kinds of trigger?
<d1b2>
<louis> It does support more complex serial triggers, but no, I just mean that something's not working right pushing the edge trigger config to it
<azonenberg>
oh
<azonenberg>
ok, yeah definitely get that debugged first
<azonenberg>
wrt more complex serial triggers this is actually something likely to need more work on the libscopehal side
<azonenberg>
defining APIs and object models for complex triggers
<azonenberg>
for example my lecroy 16 GHz scope has 8b/10b and 64b/66b triggers
<azonenberg>
but that is a complicated enough thing that the UI design for it will be nontrivial
<azonenberg>
in general, right now filters and triggers use entirely procedurally generated GUI objects
<azonenberg>
which works fine for basic stuff but as things get more complex i think we will want to do more complex UIs
<d1b2>
<louis> I also have some mystery meat CY7C68013A-based logic analyzer @MP handed me that is supposed to be supported by sigrok, but I haven't tried yet
<azonenberg>
this will involve either writing code to define those UIs, or figuring out a data driven way for a filter to include metadata about how stuff should be displayed
<azonenberg>
e.g. grouping related stuff together vs sorting attributes alphabetically
<azonenberg>
In general, most cheap FX2 logic analyzers should be supported by fx2lafw
<d1b2>
<louis> There's going to need to be some refactoring to get not-DSLabs-hacked-up sigrok integrated with the bridge, but it "in theory" shouldn't be that much work
<azonenberg>
long term i would like us to write our own bridge that talks directly to them to avoid the sigrok dependency but that is a longer term wishlist
<azonenberg>
near term getting easy wins to add more hardware cheaply is good
<azonenberg>
Let me send you a list of tickets against scopehal that we might be able to close soon based on this integration...
<azonenberg>
do not take this as a request to work on all of them in the near term
<azonenberg>
this is more of "if we get them for free, close the ticket"
<_whitenotifier>
[scopehal-waveforms-bridge] azonenberg 8ef79bd - WaveformServerThread: fixed race condition causing incorrect data to be sent to client if channel count changed midway through sending a waveform. Added error checking to drop connection if client disconnects.
<azonenberg>
@louis: see that last patch. i wonder if the other bridges have the same bug
<azonenberg>
pretty sure pico does and you likely copied it
<azonenberg>
tl;dr unlocking the mutex in that gap allows a clientside GUI change to re-arm the trigger which changes channelsEnabledDuringArm
<azonenberg>
thus leading to the headers and payload of the packet being inconsistent and confusing the client
<azonenberg>
I actually think i remember occasional desyncs in the pico driver i was trying to track down
<azonenberg>
and i bet this is the bug
<d1b2>
<louis> Not off the top of my head? There's a refactoring of a bunch of should-be-shared functionality out of DSLabsOsc into RemoteBridgeOsc pushed here https://github.com/602p/scopehal/tree/remoteosc
<azonenberg>
anyway i'll refactor the pico driver next
<azonenberg>
What is the status of that RemoteBridgeOscilloscope branch?
<azonenberg>
Are you happy with it?
<d1b2>
<louis> There may be a similar race in the sigrok driver, but I haven't hit it. It needs some more careful locking as it approaches real usability.
<azonenberg>
Ok
<azonenberg>
Copyright year in the comments needs to be updated to 2022, i saw that at a glance. Didn't want to spend too much time reading through the code unless you are ready to merge it
<azonenberg>
Send a PR whenever you're happy though
<d1b2>
<louis> I've only moved those things out that are in use in DSLabsOsc; I didn't want to start hacking around on Pico/others without a box to try it on.
<azonenberg>
Makes sense
<azonenberg>
We'll start with the most basic common functionality
<azonenberg>
we can always pull more stuff out into shared methods in the future
<d1b2>
<louis> Before you take a real look I need to fix some style stuff, and should also bring digital thresh/hyst over to RemoteBridgeOsc since I think that's going to be shared too.
<d1b2>
<louis> There's some other code viz. ADC modes and interleaved rates that is gonna be largely the same shape / duplicated, but that can be saved for a refactor after we have DSLabs and Pico both actually using RemoteBridgeOsc
<d1b2>
<louis> Sort of a question of approach how we want to go about those things, where if we want to have a fully generic sigrok bridge those things should probably come over the bridge, but i think in reality all the supported hardware is going to be quirky enough as to need it's own driver and so it could live there, too.
<azonenberg>
Yeah i expect there will need to be clientside quirks of various sorts. We'll figure that out later
<azonenberg>
100% support of all sigrok supported hardware is low on the priority list
<azonenberg>
Near term goal is to get this initial refactoring out of the way, then probably figure out the flow control / lag issue
<azonenberg>
which will likely involve WaveformServerThread getting refactored into some common subsystem as well
<azonenberg>
So i just ordered a hundred of the little mounting feet for the initial run of AKL-PT5s
<azonenberg>
The actual probe PCB layout may change (by a tiny bit) when i test the 450 ohm resistors so I'm not ready to order those in bulk
<azonenberg>
but the foot is fixed. And it's hard to go wrong at this price lol
<azonenberg>
$25 for a hundred boards
<azonenberg>
The one downside is they'll have mouse bites. So i'll need to sand them all down which will probably double or triple the price when you add in the few seconds per unit :p
<d1b2>
<louis> I think the RemoteBridgeOsc stuff should be lookable-at ... I don't see any glaring flaws, and the DSLabsOsc on that branch is using it.
<d1b2>
<louis> I'm a rank amateur at C++ so I'm sure there's plenty of things that should get tweaked
<azonenberg>
Ok great. Send a PR just so we have it officially pending and i don't forget
<azonenberg>
i have a lot more work to do on the pico bridge tonight then probably will be going to bed before i have time to look at that code
<azonenberg>
Are you at a stopping point now with other stuff or do you have enough other bits keeping you busy that this isn't a bottleneck?
<azonenberg>
i don't anticipate having time to review it until after i'm done with $dayjob stuff tomorrow evening
<azonenberg>
So if that will be a bottleneck let's figure out something else for you to do now
<d1b2>
<louis> I have a quirks-handling question for the DSLogic device; it ignores the trigger delay value, kinda. If you set the trigger delay to, say, 250ms and then the event it is programmed to trigger on happens 100ms after you arm it, you only get 100ms of capture before the trigger event.
<azonenberg>
So it arms the trigger before that full 250ms pre-trigger buffer has filled?
<azonenberg>
that's dumb :p
<d1b2>
<louis> Yes
<d1b2>
<louis> Same UX in DSView, that may just be how it is
<azonenberg>
so, in that case what i would do is make the output waveform be dense packed with trigger phase of 150ms
<azonenberg>
so the trigger point is still at 250ms on the timeline
<azonenberg>
it's derpy but seems the least bad option given the hardware quirks
<d1b2>
<louis> Yeah, that is what I was thinking is gonna have to happen. Not super convenient for glscopeclient users, but makes it usable
<azonenberg>
(most serious scopes have a state machine where in the pre-trigger state it ignores trigger events until the pre-trigger buffer is full)
<d1b2>
<louis> (Aside: It's not dense packed anyway because it does RLE (like the Pico driver), but I see your point about using trigphase to not have a surious 150ms long sample)
<azonenberg>
So if it's not dense packed
<azonenberg>
then just have offset of sample 0 be 150ms
<d1b2>
<louis> Oh, sure
<d1b2>
<louis> (Aside x2: am I correct in thinking that since this doesn't have any analog channels, trying to do trigger phase interpolation is meaningless because there's no slope to interpolate on ?)
<azonenberg>
Yes
<azonenberg>
just use the trigger point exactly
<azonenberg>
The point of trigphase is twofold
<azonenberg>
first, it allows sub-sample resolution for trigger interpolation
<azonenberg>
and second, it allows time shifting or de-skewing of channels while still allowing offset[0] to be 0, allowing dense packing
<azonenberg>
But for RLE data that is inherently sparse, and does not have any interpolation, neither make sense
<d1b2>
<louis> Gotcha! Sounds good.
<d1b2>
<louis> A related future design question akin to the transporting ADC samples vs transporting floats question will be transporting raw vs RLE-encoded digital data :^)
<azonenberg>
I think it makes sense to have a falg for that
<azonenberg>
flag*
<azonenberg>
Depending on the nature of the instrument one or the other may make more sense
<_whitenotifier>
[scopehal-pico-bridge] azonenberg f3ca5b7 - Refactored command parsing to use new scpi-server-tools
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]
<azonenberg>
@louis sooo right now by default when you connect glscopeclient opens basically all channels
<azonenberg>
and i'm wondering if that is really the best idea
<azonenberg>
there's been a lot of talk of changing this defualt but i'm trying to think what actually makes sense
<azonenberg>
in particular opening all MSO channels all the time unless you say --nodigital (and all spectrum channels on a tek mso IIRC) rapidly clutters the display with stuff you probably don't want or need
<azonenberg>
but then the question is, do we default to all analog channels?
<azonenberg>
or just the first 1 or 2? or what makes sense
<miek>
for the standalone scopes at least, i think it makes most sense to match whatever they already have enabled when connecting
<azonenberg>
So, having different behavior for usb vs standalone scopes is a very real possibility
<azonenberg>
although we'd have to figure out how to expose that in the API
<_whitenotifier>
[scopehal-apps] azonenberg 66af81a - Refactored handling of eye gradients to be data driven and dynamically create menu items as needed. Added reverse rainbow palette. Fixes #409.