azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/glscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Degi has quit [Ping timeout: 250 seconds]
Degi has joined #scopehal
<_whitenotifier-e> [scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±9] https://github.com/glscopeclient/scopehal-apps/compare/76c0119cf87c...d79ec5350529
<_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
<d1b2> <azonenberg> but it's coming along
massi has joined #scopehal
bvernoux has joined #scopehal
massi has quit [Remote host closed the connection]
<darthrake> azonenberg: how do you keep track of rf-adapters? classic assortment box? Or any tricks?
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark has quit [Quit: Bridge terminating on SIGTERM]
mikolajw has quit [Quit: Bridge terminating on SIGTERM]
fridtjof[m] has quit [Quit: Bridge terminating on SIGTERM]
mikolajw has joined #scopehal
<azonenberg> darthrake: I store all of my adapters and cables in a bin organizer cabinet
whitequark has joined #scopehal
fridtjof[m] has joined #scopehal
jevinskie[m] has joined #scopehal
<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
<darthrake> siglent vna demo unit arrived today. ui is suprisingly usable so far. 100mm beatty in TDR: https://dsh.re/2a0c5f https://dsh.re/636be0
<azonenberg> ooooh shiny test board
<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> https://www.minicircuits.com/WebStore/Vector-Network_Analyzer.html looks interesting, athough it does cost more than the equivalent Pico
<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.
azonenberg has quit [*.net *.split]
monochroma has quit [*.net *.split]
azonenberg has joined #scopehal
monochroma has joined #scopehal
<_whitenotifier-e> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±10] https://github.com/glscopeclient/scopehal-apps/compare/d79ec5350529...0e7619d80301
<_whitenotifier-e> [scopehal-apps] azonenberg 0e7619d - Continued work on filter graph editor. Added properties adjustment within nodes.
<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
<_whitenotifier-e> [scopehal] azonenberg opened issue #718: PowerSupply: add feature flags for controllable voltage/current limit - https://github.com/glscopeclient/scopehal/issues/718
<_whitenotifier-e> [scopehal] azonenberg labeled issue #718: PowerSupply: add feature flags for controllable voltage/current limit - https://github.com/glscopeclient/scopehal/issues/718
<d1b2> <WillSlim95> Any low hanging fruits (issues) that can be worked on by someone who doesn't have access to the HW?
<azonenberg> willslim95: Hmm, there's always protocol decode type work
<azonenberg> a decoder for I2S has been on the wishlist for ages but nobody's put the time in to implement one properly
<azonenberg> i think we have waveform data files that could be used for offline development
<azonenberg> there's some little fixes to existing filters, for example the MIPI DSI header error correcting code is ignored
<azonenberg> we have the data, and we have the FEC checksum
<d1b2> <WillSlim95> This one looks interesting ? Any keywords links?
<azonenberg> but we just blindly assume it's correct
<azonenberg> for which one?
<d1b2> <WillSlim95> For this one
<azonenberg> For the DSI? let me find the ticket number
<azonenberg> ok so here's the ticket https://github.com/glscopeclient/scopehal/issues/328
<d1b2> <david.rysk> do we have support for TI's SDQ protocol?
<d1b2> <WillSlim95> Great let me try to understand the source code streucture and open up my MIPI spec
<d1b2> <WillSlim95> doc
<d1b2> <david.rysk> (a 1-wire protocol used in their battery controller chips)
<azonenberg> in that example, ecc_in is the data that needs to be checksummed and s.m_data is the FEC code value
<azonenberg> but we always output a TYPE_ECC_OK symbol regardless of the actual observed data
<azonenberg> I don't think actually correcting errors is super important, what matters more is detecting if the check value doesn't make sense
<d1b2> <WillSlim95> Ah so for now it is just assumed that all the in data is correct, which is not ideal
<azonenberg> but if you want to be extra fancy, backing up in the output waveform and correcting the header fields would be totally doable
<azonenberg> as a minimum detecting the corruption is needed though
<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
<azonenberg> will send you a link shortly
<azonenberg> Let me know when you've downloaded so I can delete it, disk space on that box is a little tight
<azonenberg> Hmmm, integrating node proeprties into the node is proving to be "here be dragons" territory
<azonenberg> anything like a color chooser or combo box that produces a popup has horrible coordinate transformation issues
<_whitenotifier-e> [scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±8] https://github.com/glscopeclient/scopehal-apps/compare/0e7619d80301...543f24c90757
<_whitenotifier-e> [scopehal-apps] azonenberg 159431d - WIP on deferred combo boxes. Likely going to revert it.
<_whitenotifier-e> [scopehal-apps] azonenberg 543f24c - Integrated node properties as popup menu. Works much better.
<d1b2> <azonenberg> Coming together nicely now