<_whitenotifier-7>
[scopehal] mubes c2f432a - Fix channel pull request to match number of enabled channels
<_whitenotifier-7>
[scopehal] azonenberg b1fecf3 - Merge pull request #539 from mubes/fix_chanpull Fix channel pull request to match number of enabled channels
<azonenberg>
Looks like both the PCF200 test fixture I was using, and the 12" SMA-SMPM cable I use between the probe head and the VNA, are significant contributors to overall performance loss
<azonenberg>
so I switched fixtures and in the lower time domain trace de-embedded the cable (as well as the 24" cable from that one to the scope)
<monochroma>
what's the top trace?
<azonenberg>
top is the raw waveform through two cables and the probe
<azonenberg>
bottom is after de-embedding the cables
<_whitenotifier-7>
[scopehal] azonenberg c53dc00 - DeEmbedFilter: added option for manual group delay override if autodetection fails
<d1b2>
<dannas> @Degi Re the discussion about ADCs yesterday, just learned that the upcoming Thunderscope ( I think Aleksa hangs out in this channel) uses HAD1511 ADCs. They seem to cost about $70 though all distributors stock's empty. So I guess once you leave 5Gsa/s and go to the 1Gsa/s territory the price drops substantially.
<azonenberg>
dannas: yes
<d1b2>
<dannas> Why I'm looking at ADCs? Just got curious, I certainly don't have the expertise to use any of these kind of components.
<azonenberg>
I had plans for three lower end scopes based on the HMCAD15xx family
<azonenberg>
either the 1511 or the 1520 which is a 1511 plus the option of running in 12 bit mode at lower sample rate (runtime reconfigurable)
<azonenberg>
and is pin compatible
<azonenberg>
My overall roadmap for scopes is...
<azonenberg>
BLONDEL: 1x HMCAD1520 shared by 4 channels, 100 MHz / 1 Gsps on one channel split to 500/250 Msps in 2/4 channel mode
<azonenberg>
basically entry level rigol but better backend, deep memory, 10g ethernet streaming, etc
<azonenberg>
the full system would be either one or two of those 4-channel mdules
<azonenberg>
DUDDELL: 1x HMCAD1520 dedicated to each channel, 250 MHz / 1 Gsps on each channel in 8-bit mode, switchable to 500 Msps in 12 bit mode possibly with reduced bandwidth
<azonenberg>
(switchable per channel independently
<d1b2>
<dannas> That sounds like something there would be a lot of demand for. You'd get the capabilities of a picoscope for (maybe?) less the price.
<azonenberg>
ZENNECK: Original plan was 4x HMCAD1520 interleaved but this proved to be difficult, and I wanted to play with the AD9213 in preparation for next-gen platforms
<azonenberg>
so to meet the same 500 MHz bandwidth spec I bumped the sample rate up from 2 to 5 Gsps using the better ADC
<azonenberg>
although it will cost more
<azonenberg>
(I may still make a HMCAD1520 interleaved scope at some point but not on the current roadmap)
<azonenberg>
all of these three will use the same frontend just with different antialiasing filters
<azonenberg>
Then VOLLUM will use a full rate AD9213 per channel giving 1-2 GHz, 10 Gsps 12 bit
<d1b2>
<dannas> Maybe there is a very limited number of suitable ADCs for these kind of applications? Given that both you and Aleksja used the same IC.
<azonenberg>
Yes the field is very limited
<azonenberg>
and MURDOCK will interleave four AD9213s per channel giving "many" GHz of BW (depends a lot on frontend and S&H configuration) and 40 Gsps 12 bit
<azonenberg>
that will be probably $20K *per channel* and may or may not ever be built
<azonenberg>
but if built it would be competitive with upper midrange scopes from big names like the LeCroy WavePro/WaveMaster/SDA platform
<d1b2>
<dannas> Wasn't your endgoal to build a better switch? 🙂 Have you digged too deep here?
<azonenberg>
Lol
<azonenberg>
The switch project is still happening
<azonenberg>
The RJ45s and FPGA and PHYs for the first prototype are on order and will be trickling into my inventory over the spring to summer of 2022
<azonenberg>
(ordered back in fall 2021)
<azonenberg>
hopefully by the time they arrive i will have had time to do some work on the board
<azonenberg>
All of these projects are kinda one big interconnected web of dependencies and relationships
<azonenberg>
I need the probes to make effective use of the scopes
<azonenberg>
glscopeclient to analyze waveforms from the scopes
<azonenberg>
a fast LAN to get data off of them
<azonenberg>
the probes and glscopeclient to debug the switches
<d1b2>
<dannas> goes back to reading spinningnumbers.org, the black magic book and https://pysdr.org/index.html for getting an overview of the fundamentals
<azonenberg>
top = right off the cable, bottom = cables deembedded
laintree is now known as lain
massi has joined #scopehal
<d1b2>
<mubes> @dannas Could you PM me your full name please for the author line in the Siglent driver?
<d1b2>
<mubes> @dannas / @mandl In respect of the outstanding issues that are mentioned in the SDS1104X-E driver; (1) The 'Reload Configuration' is worth re-checking because we changed the way that works recently (specifically, it refreshes all windows as soon as the config is reloaded). That's likely to at least mask the behaviour you've documented here. (2) For memory depth you'll probably need to stop the scope yourself, then make the change, then return
<d1b2>
it to whatever state it was in previously and (3) The socket timeout is usually that you've borked the protocol somewhere and what's coming back isn't aligned with what you are sending. If you start the program with --debug --trace SiglentSCPIOscilloscope then you can look to see where you're getting out of step.
<d1b2>
<dannas> Inspecting the traffic with Wireshark might give some clues as well. I'll test the code on my scope this evening and report my findings here.
<d1b2>
<mubes> Perfect, ta!
<d1b2>
<mubes> The debug dump isn't 100% accurate because the logging routines are bypassed by the sample-collection code (to avoid the guard timeouts) but wireshark will deffo get it right.
<azonenberg>
Degi, someone-else: yes the SDA816 has aliasing issues sometimes. i think some of the fine zoom settings are not actually changing frontend gain and just doing 'digital zoom' stretching the view into less adc codes
<azonenberg>
so you get quantization issues
<azonenberg>
i actually did a 10x upsampling to make it less bad
<azonenberg>
the native view straight off the scope looks like a star wars hologram effect wtih dark lines across it like crazy
<azonenberg>
this is much less bad but still somewhat noticeable
<azonenberg>
Doing any kind of DSP filter like a de-embed or FIR smooths out the quantization noise
<someone-else>
azonenberg: perhaps configurable dither on glscopeclient side can help
<azonenberg>
i might look into that at some point but for now you could simulate that by using the noise filter
<azonenberg>
with amplitude set to roughly 1 lsb
<Degi>
Can you restrict the noise to be outside of the scopes bandwidth?
<someone-else>
azonenberg: yep, that's mostly the same thing, I think
<someone-else>
apart from possible noise shaping
<someone-else>
dunno if it makes sense in this case
<azonenberg>
Degi: you could hypothetically do that, yes. the noise filter generates gaussian noise but you could then apply a FIR high pass to it
<azonenberg>
and then sum that with the input waveform
<azonenberg>
there's no way to directly generate noise with specific spectral characteristics in a single filter at the moment though
<azonenberg>
Just AWGN
mandl has quit [Quit: Leaving]
massi has quit [Remote host closed the connection]
Bird|ghosted has quit [Ping timeout: 268 seconds]
Ekho has quit [Ping timeout: 256 seconds]
Bird|otherbox has joined #scopehal
bvernoux has joined #scopehal
<azonenberg>
Also... working on Digilent WaveForms support again
<azonenberg>
Found a bug in their library that has a new / free vs new/delete mismatch
<azonenberg>
which is apparently getting patched in the next release
<azonenberg>
but for now it makes debug builds of my code annoying because asan complains
<azonenberg>
apparently it's been there for 13 years since the initial release
<azonenberg>
which i can only imagine means i am the first person to ever run a program using libdwf under asan :p
<d1b2>
<dannas> Doh, and there the scope hanged. Not responding to keypresses or connection attempts. But I can still ping it. That's something atleast 🙂 Happened after I tried to restart a glscope debugging session.
<d1b2>
<dannas> Well, well. Power-button my sweat friend.
Ekho has joined #scopehal
<azonenberg>
yeah we have seen firmware hangs on occasion. if you can reproduce it we can send siglent a bug report
<azonenberg>
as far as an exact list of commands to replay that reliably hangs it
<d1b2>
<dannas> Before that happened I was trying to figure out why glscopeclient does not display wveforms with the parameters I'm expecting.
<d1b2>
<dannas> I think that I had just sent a few queries for voltage_div and time_div, so might be reproducible.
<d1b2>
<dannas> Will try later. Now let's see if I can figure out why glscopeclient starts off zoomed into the nanosecond range even though tehe scope is in hundreds of microsec timerange.
<azonenberg>
i think the default powerup zoom is constant hard coded somewhere
<azonenberg>
as of a day or two ago. there is an autoscale feature accessible via the middle mouse button
<azonenberg>
push that and it should change zoom to show the entire waveform
<azonenberg>
(autoscaling on startup is probably not a bad idea but i dont currently do this)
<d1b2>
<dannas> I tried pressing the middle mouse button. I do see that the waveforms reacts to it, but it's still very zoomed in and does not show the whole waveform. I'll keep digging and see what's gone wrong in the driver.
<d1b2>
<dannas> It would be cool if the middle button would zenter the waveform if pressed on the voltage scale, like how the Siglent scopes vertical position knob centers the waveform on screen when I push it
<d1b2>
<dannas> Or is it a bug in the driver that causes the voltage scale to not have my waveforms centered around 0.0V?
<d1b2>
<dannas> I had expected the scale to use a little less arbitary steps.
<d1b2>
<dannas> I was expecting to see a small arrow at the middle of the screen horizontally. I do see an arrow vertically.
<azonenberg>
there should be an arrow at the top of the display in the timeline
<d1b2>
<dannas> goes to read the glscopeclient manual
<azonenberg>
if you dont see one the trigger config is incorrect
<azonenberg>
GetTriggerOffset() is the method of interest
<d1b2>
<dannas> Ok, one more thing to fix. 🙂
<azonenberg>
and SetTriggerOffset()
<azonenberg>
argument is femtoseconds from start of the waveform
<Degi>
I wonder if that will ever be a problem
<electronic_eel>
azonenberg: i just stumbled across the datasheet of the new TI BUF802 opamp. they have a quite comprehensive explanation of using it for a 1 GHz oscilloscope frontend in it. maybe this is of interest for you https://www.ti.com/lit/gpn/buf802
<Degi>
Oh neat, a gain of one amplifier which doesn't require external components in the RF path
<someone-else>
it's basically the same jfet + opamp circuit everybody was using since forever but nicely integrated and with up to 3ghz bw
<someone-else>
pretty nice for 1ghz 1meg scope frontend path
<someone-else>
input capacitance is bit high though, might limit attenuator options
<electronic_eel>
they don't have a direct dc path into the opamp, but split dc off to a secondary precision opamp. that is something azonenbergs current frontend design doesn't do
Bird|otherbox has quit [Ping timeout: 240 seconds]
<Degi>
Hmm, the 50 Ohm termination kinda does that
<Degi>
At least I remember some secondary OP amp to compensate for zero offset or so
<electronic_eel>
Degi: yeah, a secondary opamp was necessary to compensate the offset setting, otherwise current would have flown out of the probe.
<Degi>
It would be nice to be able to center Vcm around ground, though sadly most ADCs don't like that / though might work with JESD204 since its outputs can be AC coupled
<electronic_eel>
but i mean the dc blocking cap in the main signal path of the ti buf802 schematics. that is something that is not in azonenbergs afe, and i think doing it this way could improve performance
<Degi>
Hm yes, I think the OP amp circuit also had some flatness issues, at least the way I designed it hmm
<azonenberg>
degi, electronic_eel: I plan to respin the frontend some time later in the spring with 500 MHz BW and dual SMPM outputs
<azonenberg>
and common mode appropriate for the AD9213
<azonenberg>
so that will be a good time to make whatever other tweaks we want to
<electronic_eel>
yeah, i remembered that. thought the datasheet might give you some ideas
<someone-else>
split dc/ac path is a classic design which allows using an open-loop jfet at high frequencies and a dc servo loop to cancel all temp-dependent drift
<Degi>
We could use SATA to pass offset voltage to the frontend and pass the signal to the ADC 🤔
<azonenberg>
split ac/dc path is something I plan to do in the AKL-AD2 if/when i ever work on that too
<Degi>
Though what about temperature dependent gain drift?
<azonenberg>
since that 10 GHz diff amp i was looking at can't be DC coupled
<someone-else>
but it's much easier to just use a normal closed-loop opamp nowadays
<azonenberg>
well, it *can* be DC coupled
<azonenberg>
but Vicm != Vocm
<azonenberg>
so one leg has to be ac coupled :p
<Degi>
Huh
<azonenberg>
iirc it was like 1300 and 400 mV out/in or something?
<someone-else>
well, for probes it's entirely another matter
<azonenberg>
the ADI FAE i talked to hinted that this was basically a custom part they designed for R&S
<azonenberg>
and it was made to suit R&S's specific requirements for some instrument
<azonenberg>
i.e. the actual levels that their board design had
<someone-else>
btw one way to do a frontend these days is to ac-couple everything (including input attenuators, variable gain amplifiers etc) and use a 1-10msps 16-20bit adc with a fixed attenuator as dc path
<someone-else>
seemed to work on paper when I looked at ti
<someone-else>
*it
<someone-else>
could work for probes even
Bird|otherbox has joined #scopehal
<Degi>
Hm yes, that also allows for flatness compensation in software
<electronic_eel>
interesting concept
<Degi>
Also it could be used for an isolated probe lol, have an ADC on the input for the DC part, use a transformer to couple RF and a DAC on the output to add the DC back in
<electronic_eel>
getting precise level triggering for slowly changing signals could be hard, because the trigger circuit must be aware of the whole adc mixing + flatness calculation path
<Degi>
Hm yes, that must be done after they have been brought together again
<someone-else>
fully digital trigger is used on some r&s scopes, so it must be doable
<someone-else>
at least if your adc sampling rate is far enough from nyquist
<Degi>
Hmm, don't most scopes support that nowadays? Like triggering on RS232 pattern even
<someone-else>
yep, but they also might have a hardware level trigger
<Degi>
Hmh, tbh I think my scope is fully software, since even at 2 GS/s on 350 MHz the oversampling should be high enough for that
<Degi>
Do we wanna use one AD9213 on an only 500 MHz channel?
<Degi>
12:1 oversampling sounds a bit excessive, unless the falloff is really flat
Bird|otherbox has quit [Ping timeout: 268 seconds]
<electronic_eel>
yeah, in this range of scopes it should be possible without problems. but when you for example got 10 GSPS and want to squeeze out 2 or 3 GHz out of it, it will not work that well
<someone-else>
high oversampling, if you can afford the adc for it, can increase the snr
<Degi>
I mean yeah we could also downsample it to get 14 bit at OSR of 3 (or 1.5? Its 1.5 times nyquist)
<someone-else>
also memory bw requirements (costly) can be reduced if downsampling is performed in the fpga before storing samples to memory
<Degi>
Does it make sense to use the actual impulse response of the oscilloscope instead of a sin(x) / x filter to interpolate samples or would that have aliasing issues or something like that?
<Degi>
Hm right, the S parameter compensation can already do that...
<someone-else>
ad9213 has ENOB of ~9 bits at <1GHz, so 12x oversampling could get this up to 10-11 I think
<azonenberg>
Degi: It will be 10:1
<azonenberg>
the AD9213-6 is 6 Gsps max sample rate
<Degi>
I see
<azonenberg>
but i can only run it at 5 Gsps with an artix7
<azonenberg>
because the GTP maxes out at 6.25 Gbps
<Degi>
Hmm, 11 ENOB sounds nice... I think my scope only has 6 or 7
<azonenberg>
that gives a nice even 10:1 oversampling ratio
Bird|otherbox has joined #scopehal
<azonenberg>
The current ZENNECK design is really a stepping stone to VOLLUM
<azonenberg>
The 10 Gsps VOLLUM is intended to be 1-2 GHz BW
<azonenberg>
And yes my plan is to do full s-param compensation for flatness of the whole frontend
<electronic_eel>
but the s-param compensation is in postprocessing in glscopeclient, not in the fpga?
<azonenberg>
I'm not sure on that part yet
<Degi>
We should make a version of VOLLUM where the inputs go straight to the ADCs and call it GOLLUM
<electronic_eel>
Degi: you'd need a ring for that
<azonenberg>
Depends on the exact fpga i use, how many DSPs it has, etc. I might at least attempt to do initial flatness correction in the FPGA but we'll see
<d1b2>
<mubes> @dannas the X position of the trigger needs to be calculated...look at the SDS2000XP case and you'll see what I mean. It's painfully easy to get the calculation wrong (experience). When you've got it right you should be able to pick up the X cursor (the one at the top) and move it left and right and see it move in a corresponding fashion on the scope screen...assuming the 1000 does it in a similar way to 2000XP.
<azonenberg>
yeah but you probably need a few copies of each for noise isolation
<azonenberg>
JVTT is most likely serdes termination, analogous to xilinx MGTAVTT
<Degi>
Yes 19 rails, but some internally generated but still need a cap
<Degi>
Hm right, VTT
<azonenberg>
then JVDD and JVDD2 are probably the analog and digital supplies for the JESD204 PHY
<azonenberg>
one for the main serdes and one for the pll or something
<azonenberg>
but i havent looked at the datasheet at that level yet
<azonenberg>
i certainly will be before designing the board
<Degi>
JVTT is termination, JVDD and JVDD2 is JESD204B
Bird|otherbox has quit [Ping timeout: 250 seconds]
<azonenberg>
Also before building that board, I want to build a smaller scale board with some kind of single lane jesd204 adc on it
<azonenberg>
just to get some experience with the whole jesd204 stack
<Degi>
SVDD2 is 2 V for SPI and digital IO, DVDD is core supply, TMU_DVDD1 is temperature measurement unit supply, AVDDFS8 is the analog supply for clocks with fs/8 energy (interesting), a bunch of analog and clock supplies, a 3 V and -2 V supply for internal input buffer, that would explain the CM voltage of 0.5 V