<azonenberg>
Thinking of moving the clamp diode to the far side of the attenuator so i have the 37 ohm resistor to limit current through it
<azonenberg>
and of course the resistor values right now are ideal, not standard values
_whitelogger has joined #scopehal
<azonenberg>
also hmm, the ADL5205 is perhaps overkill
<azonenberg>
but has -3 dB bandwidth out to 1.7 GHz which means i could use it on the higher end AFE too
<azonenberg>
digitally programmable gain
<azonenberg>
probably not the full high end version with 1 GHz bandwidth, but i think it would work nicely on a midrange-ish unit
<azonenberg>
It can do up to 25 dB of gain out to 1 GHz, at which point it starts falling off
<azonenberg>
and down to... -9 dB, it looks, of attenuation
<azonenberg>
It's a bit pricey at $19.69 per 2 channels, but that isnt TOO bad
<azonenberg>
drops down to $14 @ qty 250
<azonenberg>
I think i'll use it in the prototype and see how i like it
<azonenberg>
Right now my digikey order for the prototype is $67.46. This includes 100 TVS diodes that i'll be using in other projects too, one opamp, one 8-channel DAC ($25, but will be shared by all channels in the scope), and one 2-channel VGA
<azonenberg>
Then I'll probably slap a stm32f031 out of my existing stockpile on there to run a little uart CLI to configure things
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvPJj
<_whitenotifier-3>
[scopehal] azonenberg 6bd1ad9 - Fixed missing initialization in EyeDecoder2
<zigggggy>
azonenberg beware the ides of march
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JvPU8
<_whitenotifier-3>
[scopehal-apps] azonenberg ca0d0b9 - OscilloscopeWindow: make sure eye patterns have been resized before replaying history
<_whitenotifier-3>
[scopehal-apps] azonenberg 96b49a7 - WaveformArea: refresh eye patterns off the current waveform immediately when resizing
<awygle>
what's the rendering pipeline look like for glscopeclient?
<azonenberg>
awygle: at a high level, it's a compositing engine that renders (per waveform area) three textured quads
<azonenberg>
the first one is underlays (graph background and axes), cairo rendered then pushed to a texture. In the future i'd like to cache this texture and only rerender when scales change or the window is resized
<azonenberg>
second is the main waveform itself, rendered via a compute shader to a texture directly from sample data
<azonenberg>
third is software rendered overlays - cursors, channel info boxes, complicated protocol decodes (anything that displays text basically)
<awygle>
interesting
<awygle>
why compute shader?
<azonenberg>
Previously i tesselated waveform data to triangles in software and did normal vertex/fragment processing
<azonenberg>
it was actually quite a bit slower and gave worse looking results
<azonenberg>
now i do the intensity grading and rendering directly, taking advantage of the L-R sort of the waveform
<azonenberg>
i render one column of pixels per threads
<azonenberg>
per thread*
<azonenberg>
antialiasing etc will work much nicer with this architecture moving forward too
<azonenberg>
The long term vision is to be doing protocol decodes in compute shaders too, so having waveforms in SSBOs is a natural fit for that
<azonenberg>
i'll be working on optimizing the storage formats to reduce the amount of manual shuffling of data between different formats that i have now
<awygle>
it seems like you should be able to do it in the regular rendering pipeline without software tesselation
<awygle>
but i guess no real reason to
<azonenberg>
the issue is that i need to convert the voltages to triangles somehow
<azonenberg>
since GL_LINES is basically deprecated
<azonenberg>
and variable width, AA, etc isnt well supported
<azonenberg>
You'd need to either do something funky with a geometry shader to convert the voltages into triangles, or just skip the whole geometry transformation path. I got massive framerate increases with this approach
<azonenberg>
error handling during file load needs a fair bit of work
<azonenberg>
there's a number of cases that can crash/hang, e.g. trying to reconnect to an instrument that's not there
<monochroma>
azonenberg: color ramp did not load the same as your screenshot, not sure it matters but wanted to point it out
<azonenberg>
Color ramp is a user preference that is currently not serialized
<monochroma>
that's what i figured
<azonenberg>
havent decided if i want to make that be in a user dotfile or in the session file or what
<monochroma>
hmmm
<azonenberg>
right now it resets to crt every time you start the app
<monochroma>
yeah
<azonenberg>
i think it should be a user setting, i cant think of a reason why you'd want to have different ramps per project as default
<azonenberg>
but right now i don't have a user settings file at all
<monochroma>
oh
<monochroma>
is the history window supposed to load ?
<azonenberg>
It's hidden by default
<azonenberg>
the show/hide status of the history window is not currently serialized, it always defaults to hidden
<monochroma>
huh
<monochroma>
in the history window
<azonenberg>
additionally all protocol analyzers always are shown when you load a session, the show/hide state is not serialized
<monochroma>
mine says "1 WFM / 33 MB" your history window says "1 WFM / 27 MB"
<azonenberg>
this ties into the fact that once an analyzer is closed you can't get it back, there's no UI to re-show it
<azonenberg>
interesting, we'll have to dig into that more. wonder why that is
<azonenberg>
my shot was before saving
<azonenberg>
its possible some data structure isnt quite the same before and after
<azonenberg>
i know i currently have what looks like a memory leak when a save file is closed, but it only seems to be related to protocol decoders
<azonenberg>
anyway, short term what i'm interested in is some kind of serial waveform off your DDA that i can reproduce the eye issue on
<monochroma>
azonenberg: sure, it's connected to the HDMI/DVI probe board right now, that work for ya?
<azonenberg>
anything exhibiting that rendering artifact
<monochroma>
ah yeah, that's what i'm getting it from
<monochroma>
azonenberg: oh just noticed the waveform group numbering/naming is a bit off in the load
<monochroma>
lol
<monochroma>
i have the protocol analyzer window open in your ethernet demo
<monochroma>
when i open a file dialog the protocol analyzer window's theme switches to the white theme of the file dialog window. iirc i remember you dealing with this, and found GTK is a derp about such things
electronic_eel has quit [Ping timeout: 255 seconds]
electronic_eel has joined #scopehal
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #scopehal
<azonenberg>
monochroma: yes. not sure if i filed a bug on it
<azonenberg>
basically so far, i have not found a way to un-theme or selectively theme single windows
<azonenberg>
right now i load the dark scope theme at startup but it applies to EVERYTHING, i then un-theme everything during file open because the dialog looks really weird themed
<azonenberg>
if you want to look into how to selectively un-theme that dialog go for it
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #84: Refreshing eye decoders in on_resize is slow - https://git.io/JvPlC
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #82: Crash after failing to reconnect to an unavailable scope when loading a session - https://git.io/JviAe
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #83: glscopeclient: Crash when trying to load a scopesession that doesn't exist - https://git.io/Jvix5
<azonenberg>
Anybody want to look into making a driver for the BK Precision 2120? :P
* azonenberg
hides
* zigggggy
testing the repacker
<electronic_eel>
I volunteer doing a driver for the Tek 465 ;)
<azonenberg>
lol
<zigggggy>
azonenberg im stuck
<zigggggy>
azonenberg do you know how IDispatch works in COM?
<azonenberg>
zigggggy: i havent done com stuff in 10+ years. So, not really
<azonenberg>
i know the high level basics
<azonenberg>
TIL: you can buy *relays* in BGA form factor
<azonenberg>
ok so i made some more tweaks to my AFE design
<azonenberg>
I think the silicon should be good to several hundred MHz, maybe even close to a GHz, if you used a suitably high spec attenuator on the input and an appropriate antialiasing filter. The initial prototype will use discrete resistors for both the attenuator and filter, targeting 100 MHz BW which should be a cakewalk
<azonenberg>
The new DAC I'm planning to use (AD5693) has a 0-5V output range which, at 16 bit resolution, gives 76.2 μV/LSB offset resolution which is honestly overkill
<azonenberg>
We can cost-down to a lower spec DAC later on if we decide to
<azonenberg>
The +/- 5V range 50 ohm input is attenuated by 12 dB (0.25V/V) to bring it within range for other parts of the system
<azonenberg>
This brings it to +/- 1.25V. The offset stage shifts it by a variable voltage of at least 1.25V, moving the entire signal above ground so I can use single supply components later on
<azonenberg>
So i'll probably set the gain stage input common mode to somewhere around 1.65V as that's a convenient value (vcc/2 for 3.3V)
<azonenberg>
The gain stage applies -9 to +26 dB of gain and also converts the single ended output to differential with a 1.2-1.8V common mode
<azonenberg>
Which is the end of what this board does
<electronic_eel>
wouldn't it be better for low noise figures to have the gain before the offset?
<azonenberg>
If you have gain before offset and your signal has any significant DC bias, e.g. TMDS is a few hundred mV on a 3.3V offset, you're screwed
<azonenberg>
you have to be ~unity gain to avoid clipping
<azonenberg>
and then you lose resolution
<azonenberg>
By putting offset first, you can de-bias the input (without losing the offset and causing baseline wander like you'd get with AC coupled input)
<azonenberg>
then have gain on the AC component of the signal
<azonenberg>
anyway, there's one last wrinkle i need to figure out
<azonenberg>
The ADL5205 has a variable 1.2-1.8V common mode on the differential outputs when running on a single 3.3V supply (nominal 1.65 but you can shift it)
<azonenberg>
The HMCAD1520 ADC's nominal common mode input range is 0.5*Avdd and Avdd is nominal 1.8V so 900 mV common mode
<azonenberg>
I think i can fix this by doing a final 3 dB of attenuation
<azonenberg>
Which will bring a 1.8V common mode down to 900 mV
<azonenberg>
But then i'll lose 3 dB of gain, which will put my max system gain as +11 dB
<azonenberg>
Or 3.55:1 voltage gain. Which means ~563 mV full scale is the max input voltage, and I'll have 137 μV/LSB in 12-bit mode or 2.2 mV/LSB in 8-bit mode
<azonenberg>
at max gain
<azonenberg>
I'll experiment a bit and see what i can fine tune to keep all of the various parts in range for each other, i think i can improve on that
<azonenberg>
Having 12 dB of front end attenuation is probably overkill. I'm hopeful i can cut that down a bit. Might need to shift the offset stage to use a higher supply voltage so it doesn't clip
<azonenberg>
If i use say +/- 12V instead of +/- 5V i could probably us a 6 dB front end attenuator instead, which buys me 6 dB more headroom for later on
<electronic_eel>
how does that compare to other scopes? they usually have 1mV/div, but then some smoke screen that hides how that relates to V/LSB
<azonenberg>
Standard is 8 divisions. At 8 bit resolution that's 32 codes per div
<azonenberg>
so 31.25 μV/div at 1 mV/div
<electronic_eel>
but only if the 8 bits really align to the full 8 divisions and it is not just digital zoom with like 16 div for 8 bits
<azonenberg>
Correct
<azonenberg>
with scopehal i could figure that out, at least for my lecroy gear
<azonenberg>
because there are scpi commands to read the actual gain/offset values from the hardware and the waveform download is raw 8 (or 10/12 padded to 16) bit adc codes
<azonenberg>
so if gain stops growing as you zoom in more thats a hint
<azonenberg>
anyway, i'm going to spend a while more experimenting and playing with different parts to see how i can maximize usable adc range
<azonenberg>
this is one of the nice bits about open source test equipment, you won't have to wonder about actual capabilities
<electronic_eel>
maybe two gain stages? one fully programmable like your ADL5205, but then add another with just a few steps before it?
<azonenberg>
Yes. Like i said this project is still fairly early in the design phase
<azonenberg>
What i might do is make the input attenuator programmable
<azonenberg>
i need input attenuation in order to not max out various stuff downstream with 5Vrms inputs
<azonenberg>
But if i can remove that attenuation at higher gain values, that would be great