<azonenberg>
one of us should work on this soonish
<azonenberg>
since we're now gonna be up to 3 drivers using a similar structure
nelgau has joined #scopehal
<d1b2>
<louis> As a strategy question, we might want to think about how to maximize code reuse for drivers where we're writing both the SCPI client and server
<azonenberg>
Yes. I think we are going to want to write some kind of scpi server library
<azonenberg>
until like 2 weeks ago, pico was the only such driver we had
<azonenberg>
now all of a sudden we have 3 (pico, digilent, and dscope/sigrok)
<azonenberg>
more high level code sharing WRT command apis and such we can think about later
<azonenberg>
but i think this transport plus the protocol layer server side would be a good start
<monochroma>
how much code reuse can be done if the majority of scopes violate the protocols each in their own very unique ways?
<azonenberg>
monochroma: we're talking about where we have a sdk or RE'd protcol
<azonenberg>
and write our own socket server to provide network transparency
<monochroma>
ah, so this would be the the "abstraction layer" ?
<azonenberg>
Yeah. well, kinda
<azonenberg>
some is clientside
<azonenberg>
for example the pico driver has to know which channels can be enabled given a particular sample rate
<azonenberg>
the digilent driver takes samples as fp64 rather than as raw adc codes
<azonenberg>
these bridges are however similar enough that *some* code can definitely be shared
<azonenberg>
Both client and server side
<d1b2>
<louis> Thinking out loud, I wonder how much it helps/hurts for the bridges to be speaking SCPI as opposed to something that more directly matches the scopehal Oscilloscope interface
<azonenberg>
Soooo
<azonenberg>
now you're getting to a more fundamental question
<azonenberg>
I have been considering building a network abstraction layer for an arbitrary Oscilloscope
<d1b2>
<louis> slash if our network transparency might be better achieved by some RPC-like way to "tunnel" to another instance
<d1b2>
<louis> ah
<azonenberg>
which would essentially be a socket wrapper around that API
<d1b2>
<louis> and then implement pico, digilent, ds/sigrok directly as Oscilloscopes w/o the tunnel, and then do tunneling at a higher layer?
<azonenberg>
Yes, that is a potential way of doing it
<azonenberg>
But i think much of that would be easy to refactor if/when we decided to do it
<d1b2>
<louis> I was thinking about that approach. It's conceptually neat, but does run into possible licensing risks if scopehal directly links with manufacturer SDKs/GPL code.
<azonenberg>
this is why scopehal supports plugins
<azonenberg>
you would implement each of those drivers as a separate binary module
<azonenberg>
a separate distro package and everything, with its own license
<azonenberg>
and load at run time into either glscopeclient or a bridge server application
<d1b2>
<louis> yeah, that'd be a neat solution
<azonenberg>
anyway, i think it's a real possibility longer term but not the best use of our resources at this time
<azonenberg>
especially since the Oscilloscope API is somewhat in flux still
<azonenberg>
there's also challenges around things like caching
<azonenberg>
and more importantly cache invalidation
<azonenberg>
the Oscilloscope API tries to be fast and avoid round trips when possible
<azonenberg>
If/when we do such a thing, we could port over one bridge/driver at a time and not break anything else
<azonenberg>
This is the kind of thing that would need to be done in combination with some other broader API cleanups, like adding write queueing so that you don't have to wait for acquisition of a mutex to call a Set() method
<azonenberg>
if you don't need any data back from the scope
<azonenberg>
right now if you call e.g. SetChannelOffset() in the middle of a waveform download it blocks until you get the mutex
<azonenberg>
vs queueing the write and sending in a background thread once the download is done
<_whitenotifier-e>
[scopehal] azonenberg 2341209 - LeCroyOscilloscope: do not report 1M ohm coupling as available when a ProLink input is active. Fixes #562.
<d1b2>
<dannas> I can apply a threshold filter, and then the buses->UART option is available but that gives me a messages list filled with empty data. But a step forward.
<d1b2>
<dannas> Hm, seems like I can't remove that dialog now. I could do it before.
<d1b2>
<dannas> Oh, there was another dialog for setting the baudrate of the decode hidden behind it. When I moved the procol analyzer popup I could fill in the baudrate.
<d1b2>
<dannas> Hm, but how do I specify data length, parity and stop bits?
<d1b2>
<dannas> It would be cool if the decoded data would show start and stop bits. And If I could select to show the data bytes as hex/ascii. Maybe you can, but I'm just not finding it.
<d1b2>
<dannas> Hm, and the protocol analyzer popup window shows the decoded data as c0 c0 ... Is it looking at the UartClockRec channel?
<d1b2>
<dannas> Found https://github.com/azonenberg/scopehal/issues/33 for allowing other configurations than 8N1. If there is interrest I can look into adding display of start/stop markers and allowing other modes than 8N1 and adding an option for displaying data as pure hex.
<azonenberg>
As of now the uart decode only supports 8N1, yes
<azonenberg>
i have nothing that sends traffic in any other mode so there was no point
<azonenberg>
The UART clock recovery filter is a specialized tool that's only useful for doing eye patterns and other odd stuff
<azonenberg>
As far as showing start/stop bits that is not currently an option
<azonenberg>
i'd take a PR if someone wanted to work on it
<azonenberg>
in general the uart decode is one of the oldest ones in the library
<azonenberg>
it was built probably a decade ago and not touched since other than minimal refactoring when API signatures changed
<Degi>
Is scopehal that old? o.o
<azonenberg>
Degi: libscopehal and the original non-GPU-accelerated scopeclient were originally developed for use with an internal logic analyzer i designed to replace ChipScope because i was a starving college student with no budget for a ChipScope license
<azonenberg>
and then i added support for my rigol ds1102d
<_whitenotifier-e>
[scopehal-waveforms-bridge] azonenberg f0fa9b2 - DEPTHS? command now correctly reports available memory depths. Added more error checking. Added arguments to specify device/configuration in use
<_whitenotifier-e>
[scopehal] azonenberg 50ce94d - DigilentOscilloscope: detect model in use, don't try to enable AC coupling on anything but AD Pro. See #410.
<azonenberg>
filter names are getting way too long with any kind of complex filter graph
<azonenberg>
The two options i see are to either figure out some kind of "smart" naming that adds ellipses to only show a subset of a very long name, and decides what it thinks is most important for you to see while keeping the displayed name short
<azonenberg>
or to just switch to sequential names like Eye1, ChannelEmulation3, Noise2, etc
<azonenberg>
in either case of course you can override manually
<azonenberg>
Also I have preliminary production qty pricing for AKL-PT5s, assuming I go with TU872 instead of FR408HR as the substrate: at qty 500, $2.50 each + $250 tooling, $100 shipping. That's $1600 total or $3.20 per unit amortized cost
<azonenberg>
for comparison, doing them on OSHPark 4 layer is a lot cheaper - 40 cents each on the normal 4 layer panels, and even less on medium run
<azonenberg>
but then i have the mouse bites i need to sand off, plus some stray copper routing around the connector
<azonenberg>
So i'll need to figure out how long the sanding takes and whether it's worth paying a fair bit more to get them individually routed
<electronic_eel>
what do the smpm to sma cables you selected cost?
<electronic_eel>
wow, how that price goes down with quantity. didn't expect that for cables
<azonenberg>
then there's the "foot" board which is cheap, I will probably get those made in china on generic fr4. 20 cents each @ qty 500, plus $150 tooling, $100 shipping
<azonenberg>
so $350 for 500 or 70 cents including shipping and NRE
<azonenberg>
the PCB mount SMPM is $8.44 @ qty 10 at digikey, this drops to $7.55 @ 100, $6.32 @ 500
<electronic_eel>
and then something like a 10-pack of the custom resistors?
<azonenberg>
Then there's the tip resistors which are around $8.60 each @ 100 (MOQ)
<azonenberg>
I plan to ship one with each probe and sell spares separately
<azonenberg>
i dont want to drive up the price by shipping spares with each one
<azonenberg>
maybe one spare included
<azonenberg>
anyway, so in moderate volume we're looking (using the higher price assuming I use the china fab w/ impedance control for the probe itself)
<electronic_eel>
yeah, with $8.60 not forcing too much spares on the buyer is reasonable
<azonenberg>
$3.20 main PCB + $64.40 cable + $0.70 foot PCB + say $0.10 wire to connect them + $7.55 SMPM + $8.60 resistor + possibly a tiny 0201 on the PCB which i'll ignore
<azonenberg>
about $85 BOM. plus possibly a 3d printed protective storage/shipping cap over the probe tip to protect the resistor, i have a few concepts but nothing completely designed yet
<azonenberg>
i may just ship it in a little foam lined esd box or something
<electronic_eel>
no fancy rf rated 0201 resistor on the pcb?
<azonenberg>
so, for this i actually want a little bit of parasitic C
<azonenberg>
it helps flatten the response of the tip resistor
<azonenberg>
however, that is assuming I use the 100 ohm
<azonenberg>
if i use the 450 ohm tip resistor i don't need an 0201 on the pcb at all
<azonenberg>
i was unable to get engineering samples of the 450 so i ordered a min prod lot of 100 of them
<azonenberg>
when they get in, i'll throw them on the VNA and we'll see if they work better than the 100 + 0201 or not
<azonenberg>
and start making probes using whichever combo works better
<azonenberg>
i know I can get at least ~5.3 GHz BW with what i have now
<Degi>
Is there a reason to use TU872 instead of something like RO4350B?
<Degi>
Hmm, epsilon_r vs temperature might be interesting to look at for cal stability
<Degi>
Maybe for Issue 281 we could keep the name of the last applied function and shorten the names of the functions before that by only keeping the uppercase letters and numbers
<azonenberg>
TU872 is cheap, comparable Df to FR408HR, and the run is very short
<azonenberg>
the transmission line from tip to connector is like 8mm long
<azonenberg>
so an expensive microwave material is probably not necessary
<azonenberg>
i do not think dielectric loss in the probe head is a major contributor to the performance of the PT5
<Degi>
Hmm okay, that is very short
<Degi>
I wonder how that compares to just soldering the resistor to the connector
<azonenberg>
that's impractical mechanically
<azonenberg>
especially considering need for ground wire and such
<azonenberg>
Also i got prices from Corstat for their foam lined cardboard IC shipping boxes
<Degi>
Hmm, usually you can solder to the connector body, though not sure how the fancy connectors compare to the cheap SMAs I usually use where I don't care too much about performance
<Degi>
neat
<azonenberg>
$2-3 each for the sizes i'm considering @ qty 100
<azonenberg>
they also offer custom dissipative vacuum formed plastic liners which would be really cool but outside my near term budget (something like $2.5K NRE)
<azonenberg>
but plausible longer term
<Degi>
Huh, they cost that much? Sometimes I get shipped a few with a single IC inside from mouser or so
<azonenberg>
mouser probably buys >> 100 of them
<Degi>
Is shaped foam an option too? Like cutouts in the foam to put the parts into
<azonenberg>
It is, i didn't ask about setup fees for that
<azonenberg>
i think i would go for vacuum formed plastic if i went to anything custom
<azonenberg>
near term i can hand cut the foam if i see a need for that
<azonenberg>
the volumes are low enough and the planned sale price high enough that i can afford a fairly labor intensive manufacture process
<Degi>
Vacuum formed plastic seems like it'd rattle around a lot
<azonenberg>
yes but thats fine, you just want to avoid forces on the tip PCB
<azonenberg>
on the tip resistors*
<azonenberg>
the idea is to use other parts of the probe to support it
<azonenberg>
so it can rattle a bit but not smash the tip
<azonenberg>
Anyway, $2-3 per shipping/storage box is of no consequence when we're looking at close to $90 BOM in low volume
<azonenberg>
it's a few percent increase
<azonenberg>
re #281 the details of how we elide long names is a different question
<azonenberg>
the fundamental question is whether it's worth even trying
<azonenberg>
vs just having the name of the filter block and a sequential ID
<azonenberg>
that the user can then edit if they want
<azonenberg>
Has anybody else seen strange behavior around the file|close command?
<azonenberg>
sometimes when i close a session and connect to a new instrument i don't get good trigger behavior
<azonenberg>
it acts like i never armed the trigger
<azonenberg>
not yet clear what the root cause is
<azonenberg>
steps to reproduce: open demo scope, leave trigger running
<azonenberg>
file|close
<azonenberg>
reopen demo scope
<azonenberg>
seems it doesnt matter whether you close the sessio nwith trigger armed or not