<azonenberg>
this is the 1.5 GHz lecroy active probe
<azonenberg>
it's slightly below 1.5 as seems to be the trend with most stuff i characterize
<azonenberg>
but it's not bad
<azonenberg>
its a hell of a lot flatter than the pico
<azonenberg>
i did not do a s21 on the lecroy 10M passive probe
<azonenberg>
and i will not be attempting one on the 4 GHz diff probe any time soon
<azonenberg>
I also have s-parameters for the 6 GHz pico passive probe, but i havent written a full review for it yet
<Kliment>
how would you even S21 a diff probe?
<azonenberg>
Assuming a single ended output? You'd need a balun or something at the input
<azonenberg>
So you could apply a differential mode stimulus
<azonenberg>
and measure gain/phase of (Vinp - Vinn) vs Vout
<azonenberg>
You can probably do that on a 4-port VNA if you treat it as a 2-port network with a differential port 1 and a single ended port 2
<azonenberg>
if i were to do it with my current setup, i'd do a single ended measurement with Vinn grounded and Vinp on the single ended stimulus port
<azonenberg>
aka, a differential measurement between shield and center of the vna cable
<azonenberg>
but still single ended as far as the VNA is concerned
<azonenberg>
meanwhile the probe sees it as a differential measurement with a common mode offset of Vpp/2
<Kliment>
that makes sense
<Kliment>
azonenberg: totally offtopic, but this reminds me of that ampleon white paper about running a VNA on food in a microwave
<Kliment>
azonenberg: to find the frequency of maximum absorption
<azonenberg>
looool
<azonenberg>
i did not see that
<electronic_eel>
Kliment: so in the future you'll have to deembed your dishes before you can cook? also they will only be good for 500 mating cycles and need to be torqued correctly ;)
<azonenberg>
i deembed food from my dishes when i'm *done* wating
<Kliment>
basically, the high-power microwave amplifiers used in murderdrones and cell phone base stations have now gotten cheap enough to trickle down to the masses at just hundreds of dollars
<azonenberg>
eating*
<azonenberg>
With soap and water
<Kliment>
so solid-state-microwave ovens are a possibility now
<azonenberg>
how about efficiency?
<sorear>
my question is can this replace klystrons in HEP and astronomy with a significant const reduction?
<electronic_eel>
I saw some microwave ovens in a shop marketed as solid state the other day. but they were cheap, so I think they won't have any complex techniques to adapt the load to the food
<sorear>
attn smkz
<Kliment>
sorear: I don't think so
<Kliment>
sorear: first of all, these are microwave emitters
<Kliment>
sorear: second of all they're currently an order of magnitude more expensive than magnetrons
<Kliment>
azonenberg: efficiency is dramatically better than magnetrons
<Kliment>
azonenberg: you can get 70-80% of wall plug energy into your food
<sorear>
"an order of magnitude more expensive than magnetrons" sounds like a large improvement over klystrons
<Kliment>
sorear: that's a completely different kind of tube with an entirely unrelated function
<sorear>
a magnetron is a free-running oscillator, a klystron is an amplifier
<sorear>
it sounds like the things you're describing are also amplifiers and thus closer to a klystron
<Kliment>
sorear: this is an amplifier but it doesn't produce a linear beam
<sorear>
what does "linear beam" mean here? the systems I'm familiar with all operate in waveguides
<sorear>
if you want the energy to come out in a straight line you hook up the waveguide to a horn and a big dish
<Kliment>
sorear: klystrons used in astronomy operate at dramatically higher frequencies than the 2-4GHz you have in these parts
<Kliment>
sorear: if you need amplification at single-digit GHz range, yes, you can use these parts - and you could already use the previous generation parts from normal RF links
<sorear>
so you're saying this will replace arecibo's S band klystron but they need to keep the X band and Ku band tubes around for a little while longer
<Kliment>
sorear: klystrons can scale up in frequency and power much better
<Kliment>
sorear: you can't get a solid-state amplifier to go beyond half a kilowatt or so
<Kliment>
sorear: This is fine for applications where you can use an array of them
<Kliment>
sorear: not so good when you need a single emitter
<Kliment>
So, not the same type of thing at all
<Kliment>
with the linear beam configuration you can just make the device arbitrarily big to get more power
<sorear>
I think they still do the "running dozens of devices in parallel with the outputs summed in phase" thing
<sorear>
well I guess that's because the accelerators are running klystrons with 100s of MW of wall plug energy, point taken
<Kliment>
sorear: a klystron is basically you feed it high power RF on one input, and a modulating signal, and it spills out some of the high power input on its output when the modulation signal is on
<Kliment>
it's inefficient as hell, but you can scale it up any size you want
<Kliment>
With these amplifiers, you feed it DC and a low-amplitude RF signal
<Kliment>
and it spits out high-power RF
<Kliment>
totally different principle of operation
<Kliment>
because it's a semiconductor you can't just make the junction arbitrarily large
<Kliment>
So it doesn't scale the same way as "hurr durr bigger tube"
<Kliment>
semiconductor RF amplifiers tend to have the gain curve centered on a very small frequency range
<Kliment>
arecibo uses two tubes at 500kW each
<Kliment>
for the 2.4GHz signal
<Kliment>
each of those tubes would need 1000 of the current best-in-class solid state RF amps to replace
<Kliment>
good luck merging 2000 outputs and staying in phase
<Kliment>
also I strongly suspect one of their tubes costs less than 150k dollars
<Kliment>
And of course it's easier to provide MW of power ak kV of voltage rather than at 36VDC
<Kliment>
at*
<Kliment>
I mean, when not being used for hipster audio, the three remaining applications of tubes are actually ones where semiconductors cannot perform as well
<Kliment>
really cheap microwave generation, single-photon optical amplification, and tens-of-kilowatts-and-up radio amplification
<sorear>
the performance gap between PMTs and avalanche photodiodes is not nearly as large as the other two
<Kliment>
that's true, but the cost-performance gap is
<azonenberg>
low light CCDs and CMOS sensors are not currently competitive with microchannel plate based intensifiers for extremely low light applications
<azonenberg>
although in brighter "night" conditions like full moons, some of the SiOnyx sensors are doing quite well and also are full color capable
<Kliment>
azonenberg: I don't have much experience there
<azonenberg>
I own a gen 3 unfilmed white phosphor PVS-14
<azonenberg>
and have been thinking of picking up one of the SiOnyx systems to compare to it
<Kliment>
For what application?
<azonenberg>
From what people on the interwebs say, they're not competitive in starlight or heavy clouds at night, but in moonlight they're pretty good
<azonenberg>
Fun, astronomy, night hiking, etc
<azonenberg>
Although i really want to get a second one at some point. Night hiking with NVGs and a partner who has a flashlight doesn't work, and my one friend who has a PVS-7 lives in california
<azonenberg>
and solo hiking isnt a great idea even by day, much less night
<azonenberg>
So if i had one i could loan to my wife or a friend i'd feel a lot safer going on more ambitious night hikes
<Kliment>
right
<Kliment>
I guess night vision equipment is permanently linked in my mind to the murricah gun nut community
<azonenberg>
I mean i have taken it to the range once or twice for night sessions. But that wasn't the main reason i got it
<azonenberg>
Bird|otherbox: back to on topic, i think at this point the build is as static-analysis-clean as it's going to get for a while
<azonenberg>
at least, as clean as i can make it without fixing the false positives we've discussed and that clang-analyzer issue you were chasing
<azonenberg>
i think i've fixed all of the legit findings and suppressed the easily confirmable false positives
<azonenberg>
i guess a longer term thing to think about will be setting up automated CI builds and tests
<azonenberg>
now that we have a dummy signal generator it should be possible to exercise a lot of stuff offline
<azonenberg>
The drivers are, of course, among the most interesting bits of code and those will be hard to do automated testing on
<azonenberg>
but long term i would like a library of not-too-large test files we can use for doing basic regression testing on filters
<azonenberg>
some way to do at least some level of automated testing on glscopeclient itself
<azonenberg>
and, as a minimum (we can probably set this up pretty soon) some kind of CI dashboard doing automated nightly builds on both linux and windows and reporting any build errors or static analysis warnings to some kind of dashboard and this channel
<Kliment>
azonenberg: does this build correctly on raspi?
<azonenberg>
Never been tested. Gut feeling is no but it could be made to
<azonenberg>
the first potential issue is that i have some x86 specific AVX optimizations in a bunch of spots. I dynamically detect if your CPU supports it and enable them or not
<azonenberg>
but i still try to enable them at compile time
<azonenberg>
so if your compiler doesn't understand AVX, like you're not compiling for x86, it will likely choke on that
<azonenberg>
that's a fairly easy ifdef fix
<azonenberg>
just don't even compile the avx code on non-x86
<azonenberg>
there's generic C++ implementations already as a fallback
<azonenberg>
second issue is that I require GL 4.2 plus compute shaders
<azonenberg>
I don't request a GL ES context so it will probably fail to create the context on an embedded GPU
<azonenberg>
Recent enough GL ES should work with some work
<azonenberg>
basically, so far nobody's put in the work but i think it's possible
<azonenberg>
with the AVX ifdefs, libscopehal should work fine for headless acquisition and data processing on pi. That i'm certain of
<azonenberg>
there's nothing x86 specific, the only platform assumptions i make are when marshaling data from save files and certain instrument drivers
<azonenberg>
i assume that the CPU is little endian and that floats/doubles are 32/64 bit ieee754
<azonenberg>
so arm or x86 both meet that but you might run into trouble if you tried building for, say, powerpc
<azonenberg>
but i don't know of any opengl 4 capable powerpc platforms so i didn't really care :p
<monochroma>
modern POWER workstations usually use modern AMD GPUs
<azonenberg>
i figured realistically, arm64 and x86_64 were the two platforms to consider supporting
<azonenberg>
monochroma: that's niche enough probably not worth worrying about though
<azonenberg>
and is modern power little endian or big?
<monochroma>
they switched to LE in POWER 8 iirc
<azonenberg>
oh, then great
<monochroma>
it was either 7 or 8
<azonenberg>
it would probably be possible to build on modern power then :p
<sorear>
you can run the chips in either
<monochroma>
yeah they have always been bi endian (like most RISCs) but internally operate faster in LE mode
<sorear>
that's a surprising claim
<Kliment>
azonenberg: GL4.2 won't work on the pi
<Kliment>
azonenberg: it does ES3.2
<azonenberg>
Kliment: yes i know, i havent had time to look at the differences
<azonenberg>
I require GL_EXT_blend_equation_separate, GL_EXT_framebuffer_object, GL_ARB_vertex_array_object, GL_ARB_shader_storage_buffer_object, GL_ARB_compute_shader, and GL_ARB_gpu_shader_int64
<monochroma>
i don't think the pi platform has compute shaders
<azonenberg>
yeah i didnt think it did
<azonenberg>
i'm really targeting workstation platforms, if it runs on anything else that's a bonus
<monochroma>
yeah
<azonenberg>
keep in mind the original use case, which i still am aiming for, is 100% GPU offload of the filter graph rather than just rendering like i have now
<Kliment>
yeah
<azonenberg>
with the fastest possible offload from NIC to GPU to handle tens of Gbps of waveform data
<Kliment>
none of those extensions are supported afaict
<azonenberg>
in fact, really long term I want to be able to run multiple entire waveforms worth of filter graph in parallel to handle stuff like CDR PLLs that don't multithread well
<azonenberg>
if you have thousands of triggers per second i want one gpu thread implementing the cdr for each waveform
<azonenberg>
for say 100 waveforms at once, or more
<azonenberg>
then do digital phosphor persistence overlaying all of those in a single rendered frame
<azonenberg>
i'm not fast enough yet, nor are the instruments i'm pulling data from, for that to be a concern
<azonenberg>
but that is the endgame
<monochroma>
sorear: what is?
<sorear>
that LE is faster
<monochroma>
sorear: ah, it's only faster on modern power because they retargeted the endianess to LE from BE
<sorear>
there is as I understand this a lot of misinformation about BE in modern power
<azonenberg>
Kliment: to give you an idea of where i want to go eventually, i want to be able to have a stream of data coming off MAXWELL oversampling a full duplex 1000base-SX link at 5 Gsps each for TX and RX. So 10 Gbps of data assuming no compression
<Kliment>
Yeah I know - but there's plenty of use on the low end
<azonenberg>
i want to be able to do CDR on both in real time, decode the 8b10b, decode the 1000basex, stream packets to wireshark
<azonenberg>
detect bit errors and keep count of them, detect bad 8b10b symbols, etc
<azonenberg>
And of course i'm not ignoring the low end, i'm just saying that GPU compute is a key architectural requirement
<azonenberg>
and platforms without support for it just aren't gonna be supported ,ever
<azonenberg>
a five-year-old integrated intel gpu will work, not super fast but it will work
<Kliment>
azonenberg: 5 year old intel graphics is missing GL_ARB_gpu_shader_int64
<Kliment>
azonenberg: has all the others though
<azonenberg>
Kliment: hmm
<azonenberg>
i thought they added that around then
<Kliment>
Oh, could be
<azonenberg>
i know it works on a skylake integrated gpu from 2016
<azonenberg>
because that's what's in my oscilloscope
<Kliment>
Yeah, previous ones don't have it
<azonenberg>
ah ok
<azonenberg>
yeah 64 bit timestamp support is pretty key
<azonenberg>
thats another thing that isnt possible to avoid without major rearchitecture
<azonenberg>
or huge performance hits doing software bignum on the gpu
juli966 has joined #scopehal
<monochroma>
sorear: okay, apparently i stand corrected. asked a friend who is a POWER expert, and apparently modern POWER is true bi-endian, no performance penalty for being in either endian mode (which makes sense, they wouldn't want to penalize AIX and OS/400)
<kc8apf>
Only reason LE on POWER became relevant was IBM trying to push OpenPOWER and expand into hyperscalers. Google spent a year porting to POWER8 BE before giving up. Most bugs were endianness assumptions. Until then IBM acknowledged LE mode but refused to support it.
<kc8apf>
Rather than give up a big sales prospect, IBM spun up ppc64le firmware and Linux.
<kc8apf>
As for funneling data from NIC to GPU, it can be done directly via P2P. Large scale GPGPU and AI stuff started doing that a few years ago.
<azonenberg>
kc8apf: yes i am aware. That had been the endgame for a while
<azonenberg>
I havnet had time to look into how to actually do it
bvernoux has joined #scopehal
<azonenberg>
Woo. Flex probes are here as is the WL-PBUS
<azonenberg>
The strain relief fits a bit too snugly
<azonenberg>
while sliding one of the boards in i think i may have damaged it so i'm not gonna use that pcb to be safe
<azonenberg>
These boards are also quite stiff. not sure if the soldermask vs coverlay makes a difference or if it's something else
<azonenberg>
might just be the CPWG having more copper than the microstrip my last one used
<azonenberg>
anyway i'll assemble them after work and see how i like performance
<bvernoux>
I have just finished Digital probe MSO5000 ;)
<bvernoux>
I have spent >2h to do the matching length ;)
<bvernoux>
like that they can go up to 1GSPS ;)
<bvernoux>
and the must is I generate also JCPCB SMT pos & files ;)
<bvernoux>
if someone is interested I will produce 2 board with assemble (and 3 board will be not assembled)