<azonenberg>
I also just did some new measurements to try and characterize the impacts of probe loading on signal quality. The kickstarter probe rev is the worst
<azonenberg>
(measured in terms of S21 with probe present vs not present, 50 ohm terminator across probe, VNA across a thru line)
<azonenberg>
the damped and undamped probe are actually pretty close
<azonenberg>
it's better at some freqs and worse at others
<azonenberg>
particularly intersting, the tip ground seems to make loading worse
<azonenberg>
with the leaf ground, lkoading is much less
<azonenberg>
and actually less than the pico probe at times
<azonenberg>
This is with the v1.2 probe (no damping resistors, just the filter)
<azonenberg>
I definitely want to try making an active diff probe at some point. This kind of signal is tricky to measure passively
loxodes has joined #scopehal
<azonenberg>
Bird|otherbox: soooo crazy idea
<azonenberg>
what if (on Linux)
<azonenberg>
we had the beginning of main() check the env var
<azonenberg>
if not set right, set it
<azonenberg>
then exec $argv
<azonenberg>
(the second exec is needed because libgomp reads the env var before main, so by the time we check it's too late)
monochroma has quit [Ping timeout: 246 seconds]
laintoo has quit [Ping timeout: 264 seconds]
electronic_eel_ is now known as electronic_eel
juli965 has joined #scopehal
<Degi>
De-embedding seems to make it worse...
<Degi>
Also whats up with the thin vertical line in the middle of the eye diagram
<Degi>
I wonder if you can do PCIe over SFF80087
<Degi>
Do we have 8087 or 8088?
Nero_ has joined #scopehal
<electronic_eel>
Degi: the probe pods for maxwell are SFF 8087, because 8088 does not have the sideband channels
<Degi>
Huh interesting
<Degi>
SFF8087 is usually used internally, right?
<electronic_eel>
yes, to connect from mainboard/sas-controller to the backplate of the drive cages
monochroma has joined #scopehal
<electronic_eel>
but I have also seen 8088 used internally
<electronic_eel>
basically every vendor does it's own mix and match there
laintoo has joined #scopehal
<Degi>
Ah, so the sideband is the 2.54 mm connector on the cable I have laying around here...
<Degi>
I wonder if it is possible to do PCIe over 4 wires xD (I mean theoretically it could work without ground)
<electronic_eel>
I guess you could use SFF 8087 / 8088 for PCIe up to 2.0, but I don't think it is common
<electronic_eel>
you see a lot of chinese vendors doing PCIe over usb 3 cables though
<electronic_eel>
so if it is just something for yourself or lab use (where confusing it with actual usb isn't that much of an issue), I'd go the usb cable route, because of lot's of cheap adapters available
<electronic_eel>
Bird|otherbox: btw, do you know what the gomp maintainers say about this issue? are they aware of the problem and what solution do they propose?
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUMeW
<_whitenotifier-f>
[scopehal] azonenberg 4a90b67 - TektronixOscilloscope: implemented gain/offset controls for frequency domain channels. See #269.
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #201: RBW display for Tek MSO5/6 FFT channels is wrong - https://git.io/JUMeB
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #201: RBW display for Tek MSO5/6 FFT channels is wrong - https://git.io/JUMeB
<_whitenotifier-f>
[scopehal-apps] azonenberg edited issue #201: RBW display for Tek MSO5/6 spectrum channels is wrong - https://git.io/JUMeB
<azonenberg>
ok so at this point i think the only thing i need for full spectrum channel support is APIs for center freq and bandwidth, and UI to call them
<azonenberg>
also i just did another interesting loading test of my probe vs a LeCroy ZS1500 (1.5 GHz active voltage probe)
<azonenberg>
Rise time (20-80 / 10-90) of the test signal untouched was 80/117 ps
<azonenberg>
With a ZS1500 and leaf ground the DUT risetime degraded to 99/179 ps and the waveform seen by the scope through the probe was completely sinusoidal, rise and fall just merged together
<azonenberg>
With the same tip and ground on my probe, DUT risetime was 89/132 ps (barely noticeable), and the waveform seen through the probe was 162/230 ps
<azonenberg>
Using the tip mounted ground instead of the leaf, the DUT was more heavily loaded (101/153 ps, so slightly better than the active probe but not by much)
<azonenberg>
but the edge seen through the probe improved to 107/201
<azonenberg>
Visually, the DUT-side eye at 1.25 Gbps is basically unaffected with my probe
<azonenberg>
The kickstarter probe, by comaprision, loaded the DUT risetime to a whopping 196/286 ps
<azonenberg>
and risetime through the probe was 136/204
<azonenberg>
So objectively a lot worse
elms has quit [Ping timeout: 240 seconds]
sorear has quit [Ping timeout: 258 seconds]
futarisIRCcloud has quit [Ping timeout: 260 seconds]
kc8apf has quit [Ping timeout: 260 seconds]
LeoBodnar has quit [Ping timeout: 260 seconds]
lukego has quit [Ping timeout: 260 seconds]
wbraun has quit [Ping timeout: 272 seconds]
bvernoux has joined #scopehal
<bvernoux>
hello
<bvernoux>
azonenberg, so you have found an issue in measurement on probe v1.2 ?
<bvernoux>
I saw that in Twitter
<azonenberg>
bvernoux: i'm seeing input impedances that vary by like an OOM depending on which fixture method i measure with
<azonenberg>
So i dont know which to trust at the moment
<bvernoux>
yes I was also suspecting something like that especially if you are not doing exactly same test on both probe
<bvernoux>
to compare them
<bvernoux>
to compare apple with apple ;)
<azonenberg>
given that the grounds arent the same distance apart i cant do exactly identical tests
<azonenberg>
anyway, testing my probe using a similar method to the pico one shows a minimum impedance of around 100 ohms
<bvernoux>
it is why I asked photo of setup to check that too
<azonenberg>
which isnt great but isnt awful either. certainly not 10 ohms
<azonenberg>
But i'm also doing testing to measure real world loading on an actual DUT
<azonenberg>
seeing how much eye closure i get
<azonenberg>
the answer is, not much
<bvernoux>
yes it is a good test
<bvernoux>
I shall finish my TRL ;)
<bvernoux>
it could help to do such measurement with fully calibrated/characterized traces ...
<bvernoux>
I would like to find a paper to correctly characterize Oscilloscope Probe with a VNA ;)
<bvernoux>
as there is some tricks
<bvernoux>
especially for such probe which reach 5GHz BW
<azonenberg>
Yellow/light pink = saved traces with no probe loading
<azonenberg>
pink = with probe loading
<azonenberg>
green = through probe
<azonenberg>
https://www.antikernel.net/temp/LeCroy--00051.png this is a Pico TA061, the low-end transmission line probe. Lots of loading, not great frequency response, and huge overshoot from ~1 GHz peaking
<azonenberg>
https://www.antikernel.net/temp/LeCroy--00054.png Pico 921, the good transmission line probe. Better loading characteristics than mine but i'm not actually thrilled about the shape of the waveforms through it
<azonenberg>
https://www.antikernel.net/temp/LeCroy--00055.png Same as the previous plot, but with scope gain turned up one more tick. It seems like at the highest gain my frontend performance craps out
<azonenberg>
the waveform suddenly starts looking sinusoidal and not sharp
<azonenberg>
So my conclusion at this point is that my probe is undoubtedly better (for fast signals) than the lecroy active probe or any of the cheap passive probes
<bvernoux>
I do not imagine the price of that scope ;)
<bvernoux>
ha no it is bad only 5GS/s ;)
<azonenberg>
Degi: So the issue is, transports and drivers are separate
<azonenberg>
the "lan" driver just moves SCPI over a TCP socket
<azonenberg>
it defaults to 5025 which is the IANA registered port
<Degi>
Ah
<Degi>
Hmm now glscopeclient gets stuck at the connect menu lol
<azonenberg>
Rigol uses... 5555 i think, and Tek uses 4000. These have to be specified manually because there's no way for the transport to know what the instrument is using
<Degi>
The scope kinda gets stuck at stop, now the window shows up but it doesnt get reset to SING
<azonenberg>
well, start debugging :p
<Degi>
Oh welp it hung my desktop session due to mem leak or so
<Degi>
Where does it show the framerate? Is that a new feature?
<Degi>
Getting approx 1 FPS right now
<Degi>
Hm, when I right click in the GUI it hangs up. I think I should update
<Degi>
Wait I was still on scopehal-cmake
<azonenberg>
oh lol you're probably months out of date then
<Degi>
Maybe we can have a python / bash script to build it...
<Degi>
Hmh, why does this recurse submodules want my SSH keys when it doesnt use them for anything...
<azonenberg>
Degi: it's probably trying to clone the submodules via ssh
<Degi>
Can I somehow specify https?
<azonenberg>
No. The reason being, github i think only accepts pushes via ssh and the repo is currently optimized for development
<azonenberg>
there is an open ticket to switch to relative paths rather than absolute paths
<azonenberg>
meaning if you did the top level checkout via https all submodules are pulled via https
<azonenberg>
but someone needs to put some time into testing that
<Degi>
Huh
<miek>
i think it should just be changed, the ssh urls are only useful to you - nobody else that checks it out, and you can just override it locally
<azonenberg>
miek: well my theory was that anyone cloning the repo at the current stage of maturity is likely a developer
<bvernoux>
I do not understand why it break pushing via SSH
<bvernoux>
personnally I never push using SSH ;)
<bvernoux>
but using https and it is the same at end
<bvernoux>
big advantage is with https it does not requires an account
<miek>
those URLs only get used on submodule init anyway - it wouldn't break anything for an existing clone
<Degi>
Where can I see WFM/s
<miek>
bottom right corner of the main window
<Degi>
0.2
<Degi>
Cool, GUI is more reactiven ow
<Degi>
It somehow doesnt trigger huh
<azonenberg>
yeah there have been a lot of improvements to the UI. It's possible i broke something around triggering during my refactoring of trigger stuff?
<miek>
does it have anything to trigger on?
<Degi>
OK, turned the waveform gen on
<azonenberg>
i did it blind and coudln't test since i didnt have a rigol
<azonenberg>
Lol, that helps
<Degi>
Now I get 0.9
<azonenberg>
(let it run for a while, it's a running average of the last ten waveforms)
<Degi>
Stable 0.92 with 10 kpts, ill try 1 kpts
<azonenberg>
At some point we should make some notes in the manual on what kind of WFM/s we've got with different hardware, memory depths, and channel counts
<azonenberg>
So people know what to expect
<bvernoux>
yes will be very nice
<Degi>
Now it got stuck after 45 WFMS when I tried to use the gui
<Degi>
How do I change the depth again?
<azonenberg>
Degi: memory depth?
<azonenberg>
double click the timeline
<azonenberg>
There will eventually be menus for a lot of this stuff too. A lot of general UI improvements are needed, i've been mostly working on the back end lately
<Degi>
My scope hung up :c
<bvernoux>
Degi, do you have the latest firmware ?
<Degi>
Also saving last scope settings when starting up would be nice
<Degi>
On the scope? I think so, or one before the last
<bvernoux>
just to know
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUM0K
<_whitenotifier-f>
[scopehal] azonenberg 08aa933 - Changed gitmodules to use relative URLs
<bvernoux>
short term I could be a MSO5072 ;)
<bvernoux>
buy
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUM01
<_whitenotifier-f>
[scopehal-apps] azonenberg 47fa6ca - Changed gitmodules to use relative URLs. Fixes #143.
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #143: Change .gitmodules url in order to allow clone from anonymous user - https://git.io/JJObp
<bvernoux>
ha nice let's check relative URL ;)
<bvernoux>
Degi, could you write your performance with firmware used on Wiki ?
<Degi>
What wiki
<bvernoux>
with the hash of the git used ;)
<azonenberg>
I was thinking just in the drivers section of the manual
<bvernoux>
it will be great to add a wiki and your notes/test with MSO5000 with settings used
<bvernoux>
also your feedback about stability
<bvernoux>
and how it feel
<bvernoux>
I do not really know what mean WFM/s
<bvernoux>
in term of fps
<Degi>
With 1 kpts I get almost 1 WFM/s
<Degi>
1 WFM/s = 1 FPS
<azonenberg>
Not quite
<bvernoux>
it is a full frame corresponding to a full screen with all probes ?
<Degi>
Yes
<azonenberg>
FPS is a measure of display update rate
<azonenberg>
WFM/s is triggers per second
<bvernoux>
ha ok
<azonenberg>
if you are scrolling around the view without downloading new waveforms you may have high FPS and zero WFM/s
<Degi>
Great, the scope hung up again after 109 WFMs
<bvernoux>
so with a 50Hz signal you should have 50 WFM/s ;)
<bvernoux>
with a trigger ;)
<azonenberg>
generally low WFM/s indicates a communications bottleneck and low FPS means rendering is the issue
<Degi>
OK ill continue tomorrow
<bvernoux>
azonenberg, how many WFM/s do you have on your 2 scope ?
<bvernoux>
for example on the test input 1KHz signal with normal trigger
<bvernoux>
as I imagine it change a lot depending on sampling rate ?
<Degi>
It definitely needs better error handling
<bvernoux>
Degi, it is strange the scope is frozen/crash
<bvernoux>
or maybe only glscopeclient ?
<bvernoux>
as the scope is intended to be robust
<miek>
Degi: you should complain to whomever wrote the mso5k driver support :p
<Degi>
No the scope literally turned unresponsive
<azonenberg>
bvernoux: it's not, trust me. most scope firmware is horribly inefficient and not error tolerant at all
<bvernoux>
yes it is not good :(
<Degi>
azonenberg, you had that issue with teks too right
<azonenberg>
Degi: not exactly
<bvernoux>
ha even with tek ?
<bvernoux>
streaming the scope data freeze the scope ?
<azonenberg>
when you send an invalid command the scope seems to stop processing remote commands for a short time, but doesn't freeze the GUI
<azonenberg>
the workaround is to *IDN? a couple of times or just wait a little while
<azonenberg>
then it starts responding
<bvernoux>
ha ok interesting
<azonenberg>
i think it like reboots the scpi server or something
<azonenberg>
(on mso64)
<azonenberg>
i've never had it malfunction when sending well formed commands though
<bvernoux>
so it is not very robust ...
<miek>
i don't think many (any?) manufacturers expected people to be streaming things out at full rate either :)
<bvernoux>
whatba shame compared to my old instruments especially my HP VNA it is ultra robust to any command ;)
<Degi>
Ahhhh why is it all so fragile
<Degi>
Cant they just open source it
<Degi>
On the other hand, a software option costs 2k
<bvernoux>
yes maybe buffer overflow in SCPI parser ;)
<Degi>
Damn scope manufacturers and their software options!!!
<bvernoux>
Degi, you confirm it was the scope which was frozen on your case ?
<Degi>
Hm, when I pressed the buttons on it, it literally did nothing
<azonenberg>
bvernoux: anyway as far as performance goes, with my waverunner 8404m-ms with all four analog and no digital channels enabled, 400K points per channel, 20 Gsps sample rate, I'm getting about 14 WFM/s
<bvernoux>
will be interesting to sniff the ethernet port to check what command do that ;)
<bvernoux>
it is probably not so simple
<azonenberg>
if i only have one channel enabled, i get about 50 WFM/s
<Degi>
On the rigol it crashes after x samples
<Degi>
My guess is that an internal buffer overflows
<bvernoux>
azonenberg, ha ok very interesting
<azonenberg>
With 1M points on a single channel I get about 30 WFM/s
<azonenberg>
1M points on two channels I get around 15
<bvernoux>
azonenberg, do you know how many MB/s it is ?
<Degi>
Lol I wonder what blondel will be able to do (it has 10GbE right?)
<azonenberg>
bvernoux: I'm getting 200 Mbps sustained right now with 2 channels @ 1M points, ~15 WFM/s
<azonenberg>
the scope has gig-e so maybe its software limited scope side
<azonenberg>
Degi: I think once we get more than a couple of Gbps of waveform data, glscopeclient will need serious optimization to keep up
<azonenberg>
not saying we cant do it, but it will take work and likely not be possible with the code we have right now
<azonenberg>
But i'll have a better idea of that once maxwell is ready
<azonenberg>
Among other things i definitely need to optimize how we handle multi-bit digital waveforms
<miek>
my scope maxes out around 30Mbps
<azonenberg>
right now each point in a digital bus is a std::vector<bool>
<azonenberg>
which is... not scalable
<bvernoux>
ok interesting
<bvernoux>
I doubt 40Gbit/s is required ;)
<bvernoux>
10Gbit/s is still ultra fast to do anything with the data
<Degi>
We could do it entirely on the GPU
<azonenberg>
Degi: that is the long term goal
<azonenberg>
but we have a LOT of work to do before reaching that point
<Degi>
Then some footnote on the git repo says "requires RTX3080 to run"
<bvernoux>
I think it shall be challenging to do some math stuff on 10Gbit/s data ;)
<Degi>
Eh, GPU's can get some TFLOPs easily
<bvernoux>
azonenberg, does tek6 can go faster than 200Mbit/s ?
<azonenberg>
bvernoux: not over a VPN from the US to Europe :P
<bvernoux>
azonenberg, so far you cannot test that remotely but it will be interesting
<azonenberg>
I'll let you know how far i push the tek5 when i get it in my lab
<Degi>
Oh wow, the nvidia site says "Minecraft (RTX ON)" I thought that was a meme
<azonenberg>
Degi: yes math functions are the easy bit
<azonenberg>
the hard part will be stuff like CDR PLLs
<azonenberg>
that don't parallelize well
<Degi>
Hmm yes
<bvernoux>
azonenberg, and why do you plan 40Gbit/s version ?
<bvernoux>
I have never seen any PCIe card doing that so far ;)
<azonenberg>
bvernoux: i have a 40G NIC in my desktop
<azonenberg>
and the reason is that i have four serdes lanes available on the fpga
<azonenberg>
seemed a shame to only hook up one :
<azonenberg>
:p
<bvernoux>
ha yes there is some 40Gbit Ethernet card in fact ;)
<Degi>
PCIe 2.0 x16 can already do 64 Gbit/s data
<azonenberg>
You can always get a 40Gbase-SR4 optic and hook up a fanout cable to only use one 10G lane
<azonenberg>
this is what i primarily intend to do
elms has quit [Ping timeout: 246 seconds]
kc8apf has quit [Ping timeout: 246 seconds]
futarisIRCcloud has quit [Ping timeout: 260 seconds]
<bvernoux>
yes it seems overkill 40Gbit/s ;)
wbraun has quit [Ping timeout: 260 seconds]
lukego has quit [Ping timeout: 240 seconds]
<Degi>
PCIe 5.0 which is the newest stuff apparently should be able to do 512 Gb/s
LeoBodnar has quit [Ping timeout: 246 seconds]
<bvernoux>
It is a shame as no any PC have 10GBit Ethernet card natively today
<bvernoux>
only 1Gbit
<Degi>
Now if some company puts a RTX3080 onto M.2 format....
<bvernoux>
I do not speak about special ultra expensive computer ;)
<bvernoux>
Degi, so far MSO5000 is a bit disappointing to be used with glscopeclient ;)
<bvernoux>
I'm not sure I will buy it even if it is very cheap for the potential
<bvernoux>
as my aim was to use a scope with glscopeclient
<Degi>
Ah okay
<bvernoux>
and a dedicated PC
lukego has joined #scopehal
wbraun has joined #scopehal
futarisIRCcloud has joined #scopehal
kc8apf has joined #scopehal
LeoBodnar has joined #scopehal
elms has joined #scopehal
<bvernoux>
Degi, will be interesting to create an issue to Rigol for that
<miek>
it would be interesting to write a little c app or something that just tries to poll it as fast as possible, to get a baseline
<bvernoux>
Degi, maybe they shall fix that and maybe improve the speed too
<Degi>
Eh I just wanted a cheap fast scope
<bvernoux>
-shall+will
<Degi>
I wonder how hard it'd be to get the chips which I found a few days ago... Then we could make an open source oscilloscope which blows current scopes out the market
<bvernoux>
miek, yes clearly
<bvernoux>
miek, do you have also a MSO5000 ?
<Degi>
The DATA?
<miek>
nope
<bvernoux>
Degi, yes pull the data as fast as possible with a simple C app
<bvernoux>
to check MB/s and stability ;)
<Degi>
Why C tho
<bvernoux>
and send that to Rigol if it crash ;)
<bvernoux>
because C is the fastest ;)
<Degi>
EH not necessarily
<bvernoux>
for such simple things it is good ;)
<bvernoux>
especially with few line of code using socket
<bvernoux>
I can provide you a simple TCP client
<bvernoux>
I do not know what are the commands and data format
<bvernoux>
If we can prove the issue is with Rigol scope with a basic test they shall fix that
<bvernoux>
as it seems not usable until such things is fixed
<bvernoux>
what is nice is reverse engineering on MSO5000 is very deep
<bvernoux>
on the FPGA part it is an other story anyway ;)
<Degi>
I could get 100 frames in 760 ms
<Degi>
Well 230 ms if I dont print the resultö
<azonenberg>
Degi: wait you can get 100 waveforms in 230 milliseconds?
<Degi>
Not sure
<azonenberg>
that sounds ridiculous, that's like 400 WFM/s
<Degi>
Well 100 DATA? requests
<bvernoux>
I confirm relative path is life changer ;)
<bvernoux>
on Windows ;)
<azonenberg>
Degi: but are you waiting for replies?
<Degi>
Yes
<bvernoux>
I can clone easily with TortoiseGit ;)
<Degi>
Without waiting its like 1.6 ms
<azonenberg>
and how many points? and are you waiting for a trigger between thm?
<bvernoux>
yes it is a shame to use a GUI to do git ;)
<Degi>
1k, 10k
<Degi>
Not sure how to wait for trigger
<Degi>
Hm something is wrong
<azonenberg>
Thought so :P
<azonenberg>
The loop you should be doing is
<azonenberg>
:SING
<bvernoux>
yes it will be interesting to check vs glscopeclient
<Degi>
No way it can do 25 MS in 389 ms for 100 ACQs
<azonenberg>
:TRIG:STAT?
<bvernoux>
if there is anything which could be optimized who know
<azonenberg>
wait until you get "TD" or "STOP"
<bvernoux>
yes let's do exactly same sequence as glscopeclient ;)
<bvernoux>
just drop the data
<bvernoux>
and count MB/s
<Degi>
Hm, what is WAV:STAR and WAV:STOP huh
<azonenberg>
then for each channel WAV:SOUR channelname
<azonenberg>
WAV:PRE?
<bvernoux>
will be interesting to share this code to check other scope
<bvernoux>
to be used like a benchmark
<azonenberg>
Degi: i believ eit's the start and stop points within the buffer that you want to see
<azonenberg>
and apparently you can only download 250K at a time
<azonenberg>
Who wrote the rigol driver? i cant remember lol
<Degi>
I guess channel name "1" etc is fine
<Degi>
What is wav pre? Its parameters?
<bvernoux>
x44203 wrote it
<bvernoux>
at start in history
<azonenberg>
I would suggest we start out by wireshark'ing the driver running and note timestamps on packets
<bvernoux>
yes it is a big advantage to use Ethernet for that ;)
<azonenberg>
you can do it with usb too
<bvernoux>
yes but it is less visible ;)
<azonenberg>
wireshark works with usb
<bvernoux>
I had lot of issue in paste with it
<Degi>
Oh no I filled the scope stack or so lol
<bvernoux>
it read what the computer see ;)
<bvernoux>
especially on windoz
<bvernoux>
clearly far from a real USB analyzer
<bvernoux>
Degi, haha again ;)
<bvernoux>
it seems confirmed that MSO5000 does not support 50Ohms ...
<bvernoux>
Degi, very nice so you have a basic code which reproduce the lockup
<bvernoux>
in python ;)
<Degi>
hm not that reproducibly.
<Degi>
I stopped the code, it was behaving weird
<bvernoux>
ha ?
<Degi>
After like a minute the scope blinked around and locked up
<bvernoux>
so like in glscopeclient
<Degi>
With the python code
<bvernoux>
will be great to send that to rigol to fix the MSO5000 FW
<bvernoux>
it is a very good POC very simple
<Degi>
Maybe if it can work reproducibly
<bvernoux>
yes
<bvernoux>
I think I will buy it anyway ;)
<bvernoux>
and sell my DS1102E for 50euros ;)
<bvernoux>
like that I have space for MSO5000
<bvernoux>
until I can buy the Tek 6B ;)
<bvernoux>
I'm pretty sure there is huge potential with this cheap scope
<bvernoux>
for info there is design to do a cheap PLA2216
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 240 seconds]
bvernoux1 has quit [Client Quit]
<Bird|otherbox>
azonenberg: you rang?
<azonenberg>
Bird|otherbox: not recently
<azonenberg>
i was probably just saying forget the GOMP stuff for now
<azonenberg>
focus on more pressing issues
<Bird|otherbox>
ah, right :)
<Bird|otherbox>
will take another look thru the tickets, will also pull master down into the new GUI branch
<azonenberg>
Ok
<azonenberg>
For this evening my focus is finishing tek 5/6 series spectrum view support
<azonenberg>
Bird|otherbox: Within scopehal-apps i would say the best tickets to grab are #59 (easy refactoring, i just want to get it out of the way), #140 (build system fix), #139 (I think this is actually a scopehal-docs fix), #175 (about dialog)
<azonenberg>
These are all fairly low effort issues that are pretty self contained and don't have dependencies on a lot of other stuff
<Bird|otherbox>
I can grab the about dialog stuff then
<azonenberg>
Ok great
<azonenberg>
as far as content it should display the following (I'm not picky on formatting for now)...
<azonenberg>
* copyright 2012-2020 me
<azonenberg>
* list of contributors, put github usernames to start and then we can replace those with real names on request
<azonenberg>
* git hash (this will need some cmake integration probably)
<azonenberg>
* BSD license (either as text or just a mention "3-clause BSD license" or similar)
<azonenberg>
* version 0.1
<azonenberg>
The single biggest UI priority, though, is the preferences dialog
<azonenberg>
Which katharina might be getting back to soon, hopefully
<azonenberg>
Oh and #53 is another easy one
<azonenberg>
make a properties dialog for waveform groups that allows you to change the display name from the default "waveform group N"