<azonenberg>
@louis so, to recap our DM discussion: I think it makes sense near term to begin refactoring the Digilent, Pico, and DSLabs drivers to share as much common client and server code as possible
<azonenberg>
Cleaning up the SCPI server code to be a common library for use server side is straightforward and should be a couple hours of work max
<azonenberg>
For actual waveform transfer, there are two possible approaches: always using fp32 over the network for sample data (keeps client code simple, and can save CPU on the client, but can also bloat network bandwidth significantly)
<azonenberg>
or using instrument native ADC code format over the network and scaling clientside, which is how we currently do it
<azonenberg>
For the clientside code, I think what we should do is create a new abstract driver class called something like ExternalBridgeOscilloscope
<azonenberg>
and push all of the common stuff like setting channel gain/offset, querying valid memory depths, etc into that base class
<azonenberg>
have the Digilent, Pico, and DSLabs drivers inherit from that rather than directly from SCPIOscilloscope, and only implement the stuff that's different
<azonenberg>
e.g. Pico has fairly complex rules on the 6000 series for which channels can be active given the current sample rate and memory depth
<azonenberg>
As part of this, we will want to make a new section at the end of the manual that describes the base SCPI command set used by all of the bridges
<azonenberg>
(then we can have separate docs for driver-specific commands that are not shared by all)
<azonenberg>
Does that sound about right?
<d1b2>
<louis> That sounds about right to me!
<azonenberg>
Ok, great. In that case... are you doing anything else right now?
<azonenberg>
or can we get moving on this soonish
<d1b2>
<louis> The other changes we discussed were: Oscilloscope need to report back to the UI the trigger delay (and probably other parameter) value that was actually applied after hardware constraints
<azonenberg>
So, the best way to do that is probably to have a field in the waveform header for the actual trigger position
<azonenberg>
which we then update the clientside trigger position cache from
<d1b2>
<louis> And part of the ExternalBridgeOscilloscope framework will include a credit-based control-flow schema for preventing gigantic buffering of waveform data if the external bridge can sample [much] faster than scopehal can consume it [over the network]
<azonenberg>
When dragging the trigger position live in the gui every video frame we need the cached position to be under the cursor, so it looks right in the gui
<azonenberg>
Yep
<azonenberg>
That is going to come later
<azonenberg>
the first step is refactoring the existing drivers to provide the same feature set they have now
<azonenberg>
but with less code duplication
<azonenberg>
Then we start adding new features to the common core
<azonenberg>
I think we should start with the SCPI layer, keep the binary data protocol per-driver for a short time
<azonenberg>
there's more nuance to deal with there
<d1b2>
<louis> As in, leave my current round-trip buffering protection, or have none at all? (It is borderline unusable on my system without any kind of buffer managment)
<azonenberg>
As in, we don't touch the data plane at all
<azonenberg>
leave it exactly like what we have
<azonenberg>
refactor just the control plane to be common
<azonenberg>
then re-assess where things stand
<azonenberg>
so each driver will have their own binary data protocol and bridge code just like we do now
<azonenberg>
but they'll mostly share the scpi commands and methods for controlling gain/offset etc
<d1b2>
<louis> Sounds good to me. Do you want me to PR the (mostly-duplicate) code I have now for DSLabsOscilloscope, merge that, and then start a new branch for the refactor/merging?
<d1b2>
<louis> I will push the bridge code to a repo of it's own
<azonenberg>
Yes, I think it makes sense to get that code in mainline now. Generally speaking, at the current level of maturity I consider master to be a development branch
<azonenberg>
new commits to master should add a superset of the current code's features
<azonenberg>
i.e. it's ok to add incomplete stuff as long as there's no known regressions
<azonenberg>
On that note, we should probably start thinking about making a github org for the project vs having it under my personal namespace
<azonenberg>
Maybe i should make a github org "glscopeclient" and you can push the bridge code to a new public repo under that
<d1b2>
<louis> Sounds good
<azonenberg>
then i'll migrate my repos over to that
<azonenberg>
so keep things in your internal repo for the near term, i probably won't get to that tonight
<azonenberg>
send a PR for the clientside code
<azonenberg>
Then for refactoring, how about you start by making the ExternalBridgeOscilloscope class and pulling any methods that are identical across Pico/Digilent/DSLabs drivers into it?
<azonenberg>
as well as shared member variables like the caches for various settings
<azonenberg>
And i'll work on the server side version of that refactoring across the digilent and pico bridges
<azonenberg>
then you can do the same to your bridge a bit later
<azonenberg>
Sound like a plan?
<d1b2>
<louis> Sounds like a plan. I'm going to open that PR and then probably knock off for the night, but I'll get on setting up ExternalBridgeOscilloscope and merging those drivers next :).
<azonenberg>
Excellent
<azonenberg>
Then once the refactored scpi code is tested and verified across all 3 drivers we'll merge it upstream and start thinking about what we want to do as far as a unified binary data protocol
<_whitenotifier>
[GitHub] Mind your words, they are important.
<azonenberg>
ok perfect, that hook is set up too
<azonenberg>
@louis ok so the org is set up. You can start by making the repo under your personal github then you can transfer it under the glscopeclient org
Bird|otherbox has quit [Remote host closed the connection]
Bird|otherbox has joined #scopehal
<monochroma>
o.o @ [GitHub] Mind your words, they are important.
<azonenberg>
monochroma: they throw random sage advice in the test message that goes on the first hit of a new webhook
<_whitenotifier>
[scopehal-waveforms-bridge] azonenberg 1d895ec - Ported core SCPI stuff over to new DigilentSCPIServer class
<azonenberg>
@louis ok i think this is a good stopping point for tonight
<azonenberg>
I have the core SCPI line parsing moved into scpi-server-tools, and the scopehal-waveforms-bridge application now has most of the actual command dispatch in a DigilentSCPIServer class
<azonenberg>
None of the upper layer stuff (common commands like *IDN?) is implemented in the library core yet
<azonenberg>
so that will be the next step
<azonenberg>
I'm going to keep SCPIServer generic, then make a derived class that contains all of our common commands that most bridge servers share
<azonenberg>
then most bridge classes will derive from that
<tnt>
azonenberg: did you find why your trace was 100R and not 50R ?
<azonenberg>
tnt: no, i have not had time to work on that. i plan to cross section the board later in the week
<azonenberg>
this board was actually from a test i ran a few months ago
<azonenberg>
the s-params were awful and i didn't pursue it further at the time
<azonenberg>
didnt put any effort into debugging why
<_whitenotifier>
[scopehal-apps] azonenberg 78a3dfa - Refresh filter graph after loading a saved session if there are no scopes active. Fixes #396.
<_whitenotifier>
[scopehal-apps] azonenberg closed issue #396: When loading a scopesession containing only filter-derived waveforms (no scope) nothing is displayed until you hit trigger - https://github.com/azonenberg/scopehal-apps/issues/396