<_whitenotifier-9>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfsTR
<_whitenotifier-9>
[starshipraider] azonenberg b31e12b - Stop trigger when client closes the socket to avoid spamming waveforms into oblivion
_whitelogger has joined #scopehal
<_whitenotifier-9>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JfsI3
<_whitenotifier-9>
[scopehal] azonenberg c8dd004 - AntikernelLabOscilloscope: initial implementation of offset changing. Acting a bit funny.
<azonenberg>
ok so offset can be changed in the UI but acts... wrong, i'm not quite sure how to describe it. Like there's a scaling factor somewhere that shouldn't be
<_whitenotifier-9>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfsIj
<_whitenotifier-9>
[scopehal-apps] azonenberg closed issue #54: Allow changing channel vertical offset by dragging Y axis scale in WaveformArea - https://git.io/Jv8sC
_whitelogger has joined #scopehal
<Degi>
hmh how do I install it
<miek>
recursive clone scopehal-cmake, mkdir build, cd build, cmake .., make
<azonenberg>
so it looks like basically all of the chips TI uses in appnotes with the LMH6552 have no input termination
<azonenberg>
Which explains the output resistors
<azonenberg>
i think if i 0R them we should be good
juli963 has joined #scopehal
<azonenberg>
ok that's a lot more like it
<azonenberg>
with 515 mV p-p input, I measure 414 mV at the output of the AFE. So there's still some loss we need to explain
<azonenberg>
To be clear, this is 414 mV measured by scopehal on the ADC output
<azonenberg>
With the ADL5205 set to a gain of +4 which should translate to a 0 dB end to end gain
<azonenberg>
Interestingly we're almost *exactly* 2 dB below where we should be if my math is right
<azonenberg>
When i set the gain too high i start seeing weird effects on the output now
<azonenberg>
Huge ringing on the output. I wonder if something is clipping
<azonenberg>
Clearly more debugging needed
<azonenberg>
Gonna start doing some end to end probing and see how stuff looks at each stage of the frontend in a bit
<azonenberg>
ok so, the input signal is a 5 MHz squarewave, just about perfectly centered on zero (mean of -1 mV)
<azonenberg>
Amplitude of 465 mV p-p
<azonenberg>
The output of one leg of the amplifier is 120.5 mV p-p. Assuming the swing is symmetric for the moment, the differential swing is 241 mV p-p
<azonenberg>
Which is a net gain of 0.518 or about 4% off from the nominal 0.5 attenuation we wanted
<azonenberg>
Which should be well within the realm of what we can correct for by calibration
<azonenberg>
After the VGA with a nominal gain of 0, i measure 108 mV p-p. So the nominal unity gain setting has a gain of about 0.897
<azonenberg>
With a gain of 6 (which should in theory invert the losses of the fixed front-end attenuator) I measure 209 mV p-p. This is a differential swing of 418 mV p-p given an input signal of 465 mV p-p. So also about 0.89x
<azonenberg>
With a gain of 16 I measure 653 mV, or gain of 5.419 V/V through the VGA only. This is 14.67 dB vs the nominal 16
<azonenberg>
At 20, i see 1.02V or 8.464 V/V, 18.55 dB
<azonenberg>
And at max gain of 26 dB I see 1.995V or 16.55 V/V, 24.37 dB
<azonenberg>
Measuring relative to the nominal gain of 0, 6 -> 5.73, 16 ->15.62, 20 -> 19.50, 26 -> 25.32
juli963 has quit [Ping timeout: 258 seconds]
<azonenberg>
So basically the VGA's actual gain is about (0.975*requested gain) - 1 dB
juli963 has joined #scopehal
<azonenberg>
Which i find interesting, because the datasheet says that the gain step accuracy is supposed to be +/- 0.2 dB
<azonenberg>
And i'm seeing errors substantially more than that
<azonenberg>
lain, electronic_eel, degi: ideas?
<monochroma>
hmmm can you take everything but the VGA out of circuit to test it in isolation?
<azonenberg>
note that all of these numbers right now are based on single ended measurements of one VGA leg
<azonenberg>
monochroma: funny you ask
<azonenberg>
the VGA is dual channel
<monochroma>
:O
<azonenberg>
The other channel is broken out to SMAs
<monochroma>
handy
<azonenberg>
i'd have to write some firmware to control the other channel, but i do have the ability to drive it with a SMA stimulus and observe the output
<monochroma>
i usually tie unused ones off to prevent any unconnected I/O issues
<azonenberg>
conjecture: some of this error is due to the LMH6552 circuit on the output of the VGA
<azonenberg>
maybe it's loading the output down or something
<azonenberg>
which isn't necessarily a fatal problem so much as something we need to account for in calibration
<azonenberg>
perhaps by adding more gain to the final amplifier or something
<azonenberg>
As long as it's predictable, i dont see that as being a problem
<monochroma>
yeah, good practice to trace down the inconsistancies between theory and implementation
<azonenberg>
OK so, moving on
<azonenberg>
All the way to the output of the AFE
<Degi>
Hm what do you probe with? Any capacitive loading?
<azonenberg>
I'm using a lecroy pp023 which is a 10 pF || 10M passive probe
<Degi>
Hm and 5 MHz
<azonenberg>
but i'm looking at a 5 MHz signal. i figure it might affect edge rates a tiny bit but not the amplitude of the signal
<azonenberg>
that's practically DC :p
<Degi>
Hmm!
<Degi>
ADL5205 has 10 ohm output R
<azonenberg>
Anyway... With VGA gain of 0 i see 135 mV p-p at the + output of the AFE which is 270 mV differential. Input is 465 mV so this is a net gain of 0.58 or -4.73 dB. The nominal design gain was -4 under these conditions
<azonenberg>
With VGA gain of 4 (which should null out the frontend attenuator's loss) I see 210 mV which is 420 differential, vs 465 input so net gain of 0.903 or -0.88 dB
<Degi>
What is -4 dB in volts
<Degi>
1.58x?
<Degi>
*0.63
<azonenberg>
20*log10(V/V gain)
<Degi>
Hmh
<azonenberg>
or 10^(dB/20)
<azonenberg>
to go the other way
<Degi>
I think R13 and R14 forgot about the 10 ohms
<Degi>
Without the 10 ohms we'd have 0.67x at the output if with them we have 0.58
<Degi>
Hm that'd be -3.48 dB not 4
<azonenberg>
It might not be exactly 10 ohms
<azonenberg>
let me see the datasheet again
<azonenberg>
oh
<azonenberg>
differential output resistance is 10 ohms
<azonenberg>
does that mean 5 on each leg?
<Degi>
It says 10 ohm and doesnt give an error
<Degi>
Hmw ait a sec
<azonenberg>
maybe we want to drop the 100 ohms down to 95?
<Degi>
If it were 5 ohm (and reduced R13 and R14 by 5 ohms) then we'd get -4.31 dB
<Degi>
Currently we have -4.73
<Degi>
Id suggest 92 ohms
<Degi>
We can compensate by 10 % in the ADC but we need to not forget about per channel FSR errors too
<azonenberg>
we can also compensate in post with a scaling coefficient. In the actual scope i will store a cal constant per channel per gain setting
<azonenberg>
i.e. we'll know that +1 dB on channel 2 is actually +1.03 dB and scale the ADC output appropriately
<Degi>
Actually we should try compensating per channel with analog circuitry first (which is built into the HMCAD)
<azonenberg>
Yes but i want to get the VGA gain as close as we can before trying to correct in post
<azonenberg>
oh you mean for correcting for cal errors on the VGA?
<Degi>
The HMCAD has built in FSR adjust
<azonenberg>
yes, we can compensate in the ADC vs scaling the output in software, that would be nice
<azonenberg>
my point was more that we will have a table of gain/offset error values per channel stored somewhere
<azonenberg>
Where we apply the corrections is TBD
<azonenberg>
The sad thing is, i just paid $5 in shipping *THIS MORNING* making a digikey order
<Degi>
We should store cal data for each of the 8 branches
<Degi>
oof
<azonenberg>
just a handful of SMA couplers
<azonenberg>
and i just did one for a customer the day before or so lol
<azonenberg>
Yes, we will store ADC cal data per branch as well
<azonenberg>
But that will be applied later on in the process depending on the ADC channel config
<azonenberg>
i.e. which branches are being used for which channels
<azonenberg>
as opposed to the VGA gain error, which follows the AFE
bvernoux has joined #scopehal
<azonenberg>
Possible error sources are...
<bvernoux>
hello
<azonenberg>
reference voltage error on the DAC causing a scaling of the offset voltage
<bvernoux>
I have just tested to solder 2 SMA High Freq connector using Glue before
<bvernoux>
it is clearly not easy ...
<azonenberg>
static offset error on the DAC output buffer
<Degi>
Hm the fSR adjust is apparently not per channel, but there is fine gain per channel from -0.066 to +0.066 dB
<bvernoux>
also i tried PBFree solder ...
<azonenberg>
static offset on the input amplifier
<azonenberg>
(which is amplified by the VGA and thus has to be compensated differently depending on gain)
<azonenberg>
static offset on the VGA
<azonenberg>
which is amplified by the final amp, but i think we can fold that offset and the final amp's offset into one cal constant because the final amp has fixed gain
<azonenberg>
then gain error of the signal through all 3 amps
<azonenberg>
At some point we'll have to sit down and come up with a full list of cal measurements we need, how many coefficients we have to store
<Degi>
Im kinda unsure why we have U6
<azonenberg>
and at what phase of the signal chain we correct for each error
<azonenberg>
U6 does two things
<Degi>
Ah the 0V9
<azonenberg>
first, shifts the common mode signal from the 2.5V that the ADL5205 uses to the 900 mV Vcm of the HMCAD
<azonenberg>
second, applies 2 dB of fixed gain to make max use of the ADC full scale range
<Degi>
So at a gain of the VGA of -9 dB and input at +- 5 V you get FSR on the ADC?
<azonenberg>
That's the idea, yes
<Degi>
Uhm also did you let R30-31 in or 0R them too?
<azonenberg>
-6 dB fixed input attenuation, -9 to 26 on the VGA, 2 dB fixed gain at the end
<azonenberg>
let me see
<azonenberg>
I swapped R30/31/32/33 all out to 0R
<Degi>
Hmh unsure but that may not be the best idea
<Degi>
Because stuff will get reflected back from the HMCAD test board proably
<azonenberg>
the ADC has a 100R input terminator
<azonenberg>
that should absorb it, no?
<Degi>
Ah k
<azonenberg>
Also 92 is not a standard resistor value
<Degi>
Yeah I havent looked at the test board recently
<azonenberg>
options are 91 and 93.1
<azonenberg>
91 is closer so i'll get that?
<Degi>
Hmh idk, maybe 93.1? Thats between 92 and 95
<Degi>
I calculated the 92 for this specific device...
<Degi>
Well 0.58 / 10^0.2 * 100
<azonenberg>
Ordered
<azonenberg>
ok here'sanother problem
<azonenberg>
with R32/33 removed, the output clipper doesn't work right
<Degi>
You could move then between U6 pin 4 and R28 or pin 5 and R29
<azonenberg>
no you misunderstand
<azonenberg>
the diodes need series resistance to avoid overloading
<Degi>
Hmh can they do 100 mA?
<azonenberg>
idk about thermal limits, but i know if you put too much current through them the Vf gets too high
<azonenberg>
We might be able to just use bigger diodes on the final board, idk
<azonenberg>
But it's something to look into
<Degi>
for scopehal do I just run cmake in the scopehal directory and execute the resulting executable?
<monochroma>
Degi: there are many binaries generated
<monochroma>
the assumed build procedure is to make a build directory, and run cmake in there
<monochroma>
and then make
<Degi>
whats sigc++
<Degi>
I mean i have libsigc++ installed but make complains about sigc++/sigc++.h missing
<miek>
you probably need the -dev package
<Degi>
Hmm I guess I can just clone the libsigc++ repo or something... arch linux doesnt seem to have a dev pakage
<miek>
oh, arch. it should be there in the normal package then
<monochroma>
hmm i don't remember having problems with that last time i built it on arch
<miek>
are you building the scopehal-cmake repo?
* monochroma
got sick of arch's rolling release constantly breaking things and moved to debian for her scopehal dev system
<Degi>
I mean I have libsigc++ installed
<Degi>
And scopehal from the git repo, executed make in scopehal/scopehal directory
<miek>
clone 'scopehal-cmake', not 'scopehal'
<monochroma>
and you have to recursively clone subrepos
<Degi>
Hmh why does it want my ssh key passphrase when I git clone recursive...