<monochroma>
waiting for the april fools one where he is repairing his microwave oven
<azonenberg>
lol
<azonenberg>
you should let him borrow your microwave for that
<azonenberg>
You know the one i'm talking about :p
<monochroma>
XD
<monochroma>
"Now here we can see they actually spent the time to create a good RF gasket on the door frame. This is very rare in modern microwave ovens!"
<azonenberg>
better yet, put it up on the roof inside a big dome
<azonenberg>
with a raytheon logo printed on it
<monochroma>
XD
<monochroma>
azonenberg: have you seen the solid state microwave transmitters?
<azonenberg>
Not for cooking, no
<azonenberg>
although i suspect IGBTs etc have reached that point
<monochroma>
azonenberg: yeah back in like ~2018 started seeing headlines for (primarily) NXP's GaN power amps used for ovens
<azonenberg>
So what i'm hearing is that you can probably make a pretty decent S-band radar transmitter out of a modern microwave? :P
<monochroma>
:D
<azonenberg>
Now you just need to combine it with a microbolometer array and some coherent beamforming
<azonenberg>
To make sure you don't have any cold spots in the food :p
<monochroma>
XD
<GenTooMan>
freescale now NXP was developing circuits for solid state cooking microwave technology. They have a series of 2.4GHz RF transistors that are 250W. I am not sure if NXP is pushing it like Freescale was but the advantage of tuning the RF output with frequency and phase adjustments does have advantages over the broad band dump from a magnetron.
<GenTooMan>
the other advantage is you can very the power fast enough that a giant relay isn't necessary, no high voltage is needed (much lower voltage circuit) either.
<_whitenotifier-a>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JGhHU
<_whitenotifier-a>
[scopehal-apps] azonenberg 9805b86 - Added toolbar button for "force trigger" event. Currently uses same icon as "start single trigger" (see #133)
<azonenberg>
Attention driver devs (GenTooMan, Degi, miek, bvernoux, noopwafel, and anybody else I forgot): Oscilloscope now has a ForceTrigger() method
<azonenberg>
It works correctly on LeCroy, in Pico it sends a "force" command the bridge does not yet understand
<azonenberg>
There is an untested implementation in the Tek driver based on the command reference I have, but I lack a MSO5/6 to test against
<azonenberg>
Rigol, Siglent, and others have empty stubs that print warning messages
<azonenberg>
So please implement at your convenience
<azonenberg>
Also woo, down to 32 open tickets between scopehal and scopehal-apps blocking v0.1. And ~7 of them are in progress
someone--else has joined #scopehal
electronic_eel_ is now known as electronic_eel
someone--else has quit [Quit: Connection closed]
<electronic_eel>
azonenberg: could you check if you have some sample data i can use to check the clFFT support with?
<electronic_eel>
i'm working on packaging clFFT but i don't have any experience using opencl yet, so i don't know how to verify that it acutally works
<electronic_eel>
i mean i can call clinfo, but that's about it. would prefer to have some real-world test
<_whitenotifier-a>
[scopehal-pico-bridge] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JGjkU
<azonenberg>
electronic_eel: just use the demo scope
<azonenberg>
and run a fft on, say, the sweeping tone waveform
<azonenberg>
verify that you see two peaks, one fixed at 1 GHz and one sliding from i think 1.1 to 1.5
<azonenberg>
run with --noopencl and you should get the same behavior
<electronic_eel>
ok, but there is no way to differentiate if ffts or clfft is used for the current operation?
<azonenberg>
If opencl was detected at startup time
<azonenberg>
and clfft was available at compile time
<azonenberg>
clfft will be used for the fft, de-embed, and channel emulation filters
<azonenberg>
if you really want to confirm you can add breakpoints to the filter code that calls clfft or something
<electronic_eel>
you wrote something about clfft not being usable for some big waveforms or something along those lines. do you automatically switch to ffts in some cases like this?
<azonenberg>
No. Right now, it just chokes
<electronic_eel>
:-)
<azonenberg>
you have to exit glscopeclient and relaunch with --noopencl
<azonenberg>
I want to confirm the source of the failure is indeed what I thin kit is
<azonenberg>
then add fallback to ffts
<electronic_eel>
that behavior acutally helps in my case
<electronic_eel>
ok, then i know how to test it when i'm finished with packaging
<azonenberg>
Great
<azonenberg>
also, the windows build is still broken
<azonenberg>
dang seems to have got stuck then disappeared for a bit so if anybody else wants to try unbreaking it, that would be great
<azonenberg>
it's related to recent library changes
<azonenberg>
GyrosGeier i think found the exact commit that's at fault
<electronic_eel>
i think i'll just upload the finished rpms on my server for now. once you have a domain for scopehal up, we can move them there
<azonenberg>
I've just been too busy to do anything about it
<azonenberg>
Sure
<azonenberg>
Lots of logistics to take care of still
<electronic_eel>
do you want to do the build of the different packages yourself in the long run or do you want others like me keep doing it?
<electronic_eel>
if you want to do it, i guess we should devise a method to automate it, to make it easier for you to run it
<azonenberg>
I'd prefer separate maintainers
<azonenberg>
i'm busy enough as it is
<azonenberg>
that said, automation is still advisable in case we need to turn over a package to a new maintainer
<azonenberg>
or just to save you time :p
<electronic_eel>
if it is just my own infrastructure, i can easily automate that myself. just hardcoding stuff and expecting a build vm in a specific state makes that easier than some automation that is portable or well documented enough that it can be run anywhere
<electronic_eel>
but in the end the actual work is in the .spec files
<electronic_eel>
and those will of course be in some repo and be documented well enough that everyone can use them on their own
<azonenberg>
Make it work first, improve usability of infrastructure later
<electronic_eel>
it is already working, but yet without clfft
<azonenberg>
yeah i meant make the whole packaging chain work with all dependencies
<azonenberg>
Just wait till we add cuFFT as an alternate backend :p
<electronic_eel>
cuFFT, doesn't that only work when using the binary drivers from nvidia?
<azonenberg>
Correct. But that's what I use
<azonenberg>
I want to play with CUDA as an alternative acceleration platform to OpenCL at some point
<azonenberg>
I've used it a lot in the past (way back, like geforce 9800 to 480 era)
<azonenberg>
and nvidia's dev tools are much better for cuda than for opencl
<azonenberg>
so it might make sense to write some kernels in cuda then port to opencl
<azonenberg>
for example nvidia's profiler just doesn't work with opencl
<azonenberg>
At all
<electronic_eel>
are all the driver stubs and libs and stuff published with a permissible license like bsd so that you can link them to scopehal?
<azonenberg>
I'd probably be using the cuda c api, not their compiler wrapper. The license allows use with proprietary software so i can't imagine it being a problem for linking with anything else
<azonenberg>
it might be an issue if you wanted to GPL without the proprietary linking exemption or something?
<azonenberg>
In any case it would be an optional component that you don't have to enable
<azonenberg>
anyway the big advantage of going cuda vs opencl, or gl compute, from a performance perspective is that it gives you access to much more toggles you can adjust to tune performance for your application
<electronic_eel>
at least i won't be able to easily test if the cufft stuff is working - i switched to a amd gpu explicitly because they have good open source drivers and nouveau wasn't good enough on newer gpus
<azonenberg>
for example, nvidia cards allow you to configure some of the on chip sram as either shared memory or l1 cache
<azonenberg>
l2*
<azonenberg>
there's several different modes with different tradeoffs depending on how much shared mem you need, etc
<azonenberg>
AFAIK there is no way to use a non-default partitioning via any of the open standard APIs
<azonenberg>
And nouveau is a piece of garbage IMO, it's never been usable for me. certainly not for the kinds of GPGPU work I normally buy cards for
<electronic_eel>
is the gpu acceleration and it's optimization currently the bottleneck in some scenarios? i'd guess getting the data out of the scope fast enough would usually be the bottleneck
<azonenberg>
It depends on what you're doing
<azonenberg>
Complex filter pipelines definitely can get slow especially with de-embeds
<azonenberg>
also FIR filters, equalization, preemphasis, etc
<azonenberg>
they're very numerically intensive and had trouble keeping up with even my lecroy scopes' waveform throughput without acceleration
<azonenberg>
also, if you're using history mode stuff
<azonenberg>
every time you switch from one waveform to another, the filter graph re-runs
<azonenberg>
since filter output is not cached in the history buffer, just the input waveforms
<azonenberg>
So if you're running a de-emphasis removal filter on 128M points, there's a noticeable lag shifting between historical waveforms
<electronic_eel>
ah, ok, yeah, then looking into better gpu acceleration makes sense
<electronic_eel>
just make sure that it still works without cuda
<azonenberg>
cuda will never be required
<azonenberg>
opencl will never be required except on osx as right now it looks like the only viable path to accelerated rendering given the lack of gl 4.3
<electronic_eel>
apple wants you to rewrite big chunks of any decent software, just that it runs on osx. then one or two years later they throw out their apis again, so you have to rewrite again. that is just nuts
<azonenberg>
Yep. So I'm going to use whatever open standards I can, and if/when it runs on osx, great
<azonenberg>
if not, sucks to be an apple user
someone--else has joined #scopehal
someone--else has quit [Quit: Connection closed]
nelgau has joined #scopehal
nelgau has quit [Ping timeout: 245 seconds]
<GenTooMan>
azonenberg, it sucks to be an apple user either way doesn't it?
<_whitenotifier-a>
[scopehal-apps] electroniceel opened issue #376: std::bad_alloc exception when running the demo scope for some time - https://git.io/JZvFj
<_whitenotifier-a>
[scopehal] mubes opened pull request #495: Addition of forced trigger - https://git.io/JZfKU
ericonr has quit [Ping timeout: 268 seconds]
ericonr has joined #scopehal
someone--else has joined #scopehal
<_whitenotifier-a>
[scopehal-apps] mubes commented on issue #133: Commission toolbar icons for "auto trigger" and "force trigger" - https://git.io/JZJ6A