azonenberg_work has quit [Ping timeout: 256 seconds]
azonenberg_work has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #scopehal
juli965 has joined #scopehal
<azonenberg>
LeoBodnar: ping
<azonenberg>
So I see that the LeoNTP device has a single BNC output with PPS, 1 MHz, or 10 MHz outputs
<azonenberg>
There's no way to get both out of a single unit?
<azonenberg>
is that a limitation of your circuitry or the GPS module? And is the 10 MHz straight off the GPS module or filtered via some kind of PLL etc?
<azonenberg>
it seems like right now if i want stratum 1 NTP, PPS, and a frequency reference that I will be best off using a LeoNTP for time+PPS and a GPS-CLOCK for the 10 MHz?
<azonenberg>
Also yay it looks like the probe PCBs are coming early, expected today some time
<_whitenotifier-f>
[scopehal] azonenberg opened issue #280: Allow sample rate/memory depth of SignalGeneratorOscilloscope to be changed - https://git.io/JUPVO
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #280: Allow sample rate/memory depth of SignalGeneratorOscilloscope to be changed - https://git.io/JUPVO
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUPwe
<_whitenotifier-f>
[scopehal] azonenberg 9f362a5 - Refactored PeakDetectionFilter out to PeakDetector + PeakDetectionFilter
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUPwT
<_whitenotifier-f>
[scopehal-apps] azonenberg 8d3308a - Now render PeakDetector stuff even if not a PeakDetectionFilter
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+2/-0/±3] https://git.io/JUPoS
<_whitenotifier-f>
[scopehal] azonenberg f39cd4e - Tek 5/6 spectrum view channels now display peaks. Hard coded to 10 peaks at 1 MHz minimum spacing for now. See #269.
<_whitenotifier-f>
[scopehal] azonenberg edited issue #269: Support for Tek 5/6 series spectrum channels - https://git.io/JUaaE
<azonenberg>
lain, monochroma, miek: So at this point i have most of the stuff need to view spectrum channels working
<azonenberg>
But I don't have APIs for changing things like RBW, center frequency, span, etc
<azonenberg>
The question is how we should fit that into the overall instrument object model
<azonenberg>
In particular, how reasonable is it for a specan to be derived from Oscilloscope?
<azonenberg>
Or in general how do we want to handle the case of things that are simultaneously specans and scopes?
<azonenberg>
Conceptually, a spectrum analyzer is (to me) an oscilloscope where the X axis has units of frequency rather than time
<azonenberg>
or more precisely an oscilloscope where at least one channel's X axis
<azonenberg>
Note also that a RTSA may have the ability to give you time domain baseband I/Q data
<azonenberg>
So the line between specans and scopes is not at all sharp
<azonenberg>
also poke noopwafel, tnt, kc8apf)
<kc8apf>
that's not entirely wrong. I'd need to think through how RBW effects on data map to something similar in an oscope.
<azonenberg>
Well there would have to be new APIs for setting center frequency, span, and RBW
<azonenberg>
The question is should we add these to the oscilloscope class or make a new one?
<azonenberg>
there's no clear answer here
<azonenberg>
No matter what, if we have a combined device like a tek 6 series, there will be cases where calling some APIs on some channels make no sense
<kc8apf>
hadn't seen LeoNTP. Looks nice for the price. I want something with multiple outputs though. I want PPS, 10MHz, and adjustable output
<azonenberg>
(internally I treat CH1 and CH1_SPECTRUM as totally separate channels, because other than sharing a frontend they have basically nothing in common)
<azonenberg>
kc8apf: so in my case what I want is NTP, PPS, and 10 MHz with as few unique instruments as possible and without paying a fortune
<azonenberg>
I think a LeoNTP for NTP+PPS and his GPSDO for 10 MHz is probably the best combination right now
<kc8apf>
is the oscilloscope class intended to represent an actual oscilloscope or a more generalized display with X-Y charting?
<azonenberg>
And that's the million dollar question :)
<azonenberg>
What makes the most sense at an API level? Keeping in mind again that the lines between different types of instruments are not at all clear
<kc8apf>
there are plenty of other devices that tend to use X-Y charting output
<azonenberg>
Consider that some modern multimeters can have kHz to MHz sample rates, for example - it might make sense to have THEM represented as oscilloscopes too
<azonenberg>
what if you want to do ffts and math functions on a fast DMM output?
<azonenberg>
ultimately i think it is, no pun intended, a spectrum
<azonenberg>
And a unified representation might make the most sense
<kc8apf>
I expect trying to name things after physical equipment will always cause problems. Separating the concept of visualization from acquisition and analysis leads to much more generic naming
<azonenberg>
The class will remain named Oscilloscope since that's what it mostly is used for
<kc8apf>
what makes it an oscilloscope versus anything else?
<azonenberg>
I'm thinking more at an API level. it doesn't matter what you call the class
<azonenberg>
does it make sense for scopes and specans to be unified?
<azonenberg>
Because i am seeing some convergent evolution happening here. Ultimately scopes, LAs, and specans are "things that take in a bunch of electrical data at high speed and plot it"
<azonenberg>
A LA is conceptually a DSO that has 1-bit resolution, using comparators instead of ADCs for sampling
<azonenberg>
A sampling scope isn't realtime but outputs either a time domain waveform or an eye pattern
<azonenberg>
a specan can output either time domain I/Q or a frequency domain "waveform"
<azonenberg>
I don't think there are any lines to draw that make sense
<kc8apf>
At the API level, is this class what handles rendering of data or something more?
<azonenberg>
No. Rendering is done by the WaveformArea class
<azonenberg>
in glscopeclient
<azonenberg>
libscopehal has no rendering at all, the Oscilloscope class is purely for acquisition
<azonenberg>
New probe board came in
<azonenberg>
probably going to populate and test over lunch
<kc8apf>
For acquisition, I'd probably focus on classes that implement one channel. In that case, I'd have a Oscilloscope, LA, Spectrum Analyzer, etc classes.
<kc8apf>
mostly due to the large amount of commonality in implementing specific implementations of each of those but also the moderate amount of non-overlap between them
<azonenberg>
kc8apf: That doesn't make sense because of things like timbase and trigger config
<azonenberg>
more importantly, the Oscilloscope-derived class is normally where the driver code that interfaces to the specific instrment is
<azonenberg>
I don't want to have device-specific code in more than one class
<kc8apf>
MSOs already start to break that model
<azonenberg>
So LeCroyOscilloscope is the bridge from the Oscilloscope class API to the LeCroy SCPI protocol, etc
<azonenberg>
As far as i'm concerned a MSO is just a DSO where some channels have lower bit depth than others
<azonenberg>
and controls like gain/offset are no-ops
<azonenberg>
and that's why i'm thinking adding frequency domain stuff to it isn't much of a stretch
<azonenberg>
Each Channel has a Waveform object associated with it, and can have arbitrary X/Y units
<azonenberg>
So having a Channel that has X=freq, Y=amplitude units is completely reasonable
<azonenberg>
Since a Filter is a Channel that's not attached to an instrument, in fact, FFT's are already represented this way
<azonenberg>
so the only difference is that now there can be frequency domain Channel's that are part of an instrument
<azonenberg>
i have this now for the mso5/6, and it works. I just have to add commands for center/span and RBW i think
<kc8apf>
sounds like you know what you want to do
<electronic_eel>
are there kinds of instruments that aren't derived from this oscilloscope class?
<azonenberg>
electronic_eel: so far power supplies and waveform generators
<electronic_eel>
so why not call it acquisition_instrument instead of oscilloscope?
<azonenberg>
however some may derive from both, like a scope with an integrated AWG. But these are fundamentally separate instruments in the same body
<azonenberg>
oh and also (for now) multimeters
<azonenberg>
VNAs are likely going to be different too because they have basically nothing in common with the others
<electronic_eel>
why are multimeters different than scopes?
<azonenberg>
That's why i said "for now"
<electronic_eel>
don't they also deliver a datastream of inputs?
<azonenberg>
Because i am thinking of unifying them
<azonenberg>
Renaming the class is a decision for later
<azonenberg>
For the time being the question is whether unifying SAs and scopes under one roof makes sense. ANd i think it does
<azonenberg>
and yes actually there has been discussion with some of the xdevs folks about adding support for multimeters under the same framework
<azonenberg>
the theory being that a multimeter is just a scope optimized for resolution rather than sample rate
<azonenberg>
and with the various biasing etc circuits you need to measure current
<azonenberg>
to measure resistance*
<electronic_eel>
yeah, but does that matter much for grabbing and interpreting the data?
<azonenberg>
well what matters more is how the acqusition model works
<miek>
seems like the major distinction is the unit of data returned by the instrument. you've got scopes/specans/etc. that return a waveform, DMMs that usually give you a single value per query, SDRs/LAs that just give you a constant stream of data
<azonenberg>
miek: that is kinda how i've been thinking of it too
<azonenberg>
e.g. i think right now my R&S meters expect you to read points one at a time and we don't currently have support for roll triggers
<azonenberg>
But even these lines are a bit blurry because some meters can return blocks of many samples
<azonenberg>
which really doesn't seem any different from a waveform
<electronic_eel>
don't better multimeters also have a buffer the sample into that you can read out later?
<azonenberg>
Yes
<azonenberg>
Which is why i'm saying those are basically just scopes with really high res ADCs and slow timebases
<electronic_eel>
that looks very similar to a scope to me
<azonenberg>
Exactly
<azonenberg>
The xdevs guys were talking about wanting to do sub-Hz frequency FFTs on DMM waveforms
<azonenberg>
i think one of them said he had a DMM that had high kHz or even low MHz ADC rates
<azonenberg>
That is really just a slow scope
<electronic_eel>
your fft algorithm doesn't care about the scale on the frequencies, doesn't it?
<azonenberg>
Not... exactly
<azonenberg>
the FFT itself does not
<azonenberg>
however the X axis units for a Waveform are int64's
<azonenberg>
and right now the base unit is Hz, so we cannot represent fractional Hz resolution in a frequency domain waveform
<azonenberg>
I have a ticket open for changing the base unit to mHz or uHz to fix this
<azonenberg>
Just a constant scaling factor we'll have to change in a few places (the tek MSO driver and the FFT class)
<electronic_eel>
ah, that should be fixed for low-freq ffts. also maybe for function generators that usually are also able to do sub-hz stuff
<azonenberg>
Yeah. Right now the base units are ps for time and Hz for freq
<azonenberg>
most other units like dBm and volts are only really used for the Y axis at the moment and the Y axis for analog waveforms is 32-bit IEEE754 float
<azonenberg>
so the choice of base unit doesn't matter much. But X axis units are fixed point because the data is discretely sampled at fixed intervals and you really want integer indexes you can iterate over
<electronic_eel>
yes, having the x axis also in float would make it much slower
<azonenberg>
We may have to revisit some of these design choices when we add X-Y plots though
<azonenberg>
plotting volts against volts
<azonenberg>
That architectural decision is the biggest blocker to proper x-y
<azonenberg>
But that is not a super high priority right now
<azonenberg>
Re changing the base unit to sub Hz, low frequency FFTs is the driving use case. But it will help with func gens for sure too
<azonenberg>
in fact, i think my R&S PSUs can do really low freq AWG modulation
<azonenberg>
for simulating weird ramp curves etc
<azonenberg>
probably only a few hundred Hz given bypass capacitance etc
<azonenberg>
But that is a feature the scopehal driver does not yet support
<electronic_eel>
so you plan to have multimeters, power supplys, function generators and so on in glscopeclient - how about an interface to easily script test scenarios without having to recompile the whole thing?
<electronic_eel>
as a replacement to the overpriced SMUs?
<azonenberg>
That would be a nice long term function. Right now you have to write such stuff in C++
<azonenberg>
in the examples directory there's a trivial curve tracer based on my R&S DMM and PSU
<azonenberg>
sweep psu in 1 mV increments and measure current with the DMM to get higher resolution than the PSU
<azonenberg>
then stop when you hit i think 20 mA or 5V
<electronic_eel>
yes, exactly this kind of stuff
<azonenberg>
Eventually either python bindings or a custom domain specific scripting feature, or both, would be nice
<electronic_eel>
finally kill off labview
<azonenberg>
also to be clear that will be in libscopehal
<azonenberg>
glscopeclient, at least for the near term, is intended to only be used for instrments that output waveforms
<azonenberg>
there will be separate UIs under scopehal-apps for things like PSUs
<azonenberg>
i think there is already an incomplete psuclient app
<azonenberg>
just a GTK dialog basically
<electronic_eel>
hmm, why not integrate it into glscopeclient?
<electronic_eel>
to get stuff like xy plots
<azonenberg>
i have very basic Cairo based plotting, actually, already
<azonenberg>
in psuclient
<azonenberg>
But it would be interesting to have it integrated. I havent made a final decision yet. psuclient is pretty trivial right now and could be easily replaced
<azonenberg>
My ultimate goal is for libscopehal to kill VISA though
<electronic_eel>
yes, kill VISA and kill labview
<azonenberg>
well as i see it libscopehal is the VISA killer and scopehal-apps is the labview killer
<electronic_eel>
then scopehal-apps or glscopeclient also needs a scripting interface, not only libscopehal
<electronic_eel>
because you want to control the graphical output to replace labview
<azonenberg>
Hmm, yeah
<azonenberg>
We'll have to think about that long term. There's a lot more basic infrastructure to work on first
<electronic_eel>
yes, of course
<azonenberg>
BTW, what is your current status wrt using glscopeclient? you said you got it compiling and running?
<electronic_eel>
no, I'm finishing a pcb project of mine first. will get glscopehal to work when that is finished
<azonenberg>
also longer term we might want a better name for glscopeclient. It's a very descriptive name that might be better off replaced with something more memorable :p
<azonenberg>
it sounds like a unix utility lol
<azonenberg>
Which isn't entirely untrue
<electronic_eel>
glscopeclient | grep fft
<azonenberg>
lol
<azonenberg>
V1.2 probe is cooling after reflow now
<azonenberg>
gotta hand solder the connector and then i can test :D
bvernoux has joined #scopehal
<azonenberg>
bvernoux: perfect timing
<azonenberg>
just finishing up soldering the v1.2 probe
<azonenberg>
throwing it on the VNA momentarily
<bvernoux>
ha nice
<bvernoux>
it is like I have read your mind ;)
<bvernoux>
I was checking the VNA2 ;)
<bvernoux>
the guy has really done amazing job
<bvernoux>
the Qt GUI is very nice
juli965 has joined #scopehal
<azonenberg>
Soldering complete, on to test
<bvernoux>
great
<bvernoux>
do you have soldered the new connector for RF up to 26.5GHz ?
<bvernoux>
similar to the one I'm using ?
<bvernoux>
SMA
<bvernoux>
as it clearly heavily improve transition from SMA to PCB
<azonenberg>
they don't get below about 250 ohms input impedance
<bvernoux>
I told you ;)
<azonenberg>
while at the same 2 GHz point i'm around 10 ohms
<azonenberg>
So basically at this point i have better S21 and they have better S11
<bvernoux>
pico is good up to 3.5GHz ...
<azonenberg>
So what i'm wondering is where is my big 2 GHz resonance coming in, and how can i get rid of it?
<bvernoux>
maybe with rf absorber
<bvernoux>
it is with the case ?
<azonenberg>
no this is uncased
<azonenberg>
Possibly related, when i simulate the simplified netlist model i get a ~3 GHz resonance that drops the input impedance down to about 100 ohms
<azonenberg>
Which makes me think it's the tip needle itself
<bvernoux>
you are not using same tip as Pico probe ?
<azonenberg>
No i'm using a PMK tip. but i meant more like the whole assembly of tip to input
<azonenberg>
maybe i need some kind of compensation or something, idk
<miek>
that's what i'd suspect, all the other probes i see go to great effort to put a resistor as close to the tip point as possible to put a hard limit on impedance
<azonenberg>
miek: I have a resistor as close to the tip as i can
<azonenberg>
i think this resonance is before that
<azonenberg>
i think it's the tip itself
<miek>
yeah, but it's still far away relative to a lot of other probes
<bvernoux>
limited by the tip protection maybe too
<bvernoux>
but here the resistor is inside tip IIRC
<bvernoux>
but maybe you could add a material around the tip
<azonenberg>
Anyway, i think i can actually do better
<azonenberg>
gimme a sec, i want to see what happens if i add the ground closer to the tip
<bvernoux>
IIRC your tip is "nude" ;)
<bvernoux>
and quite long
<electronic_eel>
bvernoux: do you think the plastic (?) around the tip is what solves the problem for yokogawa?
<bvernoux>
it is maybe not simple plastic ;)
<bvernoux>
I just search idea to check ;)
<bvernoux>
as anyway with actual tip it is impossible to add resistor on the tip ...
<bvernoux>
and it is quite long so it has an effect
<azonenberg>
anyway, also interesting: the resistive damping idea also nulls out the peaking
<bvernoux>
do you have a measurement and photo to see it ?
<azonenberg>
I'm still playing in sim
<azonenberg>
buit
<electronic_eel>
bvernoux: yes, it could be something more sophisticated. but it is not some simple shielding either, otherwise there would be resonance
<bvernoux>
ha ok it is in sim
<bvernoux>
electronic_eel, yes shielding will add more issues ;)
<bvernoux>
I think to something like rf absorber
<bvernoux>
to be checked what the effect is
<bvernoux>
as it does miracle in aluminum cavity ;)
<bvernoux>
but it is not exactly the same use case here
<electronic_eel>
what is also different is that their ground is really far away, so there is no danger of resonance there
<azonenberg>
red = v1.1 board, pink = v1.2 board, blue = v1.1 plus damping resistor
<bvernoux>
yes it is strange it is so bad after 4GHz
<azonenberg>
Well more to the point, the damped version has those weird oscillations in it
<azonenberg>
But it's also higher amplitude in general than the version iwth the filter
<azonenberg>
up to 4 GHz at least, which is about what i am targeting as my upper bandwidth
<azonenberg>
it almost hits 5, not quite, so maybe 4.5 or so will be the official spec
<azonenberg>
You know what, though? even though this probe with the damping resistors isnt perfect, it does have lower loading than the version with the fitler
<bvernoux>
yes with weird oscillations which are strange of course
<azonenberg>
And it outperforms my 1.5 GHz active probe after about 250 MHz
<Degi>
Lol
<azonenberg>
But the pico still wins. I guess that's not surprising as it's a 20x probe not a 10x
<bvernoux>
its fun but we see the curve of Pico is very similar to the v1p1 damped
<bvernoux>
but with amplitude of oscillation very attenuated
<bvernoux>
if you try 1K res you will match Pico ;)
<azonenberg>
Perhaps
<azonenberg>
So this graph here... blue is the damped probe which is think is the best so far. The bandwidth is a little less than the one with the big tip resonance, but i need a probe that doesn't load my DUT into oblivion