<xzcvczx>
azonenberg: is there a reason you are using termios2 over good ol' termios in xptools/UART?
<xzcvczx>
i assume its just for custom baud?
<_whitenotifier-3>
[scopehal] xzcvczx forked the repository - https://git.io/J3dDr
<_whitenotifier-3>
[scopehal] xzcvczx opened pull request #468: fix arguments to variadic functions to be c strings rather than std::string - https://git.io/J3dyi
bvernoux has joined #scopehal
<bvernoux>
Hello
<bvernoux>
Does anyone here have some contact with good electronic resellers in USA/Canada ?
<bvernoux>
as I'm struggling to have at least just a reply when I contact the big ones like adafruit, sparkfun ...
<bvernoux>
The plan is to find resellers for open source HydraBus products
<bvernoux>
in USA/Canada
<bvernoux>
It is first time I try to find resellers in USA/Canada as I receive more and more email to ask how to buy HydraBus in USA
<bvernoux>
and now I have produced a big batch of boards it is possible to sell some boards to more resellers ...
<bvernoux>
azonenberg, I have received 10 connectors 901-10510-2
<bvernoux>
I will test them on a new design I'm planning
<bvernoux>
a revolutionary RF board ;)
<d1b2>
<mubes> @bvernoux I'd speak to @esden ...he's gone through this whole process.
<bvernoux>
yes will be interesting to have feedback
<bvernoux>
especialy I'm not doing lot of money with HydraBus product (especially HydraBus v1) which is intended to learn/hack/pen test electronic stuff ...
<bvernoux>
The aim is not to win money with this hardware anyway else I will have stopped that projects since lot of years ;)
<bvernoux>
So I can understand USA are very protective against foreign country (to protect their buisness...) but here it is clearly not the case on such type of product
<bvernoux>
woo => Skyworks to Acquire Silicon Labs Infrastructure & Automotive Business for $2.75 Billion
<bvernoux>
I'm not sure it is a good things to buy future SI chipset ...
<xzcvczx>
pity they can't acquire microchip and turn it into a good company
<bvernoux>
yes ;)
<bvernoux>
microchip is clearly crappy ...
<bvernoux>
or microchip to be bought by ST ;)
<bvernoux>
and they stop their crappy ATMEGA ;)
<xzcvczx>
something tells me microchip would acquire st before st acquired microchip
<bvernoux>
I'm tired of those arduino 8bits with no ram no flash and which are so expensive ...
<xzcvczx>
and that would not be good
<bvernoux>
ST is independant
<bvernoux>
so far they are protected
<bvernoux>
it is the only firm in Europe to be protected
<bvernoux>
we have lost all others ...
<xzcvczx>
oh ok
<bvernoux>
NXP is an other one but was pratically bought ....
* xzcvczx
is really rather glad that britain put the brakes on nvidia acquiring arm
<bvernoux>
and ST is the only one in EU to have some fabs
<bvernoux>
doing research with government ...
<bvernoux>
anyway I think ARM is at end of their process ;)
<bvernoux>
no innovation they are lagging since few years now
<bvernoux>
and RISCV will hit them hardly soon (it has already started)
<bvernoux>
new market is chinese are using free RISCV IP and adding their own and on mid/long term that will kill ARM ...
<xzcvczx>
lol i think one of the more available riscv dev boards seems to be based on riscv ip and st ip
<xzcvczx>
seems very similar
<bvernoux>
china have clearly take the lead on innovation since few years now and they are unstoppable
<bvernoux>
check the patents ;)
<bvernoux>
they are all chinese guys now for 5G, 6G ...
<bvernoux>
it is time we wakeup in Europe ;)
<xzcvczx>
i think america is just going to keep doing huawei on each of them to keep them down
<bvernoux>
I think it is too late unfortunately for EU :(
<bvernoux>
yes we are already all behind China for new technology
<bvernoux>
will be good to work together ;)
<bvernoux>
and inject lot of billions in Fab/new technology to counter china
<bvernoux>
In USA there is still some Fab like TI, Analog Device but I imagine it is not even 10% of components produced (just the one with very good margin) and majority of chipset things are done in Fab in China/Taiwan/Japan
<bvernoux>
Interesting point like TI have lot of Fab but they use old technology node ...
<_whitenotifier-3>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/J3Fne
<_whitenotifier-3>
[scopehal] xzcvczx c386a3b - fix arguments to variadic functions to be c strings rather than std::string
<_whitenotifier-3>
[scopehal] azonenberg a4b86a0 - Merge pull request #468 from xzcvczx/c_strfixes fix arguments to variadic functions to be c strings rather than std::string
<_whitenotifier-3>
[scopehal] azonenberg closed pull request #468: fix arguments to variadic functions to be c strings rather than std::string - https://git.io/J3dyi
<azonenberg>
xzcvczx: good catch, on a lot of systems that wont even run
<xzcvczx>
azonenberg: i only caught it because clang moaned at me
<xzcvczx>
moaned/errored
<xzcvczx>
and its nice to see that glscopeclient runs on my old piece of crap laptop running bsd
<xzcvczx>
with a few modifications
<azonenberg>
And yeah interestingly gcc did not
<azonenberg>
gcc complains if you pass a std::string to printf-family functions
<azonenberg>
but not all varadics
<azonenberg>
otherwise i'd have seen it a long time ago
<xzcvczx>
oh woops my bad for hte mispell
<bvernoux>
what do you think of ultra ambitious plan from Biden ?
<bvernoux>
IIRC he has spoken of billions USD to rebuild USA and be more competitive and so on
<azonenberg>
xzcvczx: oh? what did you have to modify
<azonenberg>
bvernoux: i kinda stopped paying attention to political stuff when trump left office because i was no longer quite as worried about somebody starting world war 3 or killing everyone by ignoring the pandemic
<azonenberg>
:p
<bvernoux>
azonenberg, yes but Biden seems more pacific vs Trump ;)
<azonenberg>
xzcvczx: Are these changes you made breaking to linux?
<azonenberg>
or windows?
<azonenberg>
i'm all for adding BSD support just not at the expense of the main platforms
<xzcvczx>
they can be #ifdeffed out and a couple of them i have
<azonenberg>
Please prepare PRs when you have the time
<bvernoux>
azonenberg, do you plan to merge noopwafel soon for Pico3000 ?
<bvernoux>
I think it need a little refactor on the name
<bvernoux>
as the PS6000 dir will support pico3000A & Pico6000
<azonenberg>
bvernoux: current plan is to finish MSO channel support for 6000 series
<azonenberg>
then check with her on status
<azonenberg>
a name change is planned
<bvernoux>
ha yes it is more important to finish the MSO stuff
<xzcvczx>
azonenberg: just to confirm the only reason for using termios2 was for custom bauds?
<xzcvczx>
custom/non-standard
<azonenberg>
xzcvczx: I believe so, yes
<bvernoux>
azonenberg, are you working on MSO stuff now ?
<azonenberg>
but i wrote that code probably a decade ago
<xzcvczx>
okay, thats the only large one, the others are mainly 3 liners
<xzcvczx>
but main.cpp i need to figure that one out as freebsd doesn't have proc by default for readlink so i need to find a better way
<azonenberg>
xzcvczx: Don't worry about that one
<azonenberg>
that chdir is going to be removed longer term
<xzcvczx>
well my current workaround was just commenting out the return and running it from the right dir :)
<azonenberg>
bvernoux: Yes. As of now i can detect MSO channel pods and only enable/disable them if the hardware/sample rate config allows (and the pod is present - unlike lecroy, pico allows you to check whether one is plugged in)
<azonenberg>
i can configure threshold and hysteresis via SCPI commands in the bridge, but the pico driver does not yet send those commands
<azonenberg>
the main thing missing is actually pulling waveform data
<azonenberg>
which is hopefully happening in the next few hours
<bvernoux>
azonenberg, ha ok nice so it is not far to be working
<bvernoux>
IIRC it is the first scope with support of MSO ?
<bvernoux>
github have added a very convenient feature
<bvernoux>
when forking a repo (especially for glscopeclient and all subrepo)
<bvernoux>
there is Fetch upstream feature to synchronize all from upstream from github web interface
<bvernoux>
before that it was a pain to update the fork from mainstream requiring to do it from cmd line ...
<azonenberg>
xzcvczx: I didn't write that code, that was katharina. Would have to spend a while reading it
<xzcvczx>
ah my bad saw someone elses name in the .h but didn't see it in the .cpp
<xzcvczx>
so i wasn't sure
<azonenberg>
$ git blame
<azonenberg>
:p
<xzcvczx>
true, my bad
<azonenberg>
I mean she's not that active in the project anymore so if we have a bug i still want to know about it
<azonenberg>
But I dont know that code well
<xzcvczx>
its a really terribly named flag
<xzcvczx>
seeing as its just a optimisation thing
<azonenberg>
PRs accepted :)
<xzcvczx>
yeah fair enough, i was just moaning about the naming of the flag though
<xzcvczx>
azonenberg: btw the scope selector dialog seems a bit broken? i chose demo scope transport null and it kept complaining that transport coudldn't be null for anything but demo and ?siglent? i think it was
<xzcvczx>
i ended up just loading a csv as that skipped that dialog
<azonenberg>
You need to put "null" as the path as well iirc
<azonenberg>
The connection dialog needs to be redone to be a more full featured welcome dialog with ability to open a file etc too
<xzcvczx>
ah ok cool
<azonenberg>
right now its a bit less userfriendly than i'd like
<azonenberg>
i never use it, i just connect from the CLI lol
<azonenberg>
The other option which might actually be better is to open up as an empty window and let you pick a file from the menu, then have a "connect to scope" dialog there or something. Not sure what'll be the best UX
<azonenberg>
you should be able to get to the demo scope via the CLI as glscopeclient name:demo:null:null
<azonenberg>
the last argument can be literally anything other than an empty string
<xzcvczx>
oh ok i will try to remmeber that
<azonenberg>
the parser needs at least one byte there but it's ignored
<azonenberg>
(the null transport doenst actually take any arguments)
<xzcvczx>
i was mainly just trying to get something running to see if it would bomb out from lack of opengl 4.3 (i wasn't sure if mesa on bsd showed the compute extension properly)
<azonenberg>
It only actually needs 4.2 plus a bunch of extensions
<azonenberg>
not all of 4.3 is required
<azonenberg>
but compute shaders are one of those extensions
<azonenberg>
turns out there are a few compute shader impls that dont do all of 4.3
<xzcvczx>
yeah but wikipedia only says compute shader is on linux mesa so i didn't know if that carried over to bsd
<azonenberg>
That i dont know
<xzcvczx>
it does :)
<azonenberg>
update wiki? :p
<azonenberg>
if you get glscopeclient fully usable on BSD definitely send me a PR for the docs to include info on known working platforms, build instructions, etc too
<xzcvczx>
ffts was actually more of a dog to get working
<xzcvczx>
i was missing what the problem was and it was demanding sse3 without telling it to use sse3
<azonenberg>
Interesting
<azonenberg>
i dont intentionally use any SSE although idk if ffts does
<azonenberg>
its all the compiler
<azonenberg>
I use AVX routinely, but do runtime checks for support before using it
<azonenberg>
the general compiled C++ wont use it
<xzcvczx>
haha i also had to change cmakelists to add -m avx for clang
<xzcvczx>
-mavx rather
<azonenberg>
interesting
<xzcvczx>
ummm it wouldn't build without it
<azonenberg>
because that enables avx *everywhere*
<xzcvczx>
can't remember what it was that moaned though
<azonenberg>
With gcc i explicitly use __attribute__ on the functions that use avx to tell it it's OK to use avx2 there
<azonenberg>
while having all other code not use it
<xzcvczx>
clang is also quite a bit louder building
<azonenberg>
What you've done works but produces a binary that won't run on a pre-AVX platform
<azonenberg>
yeah i havent checked for clang warnings. on gcc it should emit ~no warnings
<xzcvczx>
i didn't have to add avx2 support so i guess thats all runtime but avx definitely required compile time
<xzcvczx>
when i have some time i will work out exactly what the problem was
<azonenberg>
ok
<azonenberg>
it *should* not require avx at compile time, on gcc i use the default cflags which i think is compatible with any x86-64 host
<azonenberg>
even back to first gen
<azonenberg>
At some point i may switch the minimum so it will start using a slightly newer CPU, say sandy/ivy bridge, as a minimum
<xzcvczx>
feel free to make my one minimum :P
<azonenberg>
lol what CPU are you using?
<azonenberg>
the other thing we need to do WRT platform support is add some #ifdefs around all the avx so it wont even try to compile it on non-x86
<azonenberg>
we have some folks trying to get it to build on arm
<xzcvczx>
Intel(R) Core(TM) i7-3520M CPU
<xzcvczx>
ivy bridge
<azonenberg>
and integrated gfx or discrete?
<xzcvczx>
integrated
<xzcvczx>
its a laptop
<azonenberg>
and do you remember about what year you got it?
<xzcvczx>
well i got it last year but its a 2013 laptop
<azonenberg>
So 2013 model year, ok. yeah that doesn't sound unreasonable as a minimum
<azonenberg>
AVX2/AVX512 is still not supported on some low end modern CPUs like atoms iirc, so i still need runtime checks for that
<xzcvczx>
is it even supported on the "pentium" branded crap?
<xzcvczx>
"pentium" branded waste of silicon
<d1b2>
<mubes> @azonenberg loosely related subject...if I replace this quadra P1000 what should I spring for? AMD or NVidia? I know you're running Nvidia but if it helps to be doing testing on AMD I can happily go with that...
<azonenberg>
mubes: I don't know the mix of our end users' machines so cant say. I'm all NV here so that is the most likely to work flawlessly
<azonenberg>
well ok not *all* NV
<azonenberg>
my main and lab workstations are a 2080 Ti and quadro K5200
<azonenberg>
my work laptop has some kind of quadro that i have not got working under bumblebee
<azonenberg>
so i only ever use the integrated intel card
<xzcvczx>
not been able to get hold of one of them 3090s yet eh? :P
<azonenberg>
I havent tried
<azonenberg>
i bought the 2080 a year or so ago
<d1b2>
<mubes> Ok, I'll go NVidia and recent-ish then.
<azonenberg>
this machine came with the quadro because the card i wanted at the time was out of stock
<azonenberg>
the lab box had a 900 series card
<azonenberg>
i moved the quadro to replace the 900 as it was about the same age but a higher spec card w/ ~double the core count
<azonenberg>
then got the 2080 for this one
<azonenberg>
i will probably do the same on my next upgrade
<azonenberg>
move the 2080 to the lab box and get something new here, then bin the 2014-era quadro
<azonenberg>
mubes: well so the one thing it might help with is opencl performance
<azonenberg>
opencl is amd's main gpgpu API iirc
<azonenberg>
so their dev tools, profilers, etc should handle it well
<azonenberg>
while nvidia wants you to use cuda and their profiler actually deprecated opencl support a while back
<azonenberg>
so i have no way to do performance tuning on my opencl code on nvidia
<azonenberg>
Longer term i think we are going to be forced into maintaining a dual stack gpu backend using cuda on NV and opencl on AMD
<azonenberg>
i dont have the time for it now but i think it will be much easier to squeeze good performance out of NV cards with CUDA
<azonenberg>
i'm not thrilled about the lack of open standards but i also want to get good performance
<d1b2>
<mubes> I can punt for either...tbh the 3060ti is looking a similar price to a decent 2080 card!
<xzcvczx>
if/when i get a workstation i think i will go all amd
<azonenberg>
Your choice. NV is what i know well, i've been using them since CUDA was first released
<azonenberg>
But i will of course continue to support amd to the extent practical
<azonenberg>
And i have no plans to go full CUDA
<xzcvczx>
fair enough i am just not a fan of nvidia only really supporting 1 thing, for eg no support for wayland
<azonenberg>
if we add CUDA support, which i have an experimental ticket for, it will be dual tracked with opencl
<azonenberg>
sorry not experimental, future
<azonenberg>
as in i'm thinking about it but have no code
<xzcvczx>
lol thinking is easy code is time consuming :)
<d1b2>
<mubes> So...to be clear, we expect everything will work fine on AMD, just that current testing has been on NVidia....is that a fair assessment.
<d1b2>
<mubes> (Jeez, it's 2021 and we still haven't sorted out the graphics card driver mess I first it in 1992 with the 4000).
<d1b2>
<mubes> s/it/hit/
<xzcvczx>
the 4000?
<azonenberg>
mubes: I fully expect some of our users have AMD cards
<azonenberg>
I just dont recall anyone mentioning that to me
<azonenberg>
everyone who's mentioned a specific card had intel or nvidia iirc
<azonenberg>
But yes there's no reason to believe it won't work on AMD
<xzcvczx>
well you never know... intel discrete might come out on top soon for gpus and beat nvidia out the market
<azonenberg>
If intel comes out with a dGPU that works well in VTune with OpenCL, that would probably be enough to make me switch
<xzcvczx>
is the ?iris pro? or whatever htey call it not good with that?
<azonenberg>
Havent used it or heard from anyone who has
<_whitenotifier-3>
[scopehal] azonenberg pushed 3 commits to master [+0/-0/±16] https://git.io/J3FM8
<_whitenotifier-3>
[scopehal] azonenberg 68b7881 - Refactoring: now have single Convert8BitSamples() function in Oscilloscope class rather than multiple variants floating around. Fixes #462.
<_whitenotifier-3>
[scopehal] azonenberg 3d1899a - Convert8BitSamples now automatically switches to AVX if available
<_whitenotifier-3>
[scopehal] azonenberg 90457d3 - Moved multithreaded sample processing into Convert8BitSamples() rather than replicating in every class
<_whitenotifier-3>
[scopehal] azonenberg closed issue #462: Refactor Convert*BitSamples() out into base Oscilloscope class - https://git.io/J3DFz
<d1b2>
<mubes> You want to talk optimisation? With 1k of ram you really learned what every z80 opcode did!
<_whitenotifier-3>
[scopehal] azonenberg opened issue #469: Look into updating Agilent driver to use Convert8BitSamples() - https://git.io/J3FMD
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #469: Look into updating Agilent driver to use Convert8BitSamples() - https://git.io/J3FMD
<_whitenotifier-3>
[scopehal] azonenberg opened issue #470: Look into updating Rigol driver to use Convert8BitSamples() - https://git.io/J3FDL
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #470: Look into updating Rigol driver to use Convert8BitSamples() - https://git.io/J3FDL
<_whitenotifier-3>
[scopehal] azonenberg opened issue #471: Optimize RohdeSchwarzOscilloscope::AcquireData() - https://git.io/J3FDS
<azonenberg>
not a near term priority but it could be made a fair bit faster
<azonenberg>
right now it's tagged for v0.2 but feel free to work on it sooner if the mood strikes you. Current priority for R&S remains basic functionality though, we can make it faster later
<d1b2>
<fsedano> Tnx - any reference implementation?
<azonenberg>
Oscilloscope::Convert8BitSamples()
<azonenberg>
you can skip the conversion step as the samples are fp32
<azonenberg>
but the vectorized fill code should be possible to copy pretty much verbatim
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/J3FQL
<_whitenotifier-3>
[scopehal] azonenberg a8d840f - Added vectorized Convert16BitSamples() function
<_whitenotifier-3>
[scopehal-apps] azonenberg labeled issue #340: Don't waste time mapping index/duration buffers on dense packed waveforms - https://git.io/J3F5z
<_whitenotifier-3>
[scopehal-apps] azonenberg opened issue #340: Don't waste time mapping index/duration buffers on dense packed waveforms - https://git.io/J3F5z
<_whitenotifier-3>
[scopehal-apps] azonenberg assigned issue #340: Don't waste time mapping index/duration buffers on dense packed waveforms - https://git.io/J3F5z
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J3F5D
<_whitenotifier-3>
[scopehal] azonenberg ac379bf - PicoOscilloscope: now use vectorized conversion. Fixes #463.
<_whitenotifier-3>
[scopehal-apps] azonenberg c823682 - WaveformArea: don't waste time mapping/unmapping unused buffers on dense packed waveforms. Fixes #340.
<_whitenotifier-3>
[scopehal-apps] azonenberg closed issue #340: Don't waste time mapping index/duration buffers on dense packed waveforms - https://git.io/J3F5z
<azonenberg>
Well that's a nice result
<azonenberg>
it's not any faster in terms of WFM/s on my box, but it uses a lot less CPU
<bvernoux>
yes but on my plateform maybe it will be better ;)
<bvernoux>
especially on my Geforce GT 650M ;)
<bvernoux>
let's rebuild it and check the demo
<azonenberg>
at some point I'll see about using AVX512 for sample conversion, for now it's all 256 bit if possible
<azonenberg>
ok so i'm looking through some vtune data for glscopeclient running on four streaming channels from the picoscope, about 1.8 Gbps of waveform data (1M points * 30ish WFM/s * 4 channels * 16 bit wire resolution)
<azonenberg>
Finishing half-baked stuff, stabilizing the file format, getting the pico and R&S drivers reasonably complete, and getting various portability stuff taken care of
<azonenberg>
and binary packaging
<bvernoux>
I was thinking about nice things to have also
<bvernoux>
like shortcut ;)
<bvernoux>
executing like a script to do multiple things
<bvernoux>
like RS232 decode ...
<bvernoux>
which will convert the signal to digital, then apply rs232 decode ...
<bvernoux>
as today we must do tons of clicks ;)
<bvernoux>
especially on complex things like decoding Ethernet which requires lot of steps
<bvernoux>
So maybe it will be convenient to add some "shortcut with icon..." to do that on a signal (or pair of signal) in 1 click
<bvernoux>
ok latest glscopeclient built ;)
<bvernoux>
all work fine with Demo about 18 to 20WFM/s
<azonenberg>
bvernoux: That's already a todo
<azonenberg>
being able to apply canned filter graphs
<azonenberg>
It's not going to make v0.1
<bvernoux>
yes for long term it is interesting mainly ;)
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #scopehal
juli9611 has joined #scopehal
<noopwafel>
I still want to grab a working vds1022 and add support for those
<noopwafel>
it's kinda a toy scope but they're cheap and would really benefit from better sw; I wrote most of a sigrok driver before realizing sigrok really Does Not Work for scopes
<noopwafel>
but the last one I hadn't lent out seems to have fried itself, usb isolator chip 5V output is like 3V or something
<xzcvczx>
azonenberg: you able to confirm if your cal fried your scope yet?
<xzcvczx>
s/your/the/
<azonenberg>
xzcvczx: at this point i've confirmed it's hardware somewhere behind the front end attenuator
<azonenberg>
because when you change V/div the offset scales
<azonenberg>
It's in the 1M ohm path only, 50 ohm is fine
<azonenberg>
ADC and other stuff is fine
<azonenberg>
suspecting a leaking protection diode but thats as much as i know now
<azonenberg>
It needs to go back to lecroy and they're closed for the weekend so i'm gonna get an RMA monday, probably not actually get it shipped until tuesday
<azonenberg>
then a week or so for it to get to their factory on the other side of the continent
<azonenberg>
and then probably some time for them to go through their backlog of other scopes before they touch it
<azonenberg>
i dont expect any updates for at least 2 weeks
<xzcvczx>
azonenberg: i dont think you can complain too loudly when other side of hte continent isn't nearly as bad as international, esspecially under current circumstances
<azonenberg>
lol
<azonenberg>
i mean i could next day air it if i wanted
<azonenberg>
it would just probably cost as much as the scope
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±5] https://git.io/J3N1I
<_whitenotifier-3>
[scopehal] azonenberg 61bddeb - Moved CRC32 calculation code from PCIe decode to Filter class so it can be reused elsewhere. Added CRC verification to Ethernet decodes. Fixes #55.
<_whitenotifier-3>
[scopehal] azonenberg closed issue #55: Ethernet decode: verify CRCs rather than always displaying as green - https://git.io/Jv0he
<_whitenotifier-3>
[scopehal] azonenberg opened issue #472: Make waterfall display do proper averaging when >1 FFT bin per pixel - https://git.io/J3NpS
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #472: Make waterfall display do proper averaging when >1 FFT bin per pixel - https://git.io/J3NpS
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #472: Make waterfall display do proper averaging when >1 FFT bin per pixel - https://git.io/J3NpS
<_whitenotifier-3>
[scopehal] azonenberg assigned issue #472: Make waterfall display do proper averaging when >1 FFT bin per pixel - https://git.io/J3NpS