<azonenberg>
Found an AWG at work hiding on a shelf that had been completely forgotten
<azonenberg>
turns out it can generate QPSK
<azonenberg>
So i grabbed a recording of a PRBS off it
<azonenberg>
This will be an excuse for me to implement two different things i've wanted to do for a while
<azonenberg>
constellation diagrams, and a filter that displays the relative phase of a signal
<azonenberg>
i.e. you create a LO that is frequency matched to the signal
<azonenberg>
then display the difference in phase between the LO and the incident signal
<azonenberg>
so a solid tone at any phase will be a straight line, and PSK will look like PAM
someone--else has joined #scopehal
someone--else has quit [Quit: Connection closed]
someone--else has joined #scopehal
someone--else has quit [Quit: Connection closed]
<Degi>
I tried to update scopehal and get /home/user/git/scopehal-apps/src/glscopeclient/OscilloscopeWindow.cpp:957:20: error: ‘class MockOscilloscope’ has no member named ‘LoadComplexUnknownFormat’
<Degi>
Oh, does git pull need recurse submodules too, even when I already have it...
<azonenberg>
That i dont know
<azonenberg>
but the CI builds pass
<azonenberg>
so it's likely a local issue
<Degi>
Hm yes pull needs that again.
<azonenberg>
there is a git config setting to make it always recurse
<Degi>
thx
<Degi>
Hm yes, last scopes menu, very nice
<azonenberg>
Yeah there's been a lot of little UI tweaks lately :)
<Degi>
Also somehow when no waveform is shown I can only zoom the timeline in
<azonenberg>
that's... not exactly a bug so much as a side effect of a recent change
<Degi>
I mean its Ok
<azonenberg>
The renderer gets really slow if you have a bazillion samples on a few pixels
<azonenberg>
so i cap zoom-out now
<Degi>
oh
<azonenberg>
you can't zoom out further than the total width of the waveform
<azonenberg>
because there's no point, there's nothing more to see
<Degi>
Hm yes that makes sense
<azonenberg>
So when there's no waveform i guess it just wont let you zoom out at all lol
<Degi>
Meh, the 0.15 WFM/s of glscopeclient is close to the 0.13 WFM/s of my python example (at 10 MPoints)
<azonenberg>
Not surprising
<Degi>
At 10 kS my code gets 0.83, glscopeclient 1.04, peaking at sometimes 2, but average like 1.1, meh
<Degi>
I mean its kinda usable
<azonenberg>
Yeah, there's not much i can do unless rigol makes their firmware faster
<Degi>
How can I remove channels?
<azonenberg>
Right click, delete or hide - i forget what the menu item says
<Degi>
Right, I managed to right click into the wrong place
<Degi>
Somehow the scope seems to take a bit between pressing trigger and actually acquiring the waveform
<Degi>
By using another trigger mode (instead of STOP SING I use RUN, check for TRIG:STAT? = TD and then STOP and then read
<azonenberg>
if you do that, you risk multiple triggers and otherwise desyncing
someone--else has joined #scopehal
<Degi>
Hm, multiple triggers? (I mean yes it triggers often when its running but as long as all traces are from one trigger...)
<azonenberg>
normally if you trigger you want to get the next trigger event though
<azonenberg>
i dont want it to miss stuff after i arm it
<Degi>
Hm yes
<Degi>
My python script measures about 240-320 Mb/s to the scope for the data transfer itself
<azonenberg>
Yeah the transfer is fast, the bottleneck is inside the scope getting ready to do the transfer iirc
<Degi>
Yes, there is a large pause
<azonenberg>
there is a huge delay from the trigger event until data starts being sent
<Degi>
Which only gives 44 Mb/s
<Degi>
Heck, that fits over my internet downlink
<Degi>
Yes, 7.5 seconds between :WAV:DATA? having been sent and start of data transfer (where it gets the #), about 1.2-1.4 s for 50 MPoints data transfer
<azonenberg>
:o
<azonenberg>
7.5 seconds
<azonenberg>
that's... pretty bad
<azonenberg>
i hope this new firmware helps
<Degi>
Well, its 50 mpts
<azonenberg>
yeah but with say a lecroy, you get the trigger notification almost instantly no matter how deep the trigger is
<azonenberg>
and you're mostly limited by transfer performance
<Degi>
With 10 kpts its only 65 ms but maybe it fits in the buffer of the internet chip
<azonenberg>
vs the huge O(1) overhead
<Degi>
Hm neat
<azonenberg>
i think it's more likely that there is a slow bus between the fpga and cpu
<Degi>
Can you get the trigger notification before the buffer is filled?
<Degi>
Yeah
<azonenberg>
Not to my knowledge
<azonenberg>
but lecroy stuff has the capture fpga attached over pcie
<azonenberg>
and in most scopes has dedicated custom built memory paired with the adcs
<azonenberg>
at least in the higher end stuff
<Degi>
At 1 Mpts 0.16 s between :WAV:DATA? and 0.015 s for transfer
<azonenberg>
the adcs stream direct to ram
<azonenberg>
and both the memory and adc are lecroy asics
<Degi>
Huh, even the memory? neat
<azonenberg>
I think most other scope vendors use COTS DDRx memory
<azonenberg>
Yeah
<azonenberg>
At least on the high end
<azonenberg>
the lower end is probably stock ddr and fpgas
<Degi>
Huh, getting peak rates of up to 650 Mb/s, though that may be somehow distorted. The average data rate is still roughly the same 50 Mbps
<Degi>
Hmm, 50 Mbps... What kinda bus could that be?
<Degi>
QSPI clocked at 12.5 MHz?
<azonenberg>
plausible. or x1 spi at 50 Mbps
<azonenberg>
could be lots of things
<azonenberg>
could be software limited too
<azonenberg>
just some unoptimized loop doing a byte at a time
<Degi>
I hope it is... bvernoux said something they have to really think how to optimize it or so, that thats why its being shifted to next month
<Degi>
lol yeah
<azonenberg>
oook so
<azonenberg>
Say I want to compare the instantaneous phase of two waveforms
<azonenberg>
One is a pure sine LO, the other is mostly sinusoidal but might have phase shifts, not be quite the same frequency as the LO, etc
<azonenberg>
If I measure the amplitude of the incident signal, I can map each voltage back to one of two possible phases
<azonenberg>
then if i check the slope of the signal i can disambiguate. right?
<Degi>
incident signal? As in LO = sin(wt) and the other signal = sin((w+err)t+phi) and the indicent signal is then sin((w+err)t+phi)-sin(LO)?
<azonenberg>
the input i mean
<azonenberg>
I'm trying to create a filter that displays relative phase of an input over time
<azonenberg>
so a pure tone will show up as a straight line
<azonenberg>
BPSK will look like a NRZ signal
<azonenberg>
QPSK will look like PAM4
<Degi>
Hm, like arcsin(input - LO)?
<azonenberg>
etc
<azonenberg>
more like arcsin(input) - arcsin(LO)
<azonenberg>
but thats the basic idea yes
<Degi>
Right
<Degi>
Yes, if you have the relative phase and a constant offset frequency, then they should slope a bit but still jump around when the phase changes
<azonenberg>
well i'm going to calculate the LO freq as the average freq of th einput
<Degi>
But it could be that phi and phi + 180 etc. are swapped
<azonenberg>
so it should be fairly close
<Degi>
Ah
<azonenberg>
but there will be drifts
<azonenberg>
And of course there is always ambiguity in phasing as far as which phase you call 0 vs 180 etc
<Degi>
If its low order PSK, then it should be possible to straighten it out
<azonenberg>
without protocol specific info about pilot tones or something, you wont know
<azonenberg>
I'm starting with just displaying the phase with no alignment
<azonenberg>
but this is kinda buildup for building constellation displays
<azonenberg>
i'm testing with a QPSK waveform at i think 500 Kbaud modulated on a 100 MHz carrier
<Degi>
I think what would be good to align would be that any change with a dx/dt smaller than a certain value is negated and only larger changes make it through, that it actually looks like PAM with no drift
<azonenberg>
Yes, i'm going to build a constellation rotator filter or something that will try to correct for drift
<azonenberg>
But i think that will be a separate block from this filter
<azonenberg>
i will also need something for doing clock recovery on a quadrature modulated signal
<Degi>
Maybe just taking one sine period and using that as a basis?
<azonenberg>
One thing at a time :) first step is the phase display filter
<azonenberg>
also something seems to ahve broken recently re loading waveforms from disk, hmmm
<azonenberg>
it displays stuff but then it disappears, you have to clikc anything in the history view to fix it
<Degi>
Argh, Scope says I have the options but :syst:opt:stat says something else. Well, guess time for a workaround.
<Degi>
I got a rigol fix for BW and memory depth soon
<azonenberg>
You'll want to call Trim() to get rid of any trailing whitespace
<Degi>
Like ReadReply()->Trim()?
<azonenberg>
Trim(ReadReply())
<Degi>
Thanks, though now it segfaults. Recompiling with debug, since gdb doesnt seem particularly helpful
<azonenberg>
Good luck. I'm chasing bugs of my own
<_whitenotifier-a>
[scopehal] azonenberg pushed 1 commit to master [+2/-0/±3] https://git.io/Jcvi4
<_whitenotifier-a>
[scopehal] azonenberg 701309f - Initial implementation of PhaseMeasurement
<Degi>
Ah, apparently it just didn't like 50 MPoints.
<Degi>
GetChannelBandwidthLimiters should return a list of available limits?
<Degi>
Hm yes probably
someone--else has quit [Quit: Connection closed]
<azonenberg>
Yes
<Degi>
Is it okay when I set the memory depth to 1 Mpoints during initialization?
<azonenberg>
I generally leave depth and rate at whatever the scope is configured for
<Degi>
Hm, but I need to change it to figure something out, after that I would need to convert a float to something like "100k" to set it to what it was before, because for some reason :ACQ:MDEP? returns a floating point number
<Degi>
I wonder who thought that that could possibly be a good idea...
<Degi>
Somehow the acquisition has a weird bug where channels get swapped around, happening seemingly every 4096 samples for a bit, no idea why that is