<d1b2>
<dannas> I noticed that the Tektronix driver is the only scophal driver to use queued SCPITransport API.
<d1b2>
<dannas> I wonder how different scope drivers differs with regards to 1) allowing multiple concurrent requests and/or 2) batching of requests.
<d1b2>
<dannas> For the Siglent driver which uses SCPILxiTransport I just rely on the immediate api: SendCommand, ReadReply, ReadRawData..
<d1b2>
<dannas> The SCPITransport class has a virtual IsCommandBatching method which is only set to true in a few derived classes. Oh, well, I just got side-tracked looking at that code.
<azonenberg>
dannas: the queued API is kinda experimental and I was using the tek to prototype it
<azonenberg>
as far as command batching goes, some transports let you send multiple commands in a single API call separated by semicolons
<azonenberg>
others do not
<azonenberg>
in particular VICP does not support it IIRC
<azonenberg>
And then some SCPI devices, like Tek MSO5/6, are very pedantic about requiring one command to complete before you can send another
<azonenberg>
and if you send one while another is in progress it will drop the old one, hang, give an error, or worse
<azonenberg>
while most smarter ones just won't read the queue until the previous command is done
adamgreig is now known as agg
<d1b2>
<dannas> @azonenberg Ok, SICP seems to not quite have turned out the way it was originally planned. One protocol for uniform access to test equipment. 🙂
<d1b2>
<dannas> i'll just ignore the queued API then if it's experimental.
<d1b2>
<dannas> I always misspell SCPI for SICP.
<d1b2>
<dannas> glanses at bookshelf
<azonenberg>
I consider SCPI a standard in the same way as JTAG
<azonenberg>
it describes the general syntax of how to format a "command""
<azonenberg>
and a universally recognized command for "WTF are you?"
<azonenberg>
everything on top of that is application specific
<d1b2>
<dannas> Oh, I wasn't aware that JTAG specifies so little besides the physical signals that should be present. https://blog.senr.io/blog/jtag-explained There is so much to learn for me.
<azonenberg>
yeah i mean jtag specifies the boundary scan stuff
<azonenberg>
which was the original use of jtag, and yet i so rarely see that actually used
<azonenberg>
vs running protocols like xilinx fpga jtag or ARM ADI over it
<azonenberg>
dannas: BTW, there should be reasonably good Doxygen coverage of at least core base classes in libscopehal
<azonenberg>
anything you find is not well documented should be fixed
<azonenberg>
(glscopeclient UI side code is far less well documented, that's something I definitely would like to spend more time on eventually)
<_whitenotifier-8>
[scopehal-apps] azonenberg 1fd82ec - WaveformArea: don't process spurious resize events when changing focus if new size is same as current size
<azonenberg>
OK so after fixing a few bugs causing the eye to get cleared more often than it should...
<azonenberg>
Here's a 1.25 Gbps 8B/10B stream through a bunch of test fixtures and an AKL-PT5
<electronic_eel>
azonenberg: have you considered measuring the lecroy D-probe tip-modules or the whole d-probe including tip with a vna to see what kind of deembedding they do in software versus how flat the signal straight from the probe is?
<azonenberg>
electronic_eel: I would love to. It's nontrivial
<azonenberg>
I can use scopevna to measure the combined response of probe+scope
<electronic_eel>
what kind of connectors do they use between the tip and the amplifier?
<azonenberg>
That's a very good question
<azonenberg>
They look similar to SMPM. but not identical
<azonenberg>
Until I figure out what is, i can't mate with them
<azonenberg>
I did measure a D400A-AT probe (handheld browser amplifier, not separate amp/tip) with a picovna using some hacks to supply power to it
<electronic_eel>
ouch. did lecroy really develop their own high speed connector just for these probes? i consider designing such a connector a non trivial task
<azonenberg>
I think it's likely something standard-ish but obscure
<azonenberg>
e.g. they use BMA for ProLink
<azonenberg>
which, while "standard", i've never seen anywhere else
<azonenberg>
(they might also *be* SMPM, just a slightly different mating geometry shape than the ones I've seen before - they're very close. but not close enough i want to risk mating to a several-k$ part without being more sure)
<azonenberg>
anyway, the D400A-AT is -8.5 dB at ~DC. dips down to -10.9 dB at 1.14 GHz
<azonenberg>
then up to -6.34 dB at 2.22 GHz
<azonenberg>
flattens out a bit and holds around -10 dB from 3 to 3.5 GHz
<azonenberg>
then dips down to -13.74 dB at the nominal 4 GHz BW limit
<azonenberg>
then it actually peaks up again to-8.5 dB at 4.7 GHz before falling off hard
<electronic_eel>
i guess deembedding that kind of nonlinearity in software is still feasible
<azonenberg>
i mean you definitely lose dynamic range, but yeah its doable
<azonenberg>
making a passive probe with this kind of response is hard especially if you don't mandate a deembed to meet spec
<azonenberg>
anyway, i'm confident with some small tweaks I can make this a 4 GHz probe
<azonenberg>
and while the AKL-PT2 has higher B/W this should be much more durable, maintainable, and easier to use
<azonenberg>
since if you break the resistor you can just solder a new one in, and it natively supports variable tip spacing unlike the PT2
<electronic_eel>
yeah, from the usability and physical design the PT5 looks great
bvernoux has quit [Read error: Connection reset by peer]
<azonenberg>
yeah. i also found a cable from amphenol that looks excellent with it from a mechanical perspective
<azonenberg>
super thin and flexible
<azonenberg>
it is a little lossy but not unreasonably so, very much de-embeddable