azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-cmake, https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal | Logs: https://freenode.irclog.whitequark.org/scopehal
<awygle> hey speaking of *hal, what's the situation with jtaghal? did that get dropped or is development ongoing?
<azonenberg> It still exists, i still actively use it
<azonenberg> there have been few commits recently because i haven't needed any new features, it does the job just fine for me
<azonenberg> arm device support could certainly use more work but i mostly use it with fpgas and custom stuff and it handles those fine
<azonenberg> it mostly works with FTDI or Digilent dongles but that's all i have in my lab
<azonenberg> at this point i consider it a relatively mature, stable tool that could always accept new features but is at the point that i've been dogfooding with it for the past few years and have saw little need to improve
<awygle> can i use it to program a SPI flash attached to an FPGA?
<azonenberg> I dont think that's currently implemented. I had an antikernel bitstream for that that used my antikernel in-system debug protocol
<azonenberg> you can runtime jtag program the fpga for sure
<azonenberg> Let me check
<azonenberg> yeah indirect programming is not currently available. on the rare occasions i need to do that i use vivado, but most of my work these days is R&D and i rarely even touch flash
<azonenberg> the big problem is that you basically need to have a library of dozens of bitstreams for different chips implementing some kind of in system programming bridge
<awygle> yeah, that's basically where openocd falls too
<awygle> seems like it should be doable with extest+sample/preload
<monochroma> i have forgotten, how does the xilinx toolchain deal with programming an external flash, do they have a specific JTAG end point for accessing the flash, are they loading a bitstream onto the FPGA to talk to the flash, or are they bit banging the interface in boundry scan mode?
<azonenberg> Xilinx loads a bitstream onto the fpga
<azonenberg> I havent looked into what that bitstream does but presumably it uses the same BSCANE2 / BSCAN_SPARTAN6 etc endpoint that chipscope et al use
<azonenberg> awygle: so actual boundary scan is completely unsupported in jtaghal
<azonenberg> it's not something i've ever had a use for
<azonenberg> and for flash programming, having to push Kbits of pad configuration to write 4 pins is sooooo slow as to not be worth doing
<azonenberg> like, it will work
<azonenberg> but it'd take forever
<azonenberg> you'd be looking at a few Kbps with jtag at Fmax
<awygle> better than a thousand proxy bitstreams
<azonenberg> Depends on your definition of better
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
m4ssi has joined #scopehal
<monochroma> azonenberg: hmmm might need to add to the pdf about needing to install texlive
<monochroma> azonenberg: /home/user/src/scopehal-cmake/src/examples/freqresp/main.cpp:38:10: fatal error: ../scopehal/LeCroyVICPOscilloscope.h: No such file or directory
<monochroma> #include "../scopehal/LeCroyVICPOscilloscope.h"
<monochroma> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<monochroma> compilation terminated.
<monochroma> looks like scopehal-cmake's sub modules are out of date?
<monochroma> hmm so if i checkout master in lib and src that should update those sub modules to the latest
<monochroma> but i get this error on build now:
<monochroma> /home/user/src/scopehal-cmake/src/psuclient/main.cpp:174:84: error: no matching function for call to ‘SCPISocketTransport::SCPISocketTransport(char [128], int&)’
<monochroma> auto psu = new RohdeSchwarzHMC804xPowerSupply(new SCPISocketTransport(host, port));
<monochroma> (the previously mentioned error is gone now)
<monochroma> manually built just glscopclient, i get a binary, and it does connect to my scope
<monochroma> something isn't quite right though
<monochroma> when i try to add an eye pattern all traces go blank and i get this message on the console: (glscopeclient:29594): Gtk-CRITICAL **: 06:53:10.319: gtk_box_reorder_child: assertion 'old_link != NULL' failed
<_whitenotifier-3> [scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/Jv6uG
<_whitenotifier-3> [scopehal-cmake] azonenberg 5e8f8af - Updated to latest submodules
<azonenberg> monochroma: how does that look?
<azonenberg> LeCroyVICPOscilloscope is gone
<azonenberg> oh, hmm - interesting maybe i never built the other scopehal-apps binaries
<azonenberg> I'll fix psuclient once i've finished the refactoring
<azonenberg> the connection string format is getting redone
<azonenberg> i've been doing "make -j" from the glscopeclient bin directory and i guess that doesn't do a rebuild of the rest of scopehal-apps
<sorear> …just -j?
<azonenberg> sorear: i'm on a dual socket 16 core / 32 thread xeon box with 192GB of RAM
<azonenberg> I can "make -j" a linux kernel in about 90 seconds
<azonenberg> i think a full build of kicad is a little slower but not much
<azonenberg> Got a quote back from the fab, finally. 380 USD for 10pcs of the probe test board. Not bad for impedance control on Rogers :D
<azonenberg> Placing the order now
<awygle> yeah that's not bad
<awygle> what's the dimensions?
<azonenberg> About 25 x 75 mm so ~1x3 inches
<awygle> ah ok. still, pretty good for low qty
<azonenberg> SMA to 50Ω precision load, SMA to 50Ω load with a probe across the load
<azonenberg> SMA to probe, no termination
<azonenberg> SMA to SMA, 20.8mm thru
<azonenberg> SMA to SMA, 35.8mm thru (15mm delta)
<azonenberg> SMA to open circuit, 6mm stub
<azonenberg> SMA to short, 6mm stub
<azonenberg> so you have your choice of SOLT or TRL standards to de-embed the SMA launch, a thru line you can drop the probe across to measure loading effects, as well as direct SMA to probe with and without termination to do S-parameter measurements of the probe itself
<awygle> i should get a quote from multech for my next board
<awygle> just to see
<azonenberg> They're not going to beat e.g. JLC for low volume on standard-ish specs
<awygle> my next order is qty 1000 or more
<azonenberg> but i've been very happy with their quality, and for high end stuff like i tend to do they're a great choice
<azonenberg> I havent done volume quotes enough to be able to comment either way
<awygle> which yeah is still fairly low volume i guess
<azonenberg> i think of them as the chinese advanced circuits, not the chinese oshpark
<azonenberg> If you want high end specs, high end quality, and overseas pricing (considering the specs) they're a good choice
<azonenberg> They're not going to be dirtypcbs pricing
<azonenberg> Did i mention how they do QA samples?
<awygle> sure
<awygle> altho lol @ advanced circuits as "high end specs"
<azonenberg> every order comes with impedance test strips if applicable, an epoxy embedded cross section, etc
<azonenberg> and a full QA report. But they include the samples as proof they really did the QA, inviting you to double check their numbers if you don't trust them
<azonenberg> i've never seen another fab do THAT
<awygle> when i was in aerospace almost all our fabs did that
<awygle> but they were $$$ of course
<azonenberg> awygle: and i consider controlled impedance on rogers, hdi, etc to be high end
<awygle> i had a fab once decide "fuck it, who needs to epoxy-fill vias, we're just gonna plate them shut"
<azonenberg> Lol
<awygle> their cross-section was hilarious
<azonenberg> solid copper slugs
<azonenberg> actually, i'd expect plating chemicals trapped in the holes
<awygle> it made our thermal design _very_ easy though
<azonenberg> and voids up the wazoo, and corrosion leading to gradual failure
<azonenberg> but that's my inner process engineer coming out
<awygle> na it was good. i think it was electroplated or something
<awygle> didn't have any issues
<azonenberg> re multech specs... their website capabilities page, which hasn't been updated in a while, says they can do up to 36 layers, finished board thickness from 200 μm to 12 mm, 12 ounce copper
<awygle> but they ended up with like 4oz copper on the outer layers and then had to plane it down i think
<awygle> weird process
<awygle> but whatever it worked
<azonenberg> 2/2 mil (50 μm) trace/space, 75 μm mechanical drills with 18:1 aspect ratio
<azonenberg> 5+N+5 HDI stackups, 14 layer flex-rigid or flex
<azonenberg> so that sounds pretty high end to me :p
<awygle> yes :p
<awygle> wasn't arguing with multech, just with AC
<azonenberg> ah true. i havent used them personally but they seemed like a high end shop
<azonenberg> i've only RFQ'd and then gone elsewhere when i saw the price :p
<azonenberg> The highest end stuff i've actually DONE at multech was 6 layers (2 layer core with 2 layer HDI on either side, stacked blind/buried microvias, filled/plated, impedance control) with an 0.4mm BGA on it
<azonenberg> around the same time a coworker did a nice aluminum core LED light engine with them
<azonenberg> But none of their products have ever given me the impression they were anywhere near the limit of their capabilities
<azonenberg> my high end is their business as usual
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±16] https://git.io/Jv628
<_whitenotifier-3> [scopehal] azonenberg 57be093 - Added dynamic creation for oscilloscopes. Fixes #99.
<_whitenotifier-3> [scopehal] azonenberg closed issue #99: Create dynamic creation table for scope drivers and SCPI transports (depends on #68, #71, #72) - https://git.io/JvrCl
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jv62B
<_whitenotifier-3> [scopehal-apps] azonenberg 4552291 - glscopeclient: use dynamic creation for oscilloscopes based on driver name
<_whitenotifier-3> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jv62R
<_whitenotifier-3> [scopehal-docs] azonenberg 99a10ee - Clarified port numbering for Rigol
<_whitenotifier-3> [scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/Jv620
<_whitenotifier-3> [scopehal-cmake] azonenberg fb31552 - Updated all submodules for dynamic creation
<azonenberg> ok at this point a few other tools in scopehal-apps are likely broken, i'll fix that after work today, but if you "make glscopeclient" it should compile OK and use the new dynamic creation table
<azonenberg> once i make psuclient etc compile again, i can work on file load as i think all of the pieces are here
<awygle> if one tried to measure a 60 MHz clock with a scope rated at 50 MHz
<awygle> what would one see
<azonenberg> What's the sample rate?
<awygle> 1 gigasample
<azonenberg> You'll see a 60 MHz sinewave with an amplitude somewhere under 1/2 the true value
<awygle> k. so seeing a flat line at 1/10th the amplitude is not expected :p
<azonenberg> exact relationship of the amplitude you see to actual is unpredictable, because a "50 MHz" scope normally means the front end has -3 dB (0.5x) attenuation at 50 MHz and less than that from DC to 50
<azonenberg> after 50 is completely unspecified, but it's not going to flatline that quickly
<awygle> (my probe is set correctly, i'm not on 10x when expecting 1x or vice versa)
<azonenberg> i'd say either your probe setup is borked (loose cable, damaged probe, not making contact) or the signal is actually flatlined
<awygle> gotta be the latter, other signals look fine.
<awygle> time to try to figure out why my ulpi transceiver isn't clocking out then
<azonenberg> You also need a better scope, lol. One more reason for me to start pushing hard on the entry level scope design
<azonenberg> I think on a single channel i should be able to get 125 MHz B/W 1 Gsps 8 bit
<awygle> tbh i _think_ this scope is actually 100 MHz? just not calibrated?
<awygle> it's a 1054Z hacked to be an 1154Z or 1174Z (forget which)
<azonenberg> ah even better
<azonenberg> yeah the entry level scopehal hardware is going to be i think the same ADC those scopes use
<azonenberg> well, the next model up that supports either a low speed 12-bit or high speed 8 bit mode, so you can select
<azonenberg> Just with a much nicer frontend and software stack plus ethernet streaming
<awygle> was about to say mine has ethernet but i think i'm thinking of my SA
<awygle> (feature request... :p)
<azonenberg> Specan support is totally doable. We already have support for FFT channels so we can do either spectrum graph or waterfall displays already
<azonenberg> All we need to do is make a scope where the channel objects have spectrum instead of time domain output
<azonenberg> this is how freesample will integrate too, it will just be a scope where the channel type is "eye pattern"
<azonenberg> And i dont think your rigol can do 500 WFM/s over ethernet like my planned scope will :D
<awygle> na i think it's usb actually
<azonenberg> USBTMC support is on the todo list and should drop into the existing object model pretty seamlessly once somebody bothers to write the class
<azonenberg> incidentally, once that happens we will get usbtmc support for all other instruments for free :D
<azonenberg> The beauty of this architecture, having transports and drivers decoupled
<awygle> i should check my probe b/w
<awygle> "tfw 1 MHz probe on 60 MHz clk" would be less than ideal
<_whitenotifier-3> [scopehal] azonenberg edited issue #84: Add SCPITransport based class for USBTMC - https://git.io/JeQQ4
<azonenberg> awygle: scopehal:#84 is the ticket for usbtmc transport class, lain says she's going to do that
<azonenberg> not sure about any progress
<awygle> 150 MHz
<awygle> so no problem
<miek> the 1000z series does have ethernet too
<awygle> ah, so they do
<awygle> somehow thought that was what the -E meant
<miek> what's generating the clock signal you're trying to measure? maybe it's something that can't take the capacitive loading of a normal probe?
<awygle> ULPI transceiver
<awygle> i'm pretty sure it's not clocking, that jives with other secondary evidence
<awygle> well, shit. ok, that explains that.
<awygle> i didn't hook the ground pad up to ground
<awygle> i specifically went way out of my way to _avoid_ hooking the ground pad up to ground
<awygle> i don't know where i got that idea
<azonenberg> That would explain a lot. Lol
<awygle> it's in my notes in several places "remember, don't hook the belly pad to ground"
<awygle> and it's in the datasheet in several places "GND flag is the only circuit ground. Other signals that are connected to the ground should not be relied upon to pro-vide circuit ground"
<azonenberg> hey, at least you didn't do what one of my customers did a few years ago
<azonenberg> and connect the thermal pad of a bipolar supplied SiGe comparator to ground instead of -3V
<azonenberg> Reworking that was fun
<awygle> lol
<azonenberg> i mean with the lab i have now, it would be relatively straightforward. But with my setup in the garage in 2017 it was dicey
<awygle> hm so what's the best way to fix this besides "go buy a pcb mill thing" or "pay azonenberg"
<awygle> wonder if i can just pour solder into the ground leads until they short to the pad lol
<azonenberg> How quick do you need it fixed, how many do you have to rework, and what does the layout look like? and thats a terrible idea
<azonenberg> (and is this f/oss or work related?)
<electronic_eel> is there a solid ground layer below?
<azonenberg> (that's what i was getting at)
<electronic_eel> you could desolder and drill down
<azonenberg> I have zero doubt i could fix it, and i'd do it free/no cost if it was a hobby/foss project as long as you didn't mind a potentially slow turn time
<azonenberg> free/low cost*
<azonenberg> obviously i'd charge my usual rate if it was a commercial project
<awygle> it's "eventually oshw", i have 10pc assembled, i don't need it fixed on a particularly tight schedule
<azonenberg> Is there a ground plane under the thermal pad?
<awygle> L1 is the IC(+signals), L2 is solid ground, L3 is solid power, L4 is signals
<azonenberg> Perfect
<azonenberg> 1.6mm pcb? how large?
<awygle> 1.2mm i think
<azonenberg> 1.2 is a bit odd but i could shim easily to fit my existing mount
<awygle> 123x119mm
<awygle> yeah 1.2mm
<azonenberg> So, my proposed rework is: hot air to remove the IC, flux+braid to remove residual solder, IPA swab to deflux
<azonenberg> Machine a stepped cavity in the center of the ground pad so you have ground plane in the middle, surrounded by thinned copper, surrounded by full thickness copper
<azonenberg> solder one or more flat copper strips from the plane to the thinned copper area (depending on how low inductance you need the bond to be)
<azonenberg> tack in place with epoxy so they don't move when solder melts during replacement of the chip
<electronic_eel> maybe do it with a scalpel by hand on one pcb first to check if this is the only problem before shipping it back and forth?
<azonenberg> i was going to suggest he send me one board and if he likes the results i'd do the rest
<azonenberg> anyway, then squirt a bit of solder paste on the pad, hot air the chip on, and touch up perimeter pads with an iron
<azonenberg> It would actually be a cool advertisement for capabilities of my lab, so as long as you're not taking a profit on the work i'd do it for free. And it would be fun
<azonenberg> as long as i get to publish some pics/video of the process
<awygle> my intention is to eventually do a crowdfunding campaign for this project, for which i would take a profit, but also to release it as OSHW concurrent with the end of such a campaign
<awygle> (And be very up front about that during the campaign of course)
<azonenberg> Hmm, in that case maybe i'd do the first prototype free but if you wanted me to do the other 9 we could negotiate some rate for my services?
<awygle> i'm not opposed to paying you
<azonenberg> either way i have no problem doing one free so you can validate your design
<awygle> yeah, that sounds fine to me
<azonenberg> But yeah, this would be a cool demo of my capabilities and is literally the exact sort of rework i got the mill for
<azonenberg> I actually got into a rather interesting debate on the moralities of spending $$$ on a home lab with some folks on twitter a while back
<awygle> oh?
<azonenberg> one person said she felt bad about spending a ton on her lab because of all the people who couldn't afford such toys
<azonenberg> meanwhile, the way i see it is that as someone who has the means to acquire a *very* nice lab, i have almost a duty to share the bounty with others
<azonenberg> So i'm going to build the lab, but i'm going to offer free/discounted services to those who need them and can't afford my usual rate
<awygle> an interesting pair of positions
<azonenberg> So basically if it's an entirely noncommercial/oshw project i'd do the work at no cost as long as i can fit it in around billable stuff with no promises of a super quick turn
<azonenberg> if it's for a business, i'd charge my usual rate
<azonenberg> and in your case, commercial osh, we'd negotiate something in between
<electronic_eel> hmm, yeah, interesting opinions.
<azonenberg> i've already done free PCB failure analysis etc for a few folks
<electronic_eel> awygle: what kind of project are you working on?
<azonenberg> Because if people are in the position of either not doing a project/not doing it right because of budgetary constraints, and i have the means to assist, i want to do so
<azonenberg> Definitely a rather communist philosophy lol
<electronic_eel> azonenberg: the photo series for greg davills connector soldering was good
<azonenberg> i.e. i'll help you out as much as i can regardless of your ability to pay, but if you *can* pay i expect you to do so
<awygle> i am fortunate enough to be able to pay :p
<awygle> electronic_eel: i'd rather not go into too much detail (if i gush too much about projects i tend not to finish them). but it's a retro gaming project.
<electronic_eel> ok, fully understand to wait till it is finished enough
<electronic_eel> I often also push stuff to github from my local repo only after it passed a certain point
<awygle> mhm. it's not so much "oh no i'm embarassed" as it is "i get the dopamine kick from talking about the project so i don't need to finish it" :P
<electronic_eel> I sometimes lose interest in a project for some time, sometimes for too long to finish it without redesigning everything from scratch
<azonenberg> ok, quotes back from PMK: substantially no discount for higher order volume
<azonenberg> solid probe tips $6.20 each, pogo tips $20.20 each
<azonenberg> ground blade $21, z-ground $16, flex ground lead $28, positioner $48
<miek> ouch!
<azonenberg> most of those are reasonable... but tequipment sells the exact same positioner for $25
<azonenberg> so i know they can be had cheaper :p
<azonenberg> (this is via SCITest which is a US distributor for PMK, not direct)
<azonenberg> So basically if i don't include a spare tip with the probe as standard (probably OK, most users won't wear tips out fast if at all) i'm looking at $6.20 + $21 + $16 + $28 for the standard accessories without a positioner - or $71
<azonenberg> if i add a positioner at tequipment's price $96 for all of the accessories
<azonenberg> And i can cut that if, over time, i find ways to build accessories like ground leads in house
<azonenberg> my cost for the probe itself is $10 for the board, maybe $10 for the passives and SMA connectors, and about $25 for the 3d printed shell, so $45, adding in technician time for assembly call it $55
<azonenberg> So roughly speaking $150 cost to me for the probe with full accessories, or $77 for a minimal setup of probe+solid tip+z-ground only
<azonenberg> i'm mostly competing with a probe with less bandwidth that costs $329 at distributors
<electronic_eel> if your probe design is finished and verified - maybe ask PMK if they are interested and want to list it
<azonenberg> I'm doing one last respin. And PMK wouldn't list it i think, they're an OEM not a distributor
<azonenberg> if anything i'd go to a scope vendor and ask if they want to list them
<azonenberg> scope vendors buy PMK products and sell them under their own name
<azonenberg> i'd be doing the same thing
<electronic_eel> look at their current probes - that is all iwatsu
<azonenberg> hmm, interesting. i dont know the relationship between PMK and Iwatsu
<azonenberg> AIUI PMK is the OEM for lecroy's passive probes and most of their <= 4 GHz active voltage probes
<azonenberg> i think the higher bandwidth lecroy probes are in house designs
<electronic_eel> I think scope vendors buy stuff from them. and if they want a z0 probe, they maybe want yours
<electronic_eel> they could of course spin their own, but if a good design can be had from some vendor for a reasonable price they buy
<azonenberg> Yeah. Well first step is to fine tune the design a bit more. I'm likely to respin the enclosure for mechanical resons
<electronic_eel> maybe just show them what you are doing and ask
<azonenberg> i am definitely respinning the PCB to provide a bit more length for the new probe socket
<azonenberg> But before i do *that* i'm waiting on the characterization board to come back so i can get final results from this spin
<electronic_eel> yeah, you should have finished design with maybe just a few dfm tweaks before showing them
<azonenberg> Exactly. I've been working on this project for a long time, i'm not in a huge rush
<electronic_eel> was just an idea. if you have a mutual relationship with them you may get better discounts for the accessories
m4ssi has quit [Remote host closed the connection]
<miek> btw, it looks like agilent/keysight uses PMK in places too - the N2870A is a PML 701 for example
<azonenberg> Not surprised. Pico uses their positioners
<azonenberg> i havent looked at pico's 1M or active probes but they're very likely PMK as well. The TA061 and the Picoconnect series transmission line probes appear to be in house designs
<azonenberg> I'm targeting performance approaching a picoconnect probe for less than the cost of a ta061
* zigggggy aims IR thermometer at azonenberg
* zigggggy checks reading
<azonenberg> Nope, not on fire yet
<zigggggy> azonenberg is your office recommending work from home yet?
<azonenberg> zigggggy: i've been under mandatory WFH for... at least a week now
<zigggggy> what about others?
<azonenberg> havent left the house except for one grocery run yesterday. Just took inventory and i have enough stuff in the house to not leave until late next month
<azonenberg> although for the last few weeks i'll be living out of cans and freeze-dried stuff
<azonenberg> only have ~2 weeks of somewhat fresh stuff
<azonenberg> iirc amazon and microsoft are doing similar stuff. Not sure about the rest of the area
<azonenberg> governor just announced a ban on all public gatherings of 250+ people
<azonenberg> schools in seattle, king county, snohomish county, and a few other nearby areas are all closed. Not this side of the water yet, it's not nearly as bad here as in the city proper
<azonenberg> but i imagine it's only a matter of time before we get hit
<zigggggy> azonenberg because the virus wont spread in gatherings of 100 or 50 or 25 :P
<azonenberg> Hey, at least it will infect less people. It's a start
<zigggggy> it seems arbritary
<zigggggy> arbitrary
<azonenberg> Just ordered three more probe enclosures in different materials (white SLS nylon 11, black SLS nylon 11, black MJF nylon 12). Going to compare the appearance, feel, and mechanical performance of these to the glass-filled dark-gray nylon i've used for beta units
<azonenberg> Black MJF nylon is the cheapest at $9.03 @ qty 1
<awygle> Well since I have to leave my house anyway might as well do the groceries and pharmacies things
<azonenberg> (and mail me the boards?)
<azonenberg> also pushing out an order to the PMK distributor for ten tips and sets of ground leads, no positioners.
<azonenberg> Plan is to do a bit more characterization on the current PCB rev of the probes and shells, then do one last respin of the probe and probably a mechanical redesign of the enclosure to accommodate the new ground position
<azonenberg> at that point i plan to send out ten assembled beta units (probably charging actual BOM cost) to interested parties for feedback, testing, and characterization
<azonenberg> (well ok i'll make ten beta units, i'm keeping one for myself)
<azonenberg> Requirements to qualify as a beta tester are owning/having access to a >= 500 MHz oscilloscope with 50 ohm inputs, a >= 2 GHz VNA, or both; as well as being willing to send me results from testing
<awygle> Yes that's why I have to leave my house anyway lol
<azonenberg> ah ok
<miek> i'd be keen to beta test and send back some results, unless 9 people chime in with better gear :p i've got a 3GHz VNA (Agilent E5062A). might be able to do rough scalar insertion loss out to 18GHz too
<azonenberg> All of the beta folks will, btw, also get one of the characterization boards
<monochroma> azonenberg: nope the repo is still derped
<monochroma> still on: /home/user/test/scopehal-cmake/src/psuclient/main.cpp:174:84: error: no matching function for call to ‘SCPISocketTransport::SCPISocketTransport(char [128], int&)’
<monochroma> and that was with a completely clean build
<monochroma> mkdir ~/test && cd test && git clone https://github.com/azonenberg/scopehal-cmake.git --recurse-submodules && cd scopehal-cmake && mkdir build && cd build && cmake .. && make -j4
<azonenberg> monochroma: psuclient will fail to build because i haven't ported it to the new driver model yet
<azonenberg> glscopeclient should compile and work fine
<azonenberg> psuclient doesn't really do much yet anyway, it's a view-only UI at the moment
<monochroma> azonenberg: okay yeah, it does build, i was just making sure you were aware the full build fails
<azonenberg> i was not, as i had been running make && ./glscopeclient from the glscopeclient build dir. I forgot i wasn't in the root of the build dir
<azonenberg> So thanks for telling me
<azonenberg> But as of this morning, however, i am aware and it's an issue i plan to address :)
<monochroma> azonenberg: did you look at the weirdness with trying to add an eye pattern filter?
<azonenberg> No, send me a screenshot?
<monochroma> 05:53 < monochroma> manually built just glscopclient, i get a binary, and it does connect to my scope
<monochroma> 05:53 < monochroma> something isn't quite right though
<monochroma> 05:54 < monochroma> when i try to add an eye pattern all traces go blank and i get this message on the console: (glscopeclient:29594): Gtk-CRITICAL **: 06:53:10.319: gtk_box_reorder_child: assertion 'old_link != NULL' failed
<azonenberg> oh interesting. yeah i just had that issue adding a new waveform
<azonenberg> gimme a minute
<monochroma> i also noticed it seems to only effect the Waveform Group that it happens in
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jv6iW
<_whitenotifier-3> [scopehal-apps] azonenberg 3ebb00f - Fixed non-digital decodes not being packed into the waveform box
<azonenberg> so what's happening is the eye pattern tries to resize the whole window to be one UI wide, but the eye itself isn't added to the box
<azonenberg> so you end up having all of the traces be super zoomed in AND no eye
<azonenberg> regression from when i fixed packing issues on digital waveforms
<azonenberg> it messed up non digital
<monochroma> ahhh
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jv6i4
<_whitenotifier-3> [scopehal-apps] azonenberg 3e47e04 - Fixed decodes with no configuration having blank names instead of default autogenerated names