<_whitenotifier-4>
[scopehal-apps] azonenberg 3b27ee7 - Updated to latest scopehal. Removed AVX test case for Filter_FIR since it's now just Vulkan or (for tests only) software fallback
<d1b2>
<chille0417> To be able to use a Siglent SSA3032X-R with EMCview you still need the EMI option in the spectrum analyzer. Thats another €745 on top of the €3995 you already spent. As far as I understand the only thing needed in the EMI option is the quasi peak detection. So yeah, €745 for like five lines of code lol.
<d1b2>
<chille0417> HOWEVER.... a base model SSA3032X-R can be hacked into a fully expanded SSA3075X-R for free. So you get 7.5 GHz instead of 3.2 GHz and all the options for free. Thats like €10k lol.
<d1b2>
<chille0417> And the €50 tinySA have quasi peak built in already!
<d1b2>
<chille0417> So yeah, I'm going to continue my research in what it would take to implement EMC pre-compliance testing into ngscopeclient.
<d1b2>
<chille0417> I thinks there is one more thing the EMC pre-compliance software does that I forgot about. Generating a nice report as a PDF.
<d1b2>
<azonenberg> Report generation is something we will need for a lot of the planned precompliance testing tools
<d1b2>
<azonenberg> So a good cross platform solution for that is worth looking into
<d1b2>
<azonenberg> Also, we need to improve our peak detection feature
<d1b2>
<azonenberg> it works now but is extremely slow and inefficient
<d1b2>
<azonenberg> i suspect the entire algorithm is awful and it should just be ripped out and redone
<d1b2>
<rapzak_> And the €50 tinySA have quasi peak built in already! --> How is that made? 1sec for each 9khz/120khz scan?
<d1b2>
<chille0417> I have no idea. I have never used a tinySA. But I'm thinking about ordering a tinySA Ultra+ to play around with.
<d1b2>
<chille0417> As far as I understand all EMC testing with a sweeping spectrum analyser have to sweep slow to get the needed precision. A tinySA will probably be extremly slow compared to say for example a SSA3032X-R or any other "realtime" spectrum analyzer.
<d1b2>
<chille0417> I read somwhere that a scan can take minutes on a good spectrum analyzer and hours on a slower one. I would assume a tinySA will be even slower than what is considered slow when talking about EMC.
<d1b2>
<chille0417> If the tinySA can sweep 120 kHz in one second a 3 GHz sweep would take around 7 hours.
<d1b2>
<chille0417> With 9 kHz/sec a 1 GHz would take 30 hours.
<d1b2>
<chille0417> So if you're not in a hurry it might be possible. I have no idea if there is any other factors that might be a problem.
<d1b2>
<miek__> i have found even just for general use the tinySA is awfully slow compared to my bench SA
<d1b2>
<chille0417> I'm using weasyprint a lot to generate PDF from HTML. It works greats, but it's written in python. With a simple template engine it should be possible to generate templates that could be puzzled together into HTML and then converted to PDF.
<d1b2>
<azonenberg> I would be fine with HTML as the report output format
<d1b2>
<azonenberg> if the user wants pdf they can make it with a browser
<d1b2>
<azonenberg> What's missing would be all of the other stuff, like making nice printer-friendly plots of waveforms and measurements etc
<d1b2>
<chille0417> I have no idea how the rendering of graph works or how imgui work. But I would guess that it would not be rocket sciende to convert the data into a SVG.
<d1b2>
<chille0417> HTML output would be great. One thing that differs Weasyprint from a browser is that Weasyprint can add things like page numbering, headers, footers, page breaking and other stuff that is useful when working with something that should be converted to a PDF. But with a few different HTML templates that would be easy for the user to select.
<d1b2>
<azonenberg> The native waveform rendering internally is done with software rasterization into a 32-bit floating point texture
<d1b2>
<azonenberg> then tone mapped to RGB with another shader
<d1b2>
<azonenberg> it never exists as a vector
<d1b2>
<chille0417> Haha, okey, then there will probably be a lot more work to convert into vector graphics.
<d1b2>
<azonenberg> I think for print, there's a good chance will want a completely different from-scratch renderer
<d1b2>
<azonenberg> optimized for quality (e.g. antialiasing) vs speed
<d1b2>
<azonenberg> just splatting the shader output into a png embed would be easy
<d1b2>
<azonenberg> as a first step
<d1b2>
<chille0417> Yeah, that would probably be good enough for a while. Vector graphics would be nice in the future, but there is like a million other things that would be more worth to focus on.
<d1b2>
<rapzak_> You will not use 9Khz bandwith all the way to the top... usually you swap at 30Mhz til 120Khz, and maybere there is another step going up in frequency... new FFT based can do 30-60Mhz in one chunk...
<d1b2>
<rapzak_> EMC becomes challenging if you have events there is slower than 1 sec... like every 20seconds and to caputre that in full frequecy range.. then spice it up with azimuth of the table and antenne height and antenne pol... then it becomes fucked (for radioated)
<d1b2>
<altracer> you should be able to find some suitable python plotter, that's still better than embedding Octave interpreter and libs just to load+format+save plots (or relying on the likes of MATLAB)
<d1b2>
<azonenberg> oh we're definitely not using matlab lol
<d1b2>
<azonenberg> So i'm working on redoing the peak detector
<d1b2>
<azonenberg> i think i'm gonna just LPF and find local maxima