<_whitenotifier-e>
[scopehal-apps] azonenberg 76f45ab - CheckForScaleMismatch: don't crash or display useless warning message if a filter has mismatched scale
<_whitenotifier-e>
[scopehal-apps] azonenberg cf7219d - Initial work on filter creation from graph editor
<_whitenotifier-e>
[scopehal-apps] azonenberg d79ec53 - Lots of improvements to visual appearance of graph editor
<d1b2>
<azonenberg> Quick test of the filter graph editor. Still more work to do on appearance and things like opening properties dialogs when you double click a node
<azonenberg>
It's definitely not the highest density option available for adapters, but makes them quick to find
<azonenberg>
and i have extra space on the door of the cabinet, spaces for the big bins are what's in short supply
<darthrake>
mhm. we are struggeling to mark especially adapters individually. and in the end its often not quite clear which adapter was used exactly. but one bin per adapter seems excessive as well.
<azonenberg>
So i have dividers, two types per bin
<azonenberg>
i have stick on labels to serialize some of the nicer adapters and have them individually VNA tested
<azonenberg>
which is nice if i have a lot of the same type with, say, different electrical lengths for sma-sma couplers etc
<darthrake>
getting a data matrix lasered onto everything would be nice.
<azonenberg>
i just used my Brady label printer to do a wraparound self laminating label with a 4-digit internal serial number
<darthrake>
this works for most things, true.
<darthrake>
but e.g. those compression sma connectors. not sure how to label those
<azonenberg>
Gonna write a scopehal driver for them?
<darthrake>
if we keep it: sure. if not: maybe :D
<darthrake>
irt testboard: so far it looks alright, but its easy to betray yourself with TRL calibration.
<azonenberg>
yeah i dont have a ton of experience with TRL
<azonenberg>
my PicoVNA normally uses SOLT
<azonenberg>
and then if i need to move the cal plane i'll de-embed the fixture
<azonenberg>
Which is one of the reasons i really want to get an implementation of the IEEE 370 2x thru algorithm in scopehal
<darthrake>
nfbraun posted a few thoughts on 2x thru a while ago. unfortunately the demo unit didn't come with a SOLT kit, and we only have a N kit, no SMA kit. having the reference plane at the end of the cable is quite handy imho.
<darthrake>
actually deembedding parts comes later.
<azonenberg>
Yeah. I have a SMA cal kit for my Pico
<azonenberg>
I normally put the ref plane for measurements at the end of the cable then de-embed to the actual DUT
<azonenberg>
but i need to work on getting better models of de-embedding networks
<azonenberg>
as well as designing some better test fixtures for vna characterization of probes
<azonenberg>
darthrake: anyway, i want to build out more support for VNAs in scopehal over the next few months, although i'm currently focusing on ngscopeclient and not new instrument drivers
<azonenberg>
are you considering other models besides the siglent right now?
<azonenberg>
and i have no personal experience with it
<miek>
i'm curious to know the origins behind that one, it looks like they obtained Tek's TTR500 series when it was discontinued
<azonenberg>
the minicircuits? I dont know
<azonenberg>
my local minicircuits rep gave me a heads up it was on the way a few months before it launched publicly
<azonenberg>
but didnt have any details on specs or origin
<darthrake>
the keysight P9372A series is quite interesting. especially with the economy ecals.
<azonenberg>
Anyone have thoughts on Siglent SPD3303X-E vs Rigol DP832? Looking to set up some LAN controllable power supplies at work. Don't need extreme stability or high resolution readouts or anything
<azonenberg>
this is mostly for emulating wallwarts or batteries on a DUT and having the ability to remotely power cycle
<d1b2>
<david.rysk> I've heard more complaints about poor QC with Rigol
<d1b2>
<david.rysk> poor QC leading to the PSUs frying DUTs
<azonenberg>
Yeah siglent seems the nicer entry level brand
<d1b2>
<david.rysk> I've only heard one report of that with Siglent, and no follow-up
<d1b2>
<david.rysk> meaning, no-follow-up from the person claiming that this happened
<azonenberg>
argument in favor of the rigol: it has afaik 3 fully programmable outputs
<d1b2>
<david.rysk> it seems like Siglent is very interested in fixing such issues
<d1b2>
<david.rysk> Yes
<azonenberg>
the siglent has only two, plus one fixed 2.5/3.3/5V output that is afaik just *there*
<azonenberg>
and has no PC control capability
<d1b2>
<david.rysk> yes it has a hard toggle
<d1b2>
<david.rysk> I got the SPD3033X-E since I take multiple reports of frying DUTs seriously
<azonenberg>
Yeah
<azonenberg>
So you have one already?
<d1b2>
<david.rysk> Yeah, though I haven't used it much
<d1b2>
<david.rysk> That said it interfaces nicely with the software and seems to be solid
<azonenberg>
Can I convince you to write a scopehal driver for it?
<d1b2>
<david.rysk> After I finish setting up the new place probably
<miek>
i've used the DP832A in a previous job and it was great, but i have also seen those complaints - specifically about the outputs turning on briefly when the PSU is switched on
<azonenberg>
yes. that is the biggest argument against it IMO
<azonenberg>
My R&S has none of those issues plus excellent resolution, i think 100 uA below 1A and 1 mA after
<azonenberg>
and 1 mV on the voltage
<azonenberg>
but that is also a $1200 supply
<d1b2>
<david.rysk> Siglent seems to be very interested in learning about such issues and fixing them
<d1b2>
<david.rysk> Rigol, not so much
<azonenberg>
which is hard to justify purchasing in largeish quantities for work
<d1b2>
<david.rysk> and I've heard they're also not very diligent with scopes
<azonenberg>
when we dont really need it
<azonenberg>
yes. i am not a fan of rigol's approach to QA
<azonenberg>
siglent is low cost but not "cheap"
<azonenberg>
they care about quality and do as much as they can to deliver a high quality product given the limited budget
<darthrake>
we are using dp832 since like forever. no complaints but fan noise.
<d1b2>
<azonenberg> How's this look? the node properties dialog - or a subset of it (things like "combobox of input ports" are hidden because they make no sense in this context) is now integrated into each node
<d1b2>
<azonenberg> so unlike in glscopeclient, where the editor would let you spawn the properties dialog but not actually reconfigure the node, you can now do basically everything you'd ever want to do to a filter in the graph editor view
<azonenberg>
So, food for thought: the Siglent SPD3303X-E apparently has "2.5" channels for lack of a better term
<azonenberg>
there are two fully programmable and controllable channels
<azonenberg>
then the third channel has a mechanical switch to select between 3 voltages, a hard wired current limit
<azonenberg>
but soft button/scpi controllable on/off
<azonenberg>
So we need to figure out how to extend the PowerSupply API model to consider asymmetric setups like that
<azonenberg>
there's a test waveform dataset there, let me know if you need more (this is a single waveform, i have hundreds of MB of captures that were too big to dump on github)
<azonenberg>
@david.rysk: not to my knowledge. File a ticket agaisnt scopehal with the request
<azonenberg>
if you can supply test data in .scopesession format and link to a spec, it will aid things
<d1b2>
<david.rysk> is this the case in general with protocols? 🙂
<azonenberg>
Yes. We have a lot of protocols on the wishlist that i can't work on, for example, because i don't have any hardware on hand that speaks it
<azonenberg>
so i have no waveforms to play with
<d1b2>
<WillSlim95> Cheers, Time to spend my newly acquired C++ skills on problems that interest me
<d1b2>
<WillSlim95> Actually can you share those waveforms
<d1b2>
<azonenberg> @WillSlim95 see above
<azonenberg>
build glscopeclient, clone that repo somewhere, and open dsi.scopesession
<d1b2>
<WillSlim95> I meant the hunders of MB captures
<azonenberg>
oh
<azonenberg>
so um, its a bit more than i thought
<azonenberg>
I have a total of three big captures
<azonenberg>
one at 5 Gsps with shallow memory, 573 MB total
<azonenberg>
one at 20 Gsps with shallow memory, 573 MB total
<azonenberg>
and one at 5 Gsps with deep memory, 5.6 GB
<azonenberg>
total is 6.8 GB
<azonenberg>
to my knowledge there are no ECC errors anywhere in the dataset, but you could easily flip some bits in a debugger or something for testing
<azonenberg>
waveforms in all case are DSI-2 from a raspberry pi talking to the attached LCD
<azonenberg>
let me see how small the dataset is when i tar it up
<azonenberg>
(these waveforms are uncompressed and tend to compress nicely)
<azonenberg>
related: we have D-PHY and DSI decodes, but no CSI decode currently
<azonenberg>
mostly because I don't have any hardware with a CSI interface handy to instrument
<azonenberg>
we also have no M-PHY or C-PHY decodes for the same reason
<azonenberg>
@willslim95: ok it's 1.2 GB gzipped. Dumping it on my web server now