search

analogdevicesinc / scopy

A software oscilloscope and signal analysis toolset
http://wiki.analog.com/scopy
GNU General Public License v3.0
398 stars 164 forks source link

Spectrum Analyzer shows no data and crashes after changing Resolution Bandwidth #966

Closed ForthDude closed 3 years ago

ForthDude commented 3 years ago

I am running Scopy 1.2.0 e02cebe on an ADALM2000 Firmware version 0.26, IIO version 0.21

The spectrum Analyzer shows no data when I start it.

I have reset the settings for Scopy, the problem stays the same.

When I change the Resolution Bandwidth and then start the spectrum analyzer then Scopy crashes.

adisuciu commented 3 years ago

What OS are you running ? What are your system specs ?

ForthDude commented 3 years ago

Sorry, I forgot to mention This problem shows up here on two x86_64 Linux machines. One is Ubuntu 20.04, the other one Ubuntu 16.04. The 20.04 has 16GB of RAM and an i7 processor. Thanks for looking at this...

adisuciu commented 3 years ago

Interestingly, ubuntu is our most stable platform. I assume you are running flatpak.

Can you make sure the ADALM2000 doesn't have a power outage while running - try different USB cable or use rightmost USB for power(you can even use a power brick to test) and middle USB for connection to the computer

Do the rest of the instruments work correctly ? Do you get any output in the terminal when this happens ?

This may be a werid questions, but are you running a 4K resolution ? If yes, can you switch it up to 1080p and retry ? Things get weird when running 4k in the spectrum analyzer because we're lacking an optimisation in the plot, and the spectrum analyser has to draw a lot of points.

There is a enable debug messages checkbox in the preferences. If you enable it, do you get any popups before the crash ? You could also try v1.1.2 to see if you get this crash when running the spectrum (not much has changed to that instrument in the latest version)

-Adrian

ForthDude commented 3 years ago

Thank you for the quick reply, yes I am running flatpak. I just added a separate USB power supply on the right most connector of the M2k and the spectrum analyzer still crashes scopy.

The rest of the scopy instruments work fine for what I can see. When I enabled the FFT view in the oscilloscope I had a Scopy crash as well.

I am not running a 4k monitor. This is a 1920x1200 DVI Display.

When I enable the the log messages I get this on the terminal on the spectrum analyzer crash:

flatpak run org.adi.Scopy ERROR: Unable to claim interface 1:4:5: -16 Warning: Using function expressions as statements in scripts is not compliant with the ECMAScript specification: "function(o) { for (each in o) { print(each); } }..." This will throw a syntax error in Qt 5.12. If you want a function expression, surround it by parentheses. QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QLayout: Attempting to add QLayout "" to adiscope::logic::LogicAnalyzer "LogicAnalyzer", which already has a layout QMetaObject::connectSlotsByName: No matching signal for on_xyLineThickness_currentIndexChanged(int) QMetaObject::connectSlotsByName: No matching signal for on_xyPlotLineType_toggled(bool) QMetaObject::connectSlotsByName: No matching signal for on_nextButton_clicked() QMetaObject::connectSlotsByName: No matching signal for on_restartButton_clicked() QMetaObject::connectSlotsByName: No matching signal for on_finishButton_clicked()
QCssParser::parseColorValue: Specified color with alpha value but no alpha given: 'rgba 25, 25, 25'
QCssParser::parseColorValue: Specified color with alpha value but no alpha given: 'rgba 74, 100, 255'
QCssParser::parseColorValue: Specified color with alpha value but no alpha given: 'rgba 55, 55, 64'
QCssParser::parseColorValue: Specified color with alpha value but no alpha given: 'rgba 25, 25, 25'
ERROR: WRITE ALL: 18446744073709551607

Thank you!

AlexandraTrifan commented 3 years ago

Hi,

Could you send us a screenshot with the configuration you are applying Scopy? (we would like to replicate the start frequency, stop frequency, resolution bandwidth, etc.) Does Scopy hang before crashing? Do you see a status above the Spectrum plot, where the Sample percentage and total number of samples are displayed?

Thank you, -Alexandra

ForthDude commented 3 years ago

Sure, This is after I reset the scopy configuration. Immediately after I pressed the Start button in the top left of the plot it shows

Sample: 100% / 8192 But there is no data. I tried different start/stop ranges, the 8192 changes to other sweep length but I never see any data. The Start button never comes back, I have to stop manually.

If I change the resolution Bandwidth to 48.83kHz and then press the Start button Scopy will crash and shut down. This happens no matter whether I have attempted sweeps before or whether I change to 48.83 kHz before the first start.

SpectrumAnalyzerNoData

ForthDude commented 3 years ago

I have used Scopy version 1.1.2 on this machine before where the spectrum analyzer worked fine. Could there be some remaining configutation file of the 1.1.2 version that confuses the setup of the 1.2.0 ?

adisuciu commented 3 years ago

You can try removing the files in ~/.config/ADI/ and retry. Make sure Scopy is not running when you do this.

We couldn't reproduce this. Does v1.1.2 still work, if you reinstall it ?

-Adrian

ForthDude commented 3 years ago

I shut down scopy, then erased ~/.config/ADI/ , then started again. that didn't change anything.

Then I uninstalled 1.2.0 and installed 1.1.2. There the spectrum analyzer works just fine.

uninstalled 1.1.2 again, erased ~/.config/ADI/ , installed 1.2.0 and the spectrum analyzer crashes again.

Does the FFT or the FFT Windowing or any newly implemented filtering depend on any external library outside the flatpak package? Can there be any of this wrong on my computer here?

Can this be a misconfiguration problem with my iio here? I have libiio Version: 0.21.g565bf68 and libiio-utils Version: 0.19-1 installed here.

ForthDude commented 3 years ago

I found something in /var/log/syslog whenever Scopy crashes: kernel: [ 4108.884559] traps: stream_to_vec15[8881] trap invalid opcode ip:7f869c3bea3b sp:7f86721105c8 error:0 in libgmp.so.10.4.0[7f869c39f000+59000]

Can that help us any further?

adisuciu commented 3 years ago

That is weird .. libgmp is a dependency that was introduced in this version due to gnuradio 3.8 . But we've never seen any problems with it. Invalid opcode might mean that there's either an incompatibility between the library and your processor, or there is a bug in gnuradio that only triggers on your machine (a stray jump lands on that library). Both are unlikely but can you provide cat /proc/cpuinfo ?

Another thing you can do is try to build scopy v1.2.0 yourself, but that is a little more complicated (Ubuntu is the easiest platform to build on)

Libiio is bundled in the flatpak along with the rest of the dependencies, so that shouldn't be a problem in my opinion -Adrian

ForthDude commented 3 years ago

This is a zip file with the cpuinfos of the two machines where it fails. CPUInfos.zip

I will attempt to build scopy 1.2.0 myself but that might take me a day... I'll let you know about the outcome.

adisuciu commented 3 years ago

Some people say that a BIOS update may fix some bad instructions if there are any in your CPU - https://gmplib.org/list-archives/gmp-bugs/2016-July/003976.html - However I find it weird that you have 2 cpu models struck by exactly the same problem

Another thing you can try is to run the newest version (newer than the release) to see if somehow that got magically fixed (new lib version) - https://github.com/analogdevicesinc/scopy/suites/1499070618/artifacts/26172252

As for the build, the instructions are here:

https://github.com/analogdevicesinc/scopy/blob/master/CI/appveyor/install_ubuntu_deps.sh - installs the deps - maybe just run the functions separately as you need instead of running the whole script.

https://github.com/analogdevicesinc/scopy/blob/master/CI/appveyor/build_appveyor_ubuntu.sh - this script builds scopy .. you can also build it from QtCreator

These scripts should work as they are built regularly on our CI

-Adrian

ForthDude commented 3 years ago

I put an ubuntu 20.04 onto a 64GB USB stick so I can boot it on any computer. I installed Scopy on that. The Scopy 1.2.0 e02cebe Spectrum analyzer crashes in exactly the same way on two other machines here.

I tried your newer version (v.1.2.0 21463cd) and the spectrum analyzer crashes in exactly the same way there.

Thanks for the instructions on the build. I'll dive into that and let you know...

adisuciu commented 3 years ago

One more thing we can try, but it's a longshot - when running, can you try running with this command flatpak run --env=LC_ALL=en_US.UTF-8 org.adi.Scopy

This command will set the locale for the flatpak to US. We've had some issues recently with locale in flatpak so it might be worth a shot ..

-Adrian

ForthDude commented 3 years ago

Compiling the preliminaries I ran into this: compiling qwt_polar_fitter.cpp qwt_polar_fitter.cpp: In constructor ‘QwtPolarFitter::QwtPolarFitter(int)’: qwt_polar_fitter.cpp:29:82: error: ‘Polygon’ is not a member of ‘QwtCurveFitter’ 29 | QwtPolarFitter::QwtPolarFitter( int stepCount ) : QwtCurveFitter(QwtCurveFitter::Polygon) | ^~~ make[1]: *** [Makefile:578: obj/qwt_polar_fitter.o] Error 1

I saw the same problem mentioned in an EngineerZone post where you recommended to use a branch version of qwt and also patch some variables before cmaking and compiling qwt and qwtpolar. I checked this and your instal_ubuntu_deps does all this

I had to modify some of the required ubuntu packages to newer versions because the old ones were not available any more for ubuntu 20.04. This is what I made out of your install_ubuntu_deps.sh:

install_ubuntu_depsUbuntu20.04.zip

How can I verify that the libs and includes that the build uses are indeed the versions that you want?

adisuciu commented 3 years ago

Scopy CMake should verify all compatibilities .. we built things on Ubuntu20.04 but didn't update the script. Things went fine. Did you fix the qwtpolar issue ?

-Adrian

ForthDude commented 3 years ago

ok, I solved the building puzzle. I had libqwt-qt5-dev also installed as a package from Ubuntu. It was found in the search path before the one in /usr/local when I tried to compile qwtpolar. I uninstalled it, re-built everything and the compile went through.

I built myself a scopy and the spectrum analyzer works fine in there. I went through all the other devices and everything seemed to work.

So on my side the problem is solved. Can I somehow assist in fixing the issue on your side?

Thank you for your help Steffen

adisuciu commented 3 years ago

Unfortunately we did not get that error on any of our systems. Do all your systems crash like that with the flatpak and fresh USB stick or just specific few ?

Either way, I'm glad things are working out. If we get some more reports (more flatpaks that crash) we'll look into it a bit more. -Adrian

ForthDude commented 3 years ago

With the scopy v1.2.0-Linux.flatpak I have the spectrum analyzer fail the same way on all my four LINUX computers here, even on the machine where I compiled the working scopy on.

I found the Dockerfile in the source code in scopy/CI/appveyor/docker/Dockerfile. If in there I change the version number of org.kde.Platform and org.kde.Sdk to 5.14 then I can build and run the container and inside make myself a scopy.flatpak following the instructions in the README.

On that self-build scopy.flatpak the spectrum analyzer runs fine here on all computers.

I ran md5sum on the three flatpaks that I have here:

4b0933e67d24302c19e0c213fab17acb Scopy-v1.1.2-Linux.flatpak 97695571cfeab3a5a7908cc21f66ac0b scopy-v1.2.0-Linux.flatpak c1dcdcdac197ac7174e740c3e77f782a SelfCompiledScopy.flatpak

adisuciu commented 3 years ago

The dockerfile is a little outdated in the CI folder. We're actually using SDK 5.14 in our oficial scopy distribution (the flatpak is not actually taken from appveyor, but from github actions, which uses a different CI script) so that doesn't explain the problem. Unforunately

-Adrian

tarikgraba commented 3 years ago

Same thing for me with the Flatpack on Debian 10 (buster/stable). Nothing is displayed when using the Spectrum Analyzer.

adisuciu commented 3 years ago

We'll send over a new flatpak in a few days when it's done. If you could test that, it would be great.

ForthDude commented 3 years ago

I will test it and let you know.

adisuciu commented 3 years ago

We may have fixed this here - #1050 Can you give it a try ? https://github.com/analogdevicesinc/scopy/suites/2244955973/artifacts/47401710

Sorry for the delay

ForthDude commented 3 years ago

This version does not crash any more.

After re-setting the configuration I could get data in the oscilloscope FFT view.

When I open the Spectrum Analyzer and sweep between 5 Hz and 5 MHz It works fine down to a resolution bandwidth of 2.44 kHz. At and below a RBW of 1.22 kHz it doesn't show any data any more. In the console where I started scopy it shows this:

scopy > gr::buffer::allocate_buffer: warning: tried to allocate 4 items of size 40000. Due to alignment requirements 64 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. gr::buffer::allocate_buffer: warning: tried to allocate 4 items of size 40000. Due to alignment requirements 64 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. ERROR: WRITE ALL: -9 E20210318 15:57:06.066821 4317 buffer.cpp:479] Buffer: Cannot refill RX buffer

I got similar results on two computers that I ran this on. One was Ubuntu 16.04, the other one Lubuntu 20.04.

adisuciu commented 3 years ago

That's great that it doesn't crash, and weird that it causes these problems. The output looks kinda normal, I'm getting the exact same output, when trying to reproduce, but for me it doesn't crash .. Can you provide Scopy.ini and Preferences.ini ?

-Adrian

ForthDude commented 3 years ago

The spectrum analyzer doesn't crash here either. No crashes at all. It just doesn't show the data. When that happens I can change the RBW to a higher value and it will show data fine again. Attached is a settings file that I saved with the spectrum analyzer set up to show the problem here. Just try different RBW settings. The lower ones don't show data. Independent from this sometimes the oscilloscope FFT view doesn't want to show data either.

SpectrumAnalyzerRBWFail.ini.zip ScopyPreferences.zip

adisuciu commented 3 years ago

Is the range of the spectrum analyzer correct when you do these changes ? We also created this build that adds some extra features to the fft calculation library(but I don't think these should be required, as the instrument works for our usecases) You can try it here - https://github.com/analogdevicesinc/scopy/runs/2150268524

-Adrian

tarikgraba commented 3 years ago

Is the range of the spectrum analyzer correct when you do these changes ? We also created this build that adds some extra features to the fft calculation library(but I don't think these should be required, as the instrument works for our usecases) You can try it here - https://github.com/analogdevicesinc/scopy/runs/2150268524

-Adrian

I have done some tests with this version, the spectrum analyser crashes (the display is not updated anymore) when the resolution BW in the Sweep settings is to small and I get:

ERROR: WRITE ALL: -9
E20210322 13:54:19.031002  1854 buffer.cpp:479] Buffer: Cannot refill RX buffer

Is it due to a hardware limitation? Lack of memory on the host (4GB on my test machine), but it would be helpful to have the BW settings filtered to only display "allowed/possible" BW settings.

adisuciu commented 3 years ago

It is unlikely this is caused by lack of memory. Can you confirm that the buffersize where the spectrum is no longer calculated is the same as reported by the other user (8192 samples) - this value can be seen in the top left portion of the plot. I'm not sure exactly why this small buffersize causes problems.

Can you also confirm that FFT works in the oscilloscope, when using different timebases (different buffersizes/samplerates) ? -Adrian

tarikgraba commented 3 years ago

I confirm that the spectrum is no longer calculated for a buffer of 8192 samples. Should I try on a machine with more RAM?

I also confirm that the FFT works in the oscilloscope mode.

sja1440 commented 3 years ago

I am new to Scopy and ADALM2000. When I run flatpak v1.20 of Scopy on my Ubuntu 20.04 PC I experience problems similar to the previous posters: Spectrum Analyzer does not work.

When I use flatpak scopy v1.3.0-rc2 the Spectrum Analyzer feature does work but with an issue whenever more than 4096 'samples' are selected. For example, with a sweep from 1Hz to 100kHz I see a result only if the Resolution BW is 48.83Hz or greater. With lesser Resolution BW's the Spectrum Analyzer shows nothing.

Whenever the Resolution BW is changed I see entries like the following in the journal:


Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]: ERROR: READ LINE: -9
Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]: ERROR: READ INTEGER: -9
Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]: E20210606 17:09:57.687963  1048 buffer.cpp:479] Buffer: Cannot refill RX buffer
Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]: gr::buffer::allocate_buffer: warning: tried to allocate
Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]:    4 items of size 40000. Due to alignment requirements
Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]:    64 were allocated.  If this isn't OK, consider padding
Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]:    your structure to a power-of-two bytes.
Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]:    On this platform, our allocation granularity is 4096 bytes.
Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]: gr::buffer::allocate_buffer: warning: tried to allocate
Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]:    4 items of size 40000. Due to alignment requirements
Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]:    64 were allocated.  If this isn't OK, consider padding
Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]:    your structure to a power-of-two bytes.
Jun 06 17:09:57 DIRAC org.adi.Scopy.desktop[62064]:    On this platform, our allocation granularity is 4096 bytes.

The FFT function on the Oscilloscope seems to work OK for all selectable time basess.

If you need any futher information to help fix this issue let me know, but note that I will be unavailable until Thursday.

adisuciu commented 3 years ago

Can you try doing the same in demo mode or over remote connection(IP) ? https://wiki.analog.com/university/tools/m2k/scopy#connecting_to_a_remote_device

For demo mode, you go to the same window and click "Enable Demo" - this will create an IIO emulator daemon on your machine you can connect to using the localhost IP (127.0.0.1) - the functionality is limited, but it will show us if it's a hardware connection issue or some kind of software bug (I lean on the latter)

When trying things out in demo mode, it is important to also start the signal generator and output a sine wave - the emulator will assume a loopback between the signal generator and the oscilloscope. This makes sure the spectrum analyzer has some data to work with ...

Can you share your computer(processor) specs ?

We're having a hard time reproducing this .. sorry -Adrian

sja1440 commented 3 years ago

Thanks for the response. I'll provide you with the results when I get back home on Thursday.

On 8 June 2021 12:10:41 CEST, Adrian Suciu @.***> wrote:

Can you try doing the same in demo mode or over remote connection(IP) ? https://wiki.analog.com/university/tools/m2k/scopy#connecting_to_a_remote_device

For demo mode, you go to the same window and click "Enable Demo" - this will create a virtual IIO server on your machine you can connect to using the localhost IP (127.0.0.1) - the functionality is limited, but it will show us if it's a hardware connection issue or some kind of software bug (I lean on the latter)

Can you share your computer(processor) specs ?

We're having a hard time reproducing this .. sorry -Adrian

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/analogdevicesinc/scopy/issues/966#issuecomment-856641353

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

ForthDude commented 3 years ago

Adrian, I still see exactly the same problems that sja1440 describes. Whenever the buffer in the spectrum analyzer is bigger than 4096 it won show data. This can be changed by changing the resolution BW. After I see no data I can change the resolution bandwidth to where the buffer is smaller than 8192, when I start the spectrum analyzer again I get data again.

I did what you suggested and ran the demo IIO emulator daemon and connected to that. In this case the spectrum analyzer shows no data at all at any buffer size.

I put a USB wlan module to my m2k and connected to it through Wifi. There too I see no data at buffer size > 4096. Below buffer size of 8192 things work fine. This is exactly the same as when I connect through USB.

My CPUinfo is: cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping : 10 microcode : 0xa0b cpu MHz : 2602.902 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 5652.54 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:

processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping : 10 microcode : 0xa0b cpu MHz : 2389.892 cache size : 6144 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 4 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 5652.54 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:

processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping : 10 microcode : 0xa0b cpu MHz : 2664.690 cache size : 6144 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 5652.54 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:

processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping : 10 microcode : 0xa0b cpu MHz : 2034.162 cache size : 6144 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 5652.54 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:

tarikgraba commented 3 years ago

I confirm that the spectrum is no longer calculated for a buffer of 8192 samples. Should I try on a machine with more RAM?

I also confirm that the FFT works in the oscilloscope mode.

For the record, I have no issue on a machine with 16GB of RAM. Maybe this will help.

adisuciu commented 3 years ago

I did what you suggested and ran the demo IIO emulator daemon and connected to that. In this case the spectrum analyzer shows no data at all at any buffer size.

You need to start the signal generator and output some data for it to show something .. you didn't need to connect through wi-fi, just connecting ot the default ip address (192.168.2.1 would have worked) - the m2k creates an ethernet over usb (RNDIS) connection ..

Anyways, I'll look again at your CPU info and corelate it with the build options that we put into the flatpak. Thanks, Adrian

adisuciu commented 3 years ago

This may be a long shot, but can you also try this ? https://github.com/analogdevicesinc/scopy/runs/2772857652

ForthDude commented 3 years ago

Hello Adrian, I tried this build and it does not change anything. The behavior is the same as what I described earlier.

ForthDude commented 3 years ago

Hello Adrian, I ran the demo IIO emulator again and this time enabled a sine wave in the signal generator. Now I can see the peaks in the spectrum analyzer. Again, when the buffer reaches 8192 the graph does not update any more. It behaves exactly the same as with the m2k connected.

This was done with the scopy flatpak that I downloaded from https://github.com/analogdevicesinc/scopy/runs/2772857652

AlexandraTrifan commented 3 years ago

Hi,

Could you try the following build? https://github.com/analogdevicesinc/scopy/actions/runs/921871291 In the console output you should see some debug messages, could you send us the output from and before the moment it stops displaying data on the screen?

Also, in the Oscilloscope, could you run the following setup? image This will make the Oscilloscope acquire much more samples. This way we can see if the frequency and time domain from the Oscilloscope behave ok when requesting more samples.

And one more try.. in an older message, you mentioned you managed to build a flatpak on your own, which worked fine. If you still have that setup, could you run a build, redirect the build output to a file and send us the build log file? It would help to see what build configuration is missing from our flatpak.

Thank you!

-Alexandra

ForthDude commented 3 years ago

Hello Alexandra, I ran the build that you asked me to run and watched the console output.

This is a successful Spectrum analyzer shot with a 4096 size buffer

gr::buffer::allocate_buffer: warning: tried to allocate 4 items of size 40000. Due to alignment requirements 64 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. gr::buffer::allocate_buffer: warning: tried to allocate 4 items of size 40000. Due to alignment requirements 64 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. scope_sink_f processing index: 4096 scope_sink_f post event: 4096 items FftDisplayPlot displaying: 4096 items ERROR: READ LINE: -9 ERROR: READ INTEGER: -9 E20210609 18:32:34.412138 140574 buffer.cpp:479] Buffer: Cannot refill RX buffer

This is a failed Spectrum analyzer shot with a 8192 size buffer

gr::buffer::allocate_buffer: warning: tried to allocate 4 items of size 40000. Due to alignment requirements 64 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. gr::buffer::allocate_buffer: warning: tried to allocate 4 items of size 40000. Due to alignment requirements 64 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes.

I will post the results of your second question separately

ForthDude commented 3 years ago

sorry for the bold font in my last post, it must have copied from the terminal.

Your Oscilloscope setup looks like this here: Scopy_Scope_test

When I ran the setup for he first time I think it did not show data on the FFT panel. But now it does all the time.

After playing for a while the oscilloscope does not show any data any more and I get in the console:

sched: <block stream_to_vector_overlap (657)> is requesting more input data than we can provide. ninput_items_required = 32768 max_possible_items_available = 16383 If this is a filter, consider reducing the number of taps. scope_sink_f processing index: 8192 ERROR: WRITE ALL: -9 E20210609 18:53:24.101012 1698560 buffer.cpp:479] Buffer: Cannot refill RX buffer gr::buffer::allocate_buffer: warning: tried to allocate 4 items of size 40000. Due to alignment requirements 64 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. gr::buffer::allocate_buffer: warning: tried to allocate 4 items of size 40000. Due to alignment requirements 64 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes.

sched: <block stream_to_vector_overlap (657)> is requesting more input data than we can provide. ninput_items_required = 32768 max_possible_items_available = 16383 If this is a filter, consider reducing the number of taps.

sched: <block stream_to_vector_overlap (651)> is requesting more input data than we can provide. ninput_items_required = 32768 max_possible_items_available = 16383 If this is a filter, consider reducing the number of taps. scope_sink_f processing index: 8192 ERROR: WRITE ALL: -9 E20210609 18:53:27.277344 1704276 buffer.cpp:479] Buffer: Cannot refill RX buffer QProcess: Destroyed while process ("/app/bin/iio-emu") is still running.

AlexandraTrifan commented 3 years ago

Hi,

Thank you for all the info you provided, it has been helpful. We think we might have caught the issue here : https://github.com/analogdevicesinc/scopy/actions/runs/925058193 . Could you run some of the tests again and let us know whether this changes anything (both on Spectrum and Osc) ?

If you still encounter issues with this version (hopefully not) we prepared another build which might help to narrow things down: https://github.com/analogdevicesinc/scopy/actions/runs/924345181 .

Thank you! -Alexandra

sja1440 commented 3 years ago

Hello Adrian and Alexandra

I am now back home and I have collected the information that you both requested.

Hardware is a custom workstation built more than 10 years ago around an Intel® Core™ i5 CPU 760 @ 2.80GHz × 4 with 16 GiB of RAM. I do not do any overclocking.

Here is the output from lscpu:

Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   36 bits physical, 48 bits virtual
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           30
Model name:                      Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz
Stepping:                        5
Frequency boost:                 enabled
CPU MHz:                         1348.166
CPU max MHz:                     2801.0000
CPU min MHz:                     1200.0000
BogoMIPS:                        5617.54
Virtualisation:                  VT-x
L1d cache:                       128 KiB
L1i cache:                       128 KiB
L2 cache:                        1 MiB
L3 cache:                        8 MiB
NUMA node0 CPU(s):               0-3
Vulnerability Itlb multihit:     KVM: Mitigation: VMX disabled
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled
Vulnerability Mds:               Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 
                                 ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid
                                  aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm pti
                                  ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid dtherm ida flush_l1d

I have also verified that the latest applicable version of the intel microcode for my CPU has been earlyloaded correctly. [ 0.000000] microcode: microcode updated early to revision 0xa, date = 2018-05-08

I was writing up my results from testing Alexandra's scopy build (https://github.com/analogdevicesinc/scopy/actions/runs/921871291) when I noticed that Alexandra has just made a new build available https://github.com/analogdevicesinc/scopy/actions/runs/925058193.

I have tried this new flatpak (https://github.com/analogdevicesinc/scopy/actions/runs/925058193) which is an improvement - I can now Spectrum Analyze successfully at 8192 but alas I cannot at any larger size.

I will now try the other build https://github.com/analogdevicesinc/scopy/actions/runs/924345181 and publish my results

sja1440 commented 3 years ago

I have now carried out the tests with Alexandra's flatpak at https://github.com/analogdevicesinc/scopy/actions/runs/924345181.

Tests used demo mode with the signal generator producing a 100kHz sine wave and Spectrum Analyzer using a sweep 0 Hz to 1MHz

Here are the journal log entries with Spectrum Analyzer running successfully with "dBFS Sample:100.00 % / 8192" AlexandraBuild20210610b_8192_Start_withStop.txt. Please ignore the log entries prior to Jun 10 15:49:49 in since they were part of a 16384 test.

Here are the journal log entries with Spectrum Analyzer running failing with "dBFS Sample:100.00 % / 16384" AlexandraBuild20210610b_16384_Start_withStop.txt

Please let me know if you need further information.

sja1440 commented 3 years ago

I have noticed something about the successful 8192 test log that I published before. I have now rerun the test as follows:

I see the following entries which refer to 16384 which seems strange given that the spectrum analyzer is running at "dBFS Sample:100.00 % / 8192"

Jun 10 16:24:43 DIRAC org.adi.Scopy.desktop[4191737]: sched: <block stream_to_vector (56)> is requesting more input data
Jun 10 16:24:43 DIRAC org.adi.Scopy.desktop[4191737]:   than we can provide.
Jun 10 16:24:43 DIRAC org.adi.Scopy.desktop[4191737]:   ninput_items_required = 16384
Jun 10 16:24:43 DIRAC org.adi.Scopy.desktop[4191737]:   max_possible_items_available = 16383
Jun 10 16:24:43 DIRAC org.adi.Scopy.desktop[4191737]:   If this is a filter, consider reducing the number of taps.
AlexandraTrifan commented 3 years ago

Thank you for the detailed info, we are investigating further.

-Alexandra

AlexandraTrifan commented 3 years ago

Hi,

  1. When I run flatpak v1.20 of Scopy on my Ubuntu 20.04 PC I experience problems similar to the previous posters: Spectrum Analyzer does not work.

This is from a previous comment. In order to fix this, a couple of months ago, a build flag was added to libgmp(a dependency). I prepared the following build which modifies that flag: https://github.com/analogdevicesinc/scopy/actions/runs/928735354 Could you try this one? I would be interested to know if changing the build flag triggers the "crash" issue again. If not, I would like to know if it fixes the issue of 8192 (or more) samples not being displayed on the plot.

  1. Some other changes that I tried to implement are available in the following build - https://github.com/analogdevicesinc/scopy/actions/runs/928600538 .

  2. If none of the above options provide any change, I would need the output of the successful flatpak build that @ForthDude mentioned in an earlier commit. This would really help to check the configuration for all the dependencies of Scopy.

These warnings are not related to the Spectrum Analyzer, we know their origin and they don't have any influence over the current issue. ERROR: WRITE ALL: -9 E20210609 18:53:24.101012 1698560 buffer.cpp:479] Buffer: Cannot refill RX buffer gr::buffer::allocate_buffer: warning: tried to allocate 4 items of size 40000. Due to alignment requirements 64 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes.

Thank you! -Alexandra