<_whitenotifier-3>
[stm32-cpp] azonenberg dc8ecd5 - Make asm helpers explicitly define exported symbols as functions to make linker happy when calling from veneers
<d1b2>
<aleksorsist> Heyy, the frontend goes up to 800MHz, it's the sample rate that's the limit 😅
<d1b2>
<azonenberg> Well yeah but that forces us to limit analog BW to avoid aliasing
<d1b2>
<azonenberg> Point is, in today's thunderscope the ADC is the limiting factor
<d1b2>
<david.rysk> can the ADC do faster if in single channel mode?
<d1b2>
<david.rysk> I can't recall
<d1b2>
<azonenberg> @david.rysk yes it does (in 8 bit) 1 Gsps total sample rate
<d1b2>
<azonenberg> split across 1/2/4 channels
<d1b2>
<azonenberg> but 1 Gsps is still slow by modern standards
Darius has quit [Quit: Bye]
Darius has joined #scopehal
<d1b2>
<azonenberg> The same AFE and PC interface bolted onto a faster ADC would be extremely competitive with the picoscope
<d1b2>
<azonenberg> aha. yeah the automatic phase and frequency detection is based on zero crossings
<d1b2>
<azonenberg> if the signal is a little noisy, it can be hard to get great results
<d1b2>
<azonenberg> the "manual" mode exists for precisely this reason
<d1b2>
<azonenberg> (i think this isn't currently doucmented, i've been going through filters writing docs alphabetically and phase is quite far down)
<d1b2>
<azonenberg> this is what i did as well, you dont want the scope timebase locked to either of the inputs for this kind of measurement
<d1b2>
<azonenberg> that looks like a bit of noise in the phase measurement where it wraps around
<d1b2>
<aleksorsist> Can always go above Nyquist for some SDR tasks 🙂 but yah, ADC is the limit but thankfully that's not the hard part to change for the next one
<d1b2>
<aleksorsist> Already is, hmcad1520 is what's in the picoscope 5000, msrp $>3k
<d1b2>
<aleksorsist> As for the 6000, that's the next goal 🙂
<d1b2>
<246tnt> @azonenberg Look at the phase difference trace ( Subtract_1 ) on the very right of the trace. Some weirdness at the end which is unexpplained because the two phase plots are clean there ...
<d1b2>
<azonenberg> yeah sorry should have clarified i meant competitive with the 6000
<d1b2>
<azonenberg> And yeah, nothing against the current thunderscope design, it's quite good for what it is
<d1b2>
<azonenberg> I'm just daydreaming of a thunderscope backend paired with the frontend from my lecroys :p
<d1b2>
<aleksorsist> As am I 😁 but it's easier to work up to that, so one step at a time for me at least
bvernoux has quit [Quit: Leaving]
<d1b2>
<azonenberg> Yeah of course lol
<d1b2>
<246tnt> Huh ? Looking at your video I don't see any Subtract blocks. Here I'm not comparing two GPSDO, just looking at a single one, vs the Rb .
Bird|ghosted has quit [Ping timeout: 255 seconds]
<d1b2>
<azonenberg> what i meant is i'm not locking the scope timebase to the rb
<d1b2>
<azonenberg> i'm triggering off it
<d1b2>
<azonenberg> essentially what you're measuring is the beat frequency between the rubidium and the gpsdo
<d1b2>
<azonenberg> also, the rubidium may not be exactly 10.000000 MHz if it's not perfectly trimmed, mine was a few ppb off from the GPSDOs
<d1b2>
<azonenberg> what i was using it for was a stability referenec
<d1b2>
<azonenberg> i.e. a constant frequency offset from gps to rb is expected
<d1b2>
<azonenberg> changes in the frequency offset were the interesting bit
<d1b2>
<246tnt> @azonenberg But what I'm not explaining is that despite me triggering from Chan 1 too (the Rb), the "Phase filter" applied to Chan 1 wasn't a constant, it was also drifting.
<d1b2>
<246tnt> (hence why I had to use a Subtract block)