<_whitenotifier>
[scopehal-waveforms-bridge] azonenberg 7198cfa - DigilentSCPIServer now derives from BridgeSCPIServer
<azonenberg>
louis: when you get a chance have a look at scopehal-waveforms-bridge and scpi-server-tools
<azonenberg>
let me know if you think this looks good so far
<azonenberg>
i have basically everything refactored except the commands that actually set properties of the instrument
<azonenberg>
hoping to get that taken care of tomorrow
<azonenberg>
then i'll do the pico bridge the same way
bvernoux has joined #scopehal
<d1b2>
<louis> Yeah, that looks good so far :). The only thought I had looking over it is that GetChannelID should probably return -1 on failure (or use optional) because 0 is a valid channel on some devices (including the DSCope)
<azonenberg>
it returns a size_t right now so i might want to change that. and the channel ID it returns is implementation defined
<azonenberg>
but normally it's 0...N-1
<azonenberg>
not the display channel ID
<d1b2>
<louis> Sure, I just mean that failing to parse should probably not return 0 since that's a valid index
<d1b2>
<louis> You mean, you intend to break out e.g. FORCE -> a ::DoForceCommand and so?
<d1b2>
<louis> That makes sense to me, and means the logic for validating/interpreting channels/arguments can live in the shared tools code
<azonenberg>
welll
<azonenberg>
channel names are vendor dependent
<azonenberg>
e.g. pico channels are letters not numbers
<azonenberg>
some use Cx and others CHx
<azonenberg>
so converting a channel name to an index is very much going to be a derived class thing
<azonenberg>
all of the *other* parsing code i can share
<azonenberg>
But yes, that is the plan
<azonenberg>
all of the common commands will turn into methods in the base class that you just override
<azonenberg>
then you add your own parsing for special scope-specific commands
<d1b2>
<louis> 👍
<azonenberg>
and then we'll figure out what we want to do clientside
<azonenberg>
in terms of refactoring common stuff
<d1b2>
<louis> The parsing the name, yes, but the logic of 'don't call DoAttenuateCommand' unless they passed a valid channel name can be shared
<azonenberg>
oh, yes
<d1b2>
<louis> clientside here meaning how much of the logic from Digilent/DSLabs/PicoOsc we can pull into RemoteBridgeOsc, yeah?
<azonenberg>
Correct
<azonenberg>
i also have one more driver using the same arch
<azonenberg>
that is not upstreamed yet
<azonenberg>
i'm working on it in collaboration with a vendor who is keeping stuff under wraps until their firmware side is ready to release
<azonenberg>
the server side is closed source and not based on the same code as what we're using for our bridges, but uses a very similar dual socket architecture
<azonenberg>
client side is very similar to those 3 drivers
<azonenberg>
so may be able to share some code too
<azonenberg>
that's a lower priority, though, than the ones we control both sides of
<d1b2>
<louis> Oh that's very exciting!
<d1b2>
<louis> Write useful enough code and oops! now you're a standard 🙂
<azonenberg>
lol
<azonenberg>
The protocol is not 100% frozen yet, they're still adding commands
<azonenberg>
so we have room to put some influence in
<azonenberg>
i'm the only client for the protocol so far as it's unreleased
<azonenberg>
so if we make changes to our own protocol there's room to potentially push some of that into theirs
<_whitenotifier>
[scopehal-docs] azonenberg a892fec - Clarified a lot of stuff in channel emulation filter docs. Documented de-embed filter. Fixes #17.
<Degi>
Is there a reason why DDR often uses a special termination voltage instead of thevenin termination to the rails?
<azonenberg>
you mean split termination with a resistor each going high and low?
<azonenberg>
Yes. That has a high DC current consumption
<azonenberg>
imagine 80 ohms from vdd to each DQ pin and 80 ohms from DQ to ground
<azonenberg>
that's 160 ohms per pin, on a 32 bit bus that's 5 ohms equivalent if my mental math is right
<azonenberg>
which means at say 1.35V you have 270 mA flowing constantly through the terminators heating things up
<Degi>
I mean that doesn't sound too bad, though with 80 ohms you'd have 40 ohms termination impedance (is that right? never looked that up)
<azonenberg>
That's common, yes
<azonenberg>
and 270 mA at 1.35V is 365 mW. just for 32 DQ pins
<Degi>
Hmm I see, I guess a push pull regulator isn't that expensive and some hundred mW is probably bad, at least for mobile devices etc. which need low current consumption
<azonenberg>
that's 670 mW for a 64-bit sodimm in a laptop
<azonenberg>
and that's just for the DQ pins, not the command/address
<Degi>
Oh right, it also needs to power that when sleeping
<azonenberg>
exactly
<azonenberg>
well... in the simple split termination strategy yes
<azonenberg>
most modern implementations use on die terminations that can be selectively enabled when the bus is active
<azonenberg>
so in between accesses or when sleeping they're off
<azonenberg>
(in addition to not using split terminations)
<azonenberg>
ESD coated cardboard box with foam insert. the stock foam is full length, I cut it down so it only pinches the support wire
<azonenberg>
which leaves the probe head floating in air not touhcing anything
<Degi>
Maybe you could rotate it 90° and pinch the ground plane too and put a cut in the foam for the wire to be in, that way it would have more support
<azonenberg>
well the thing is, the wire can bend to different shapes
<azonenberg>
any kind of custom cut cavity would be hard to get it back into without re-bending to the same exact curve
<Degi>
Oh, I mean just a slit which the wire sits in
<Degi>
Like cut the top foam block in half but leave both parts attached
<Degi>
(As long as the ground wire is in a plane it should fit)
<azonenberg>
can you sketch out what you have in mind?
<azonenberg>
the ground foot is perpendicular to the plane the support wire is curved in
<azonenberg>
i'd need a slit in the foam at both top and bottom sides for the foot
<azonenberg>
which i tried, initially, but it was slow and hard to get it shaped right
<azonenberg>
to keep costs low, i'd rather do something like this
<azonenberg>
which is two knife cuts for the top half (already glued down), one scissor cut for the bottom half (normally loose), and a piece of double sided tape to hold the bottom half down
<azonenberg>
Can you send a transfer request to move that to the glscopeclient organization?
<azonenberg>
i want to keep all of the stuff under one roof, i'm gradually moving my repos over there too
<d1b2>
<louis> Request made
<d1b2>
<louis> It's not pretty; I'll go over it again and use some actual locking primitives when I switch it to use scpi-server-tools
<azonenberg>
Ok
<azonenberg>
That was going to be my next suggestion: start that refactoring
<azonenberg>
i want to get a second driver using it as early as possible so that we can iron out any kinks in the APIs etc
<azonenberg>
Make it the same as the digilent bridge now, where most/all of the queries are handled by the base class but all of the set functions and waveform processing are done in your driver class
<azonenberg>
then i'll get the pico driver to that stage as well
<d1b2>
<louis> Sure. RE: the BridgeOsc code, we probably want to make it query for RATES?/DEPTHS? as well as INTERLEAVED:RATES? and INTERLEAVED:DEPTHS? and INTERLEAVED:CONFLICTS? if we want that to be fully generic.
<d1b2>
<louis> otherwise, we could handle that in the driver per-family after identifying hardware, but that seems more brittle
<azonenberg>
Let's keep that per-driver for the short term
<azonenberg>
but with the intention of abstracting it more in the future
<azonenberg>
the nice thing about this sort of refactoring is it's easy to do piecewise
<d1b2>
<louis> rn the rates and depths are sourced over SCPI from the bridge, but none of the bridge drivers support/correctly report interleaving
<azonenberg>
we do the big sweeping architectural change (moving from a single thread function to a class instance and having everything in members there) once
<d1b2>
<louis> so we'll have to cross that bridge at some point
<azonenberg>
Yeah
<azonenberg>
Pico has no explicit user-facing interleaving now for example
<azonenberg>
it's all done internally based on the sample rate / channel count / bit depth you request
<azonenberg>
This may end up being one of things we do per driver, idk yet
<azonenberg>
I want to start by pulling out all of the easy, common, shared code
<azonenberg>
then worry about how to abstract the stuff that is more unique
<d1b2>
<louis> Yeah, that makes sense. Next thing I get up to will be hacking around on the dslabs bridge to use the -tools
<azonenberg>
Yeah
<azonenberg>
and i'll do the same to pico tonight
<azonenberg>
so at that point we will have all 3 extant bridges using the same incomplete version of the server library
<azonenberg>
then i'll start implementing the set methods in -tools
<azonenberg>
and we'll do the same
<azonenberg>
once all of the really basic stuff is done, we'll decide what additional commands we want to have be common