Gqrx for limeSDR on RPI3

Projects LimeSDR
43

Yesterday I installed OpenSUSE for ARM 64 on a RPi3 and that makes the hell of a difference with the RPi3 on Raspbian. So the move from armv7 to armv8 architecture represents a huge gap. The Raspbian one simply cannot work at a sample rate of 3 MS/s on the HackRF while the OpenSUSE one rocks. The Ethernet/USB sharing might still be an issue but probably at larger sample rates.

44

Can you test with opensuse on your armv7 raspbian?

45

Well… this doesn’t make any sense: you have either openSUSE or Raspbian. Did you mean the armv7 release of openSUSE? I am not sure this even exists for RPi3.

I did another test with cm256cc: https://github.com/f4exb/cm256cc which is a Cauchy MDS block erasure codec library and has a test program recording the elapsed time for encoding and decoding. For both operations the RPi3 on Raspbian consistently takes twice the time compared to the RPi3 on openSUSE.

46

You say:

[quote]
So the move from armv7 to armv8 architecture represents a huge gap. [/quote]

I guess the confusion for me is around raspbian.

  • Is it not built for armv8?
  • And RPi3 is armv8?
  • And opensuse is built with the flags for armv8?

My thoughts jumped to “What difference caused the performance gains you mentioned?”.

47

OK I think I got your point. In fact the RPi3 is capable of handling both armv7 and armv8 instructions. Raspbian at present is built with armv7 instructions while openSUSE is built with armv8 instructions. This is why the RPi3 will not run with the same set of instructions in both distributions. The one with armv8 (openSUSE) has a clear advantage on the other (Raspbian) because armv8 instructions are more advanced and optimized. The new instruction set is more important that the move to 64 bit architecture I think.

There is a really long thread about the pros and cons of upgrading to armv8 for Raspbian on Rpi3: https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=138385

True to say that with a 64 bit instruction set the programs take more space in memory and 1 GB is therefore a little bit small. However it will still fit a lot of situations.

1 Like
48

I think it may be even worse than armv7 vs armv8. It seems Raspbian is running armv6 instructions. See: http://www.cnx-software.com/2016/03/01/64-bit-arm-aarch64-instructions-boost-performance-by-15-to-30-compared-to-32-bit-arm-aarch32-instructions/

49

Funny you mention that because I was going to point out that often cross-compiles are done to armv6. Then later ARMs can run that code. Yes not optimal but it works. It’s a generic one-size-fits-all solution which are often not optimal.

The best thing to do is to do a canadian-cross*. Many linux distros are built generically with a one-size-fits-all approach. So do your self a favor and setup a canadian-cross and build your own version of whatever distro has what you need. That way the kernel and modules and all the apps will be built specifically for armv8.
(you probably know all this but think of the dear readers)

*

i.e. build the armv8 compiler on x86_64 and then build all the software with that newly compiled armv8 compiler (still on x86_64 BTW)

####Update:
@csete has already done exactly what I suggested above.
csete’s post above

50

You should use OpenSUSE, it has an 64bit version for the pi 3 and probably it’s compiled form armv8 (I don’t know for sure, but that only makes sense). Why would they make an Pi 3 build without being compiled for Armv8? And the performance increases that @F4EXB is talking about also suggest that’s running armv8, although I couldn’t find a reliable source confirming this.

51

openSUSE for RPi3 works great for a headless server (the JeOS version) however I just tried a XFCE version and apparently it has no hardware acceleration for OpenGL. So anything that uses OpenGL for rendering will work slowly or not at all.

52

That sounds like a GPU issue. What GPU on the RPi3? Is it one of those proprietary ones?

53

No, there are drivers for it. Probably they didn’t include the VideoCore 4 GPU in the kernel as the kernel was re-written.

54

Hi, I am new to this thread and not sure if it is the correct one to ask these questions but they seem to be related to many discussions here. I’m trying to access the LimeSDR from a Pi3. I have been unsuccessful in building and getting the SoapySDRUtil to work. It complains of “pure virtual method called… terminate called without an active exception” and then it aborts. However, I have built pyLMS7002M and have successfully accessed the LimeSDR using the basic python example. However I need to read I and Q and can’t find examples on how to do that other than with the C++ examples using the SoapySDR driver. I have seen several threads on building on the Pi3 and I have not been successful with the recommendations. I also read about a concern over speed.
My questions are:

  1. Does anyone know how to build SoapySDR on Raspbian Jesse? Does it work reliably?
  2. Do I need SoapySDR to read I and Q or can I use the pyLMS7002 python library?
  3. I am concerned about speed. I need to read sample I and Q at about 1 khz. Has anyone achieved this rate on a Pi3?

Rene

55

Rene,
If you scroll back in this thread to March 10, you will see the steps I used to install SoapySDR and LimeUtil on the RPi3. They both worked. I have since switched to using OpenSUSE, which is a 64 bit operating system, but if you are recording data at that low a BW, you may be okay with Raspian Jesse.

I have used the code available at https://github.com/rxseger/rx_tools, specifically rx_sdr (the source code is called rtl_sdr, reflecting its origins), to record I/Q data at 10 MHz; this has been with OpenSUSE; I have not tried it yet with my earlier Raspian installation, but it may work for you.
-rkb

56

Thanks Robert for your help. Your steps was one of the ones I tried. To be precise, I followed these steps:
pi@kleio ~ $ git clone https://github.com/pothosware/SoapySDR.git2
pi@kleio ~ $ cd SoapySDR/
pi@kleio ~/SoapySDR $ mkdir build
pi@kleio ~/SoapySDR $ cd build
pi@kleio ~/SoapySDR/build $ cmake …
pi@kleio ~/SoapySDR/build $ make -j4
pi@kleio ~/SoapySDR/build $ sudo make install
pi@kleio ~/SoapySDR/build $ sudo ldconfig
pi@kleio ~ $ SoapySDRUtil --find
and the result is
pi@raspberrypi:~/SoapySDR/build $ SoapySDRUtil --find
######################################################

Soapy SDR – the SDR abstraction library

######################################################

pure virtual method called
terminate called without an active exception
Aborted

Have you seen this problem during your experimentation? I suppose I could start over completely with a fresh build but I was hoping to avoid that long process.
Assuming I get it going, I will definitely explore the link that you provided for reading I and Q.
Rene

57

I have not seen the error message you report.

Try running “SoapySDRUtil -info” before running “SoapySDRUtil -find”; it should eventually say
“Available factories…lime, null, remote,” which verifies that it can find the LimeSDR libraries, which
you should have also installed (those other steps from March 10).

58

I only see the factories for lime and null - not remote.
So,I deleted my previous LimeSuite build and started over just to be sure I followed the correct steps. One odd thing about the make is that the compiler crashes if it isn’t explicitly told about the environment. Here is the error message:
pi@raspberrypi:~/LimeSuite/build $ make
Scanning dependencies of target LimeSuite
[ 0%] Building CXX object src/CMakeFiles/LimeSuite.dir/Logger.cpp.o
*** Error in `/usr/bin/c++’: double free or corruption (top): 0x01728188 ***
Aborted
src/CMakeFiles/LimeSuite.dir/build.make:62: recipe for target ‘src/CMakeFiles/LimeSuite.dir/Logger.cpp.o’ failed
make[2]: *** [src/CMakeFiles/LimeSuite.dir/Logger.cpp.o] Error 134
CMakeFiles/Makefile2:207: recipe for target ‘src/CMakeFiles/LimeSuite.dir/all’ failed
make[1]: *** [src/CMakeFiles/LimeSuite.dir/all] Error 2
Makefile:127: recipe for target ‘all’ failed
make: *** [all] Error 2

I traced it to a bug in the compiler (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70132) which has been fixed but not yet made its way into Debian and therefore Raspbian. The work around is to specify the architecture which I did with the line ’ set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} -mcpu=cortex-a53 -mfpu=neon-fp-armv8”)’ in CMakeLists.txt.
I commented out the offending line “add_definitions(-march=native -mfpmath=both)”.
Although I was able to build the library, I do get the problem with the pure virtual function not implement.
Have you seen this problem with building using the native flag? Perhaps I didn’t specify the architecture properly.

59

Since SoapySDR could see the lime factory, I have no idea what the “pure virtual method called” error means.

Also, I never saw any build issues or compiler errors and never changed any flags. I was using the Jessie Lite version of 2016-05-27 with updates and upgrades; perhaps there were some compiler differences.

Recall that Raspian runs thearmv8 cpu on the RPi3 in armv7 (or, according to some, perhaps even armv6) emulation mode, so I am not sure about setting flags for armv8.

60

Is it possible for you to run the following command to get the environment from the compiler?
pi@raspberrypi:~/LimeSuite/build $ gcc -mcpu=native -march=native -Q --help=target
*** Error in `gcc’: double free or corruption (top): 0x01e5dc18 ***
Aborted

As shown above, my gcc version 4.9.2 for Raspbian aborts. What version of gcc are you running?

61

Unfortunately I have had to give up on this for now. I think it has something to do with 64 bit vs 32 bit because the compiler points out a number of warning with type sizes (i.e. expects 32 bit but is 64 bit). As we all know, these often lead to crashes in printf or sprintf statements and so I would have to go through the code and fix these problems to be sure. Each compile requires a couple of hours on the Pi3 so I’m going to prototype on a 64-bit Ubuntu 16.04 until I get the time to experiment with the Pi3 some more. However, if you get a moment, I am still curious which version of the compiler you are using which doesn’t complain about the default “native” architecture since there are lots of blogs on this problem and yet you did not see it.

62

$ gcc -dumpversion
4.9.2

$ gcc -mcpu=native -march=native -Q --help=target
*** Error in `gcc’: double free or corruption (top): 0x0115dc18 ***