Connect to phone

See this video: https://www.youtube.com/watch?v=W_o8sOZHoeE for a demonstration.

3 Likes

@adim - Adrian,

GREAT video…!!

Did you compile the qradiolink app for Android from the source code (appears to be a Samsung phone with an OTG cable for the LimeSDR), or is there an Android app available? I checked the Google PlayStore for ‘qradiolink’ and came up with no matches. Please let us all know how this app was compiled for Android and if it’s available for download. I have a Lime-Mini now, too, and would like to see how well it works on my Galaxy Note 6.

Keep us all advised on this, Adrian - thanks es 73,

de Marty, KN0CK

Hi Marty,

What you’re seeing there is the application running in a Linux environment (chroot) under the Android OS. It is not native to Android but runs just as well since it is not emulated. There are several methods to have a chroot, pick the one you like the best, but I recommend the Debian way: https://wiki.debian.org/ChrootOnAndroid

The phone is a Motorola MotoG 3rd gen, so quite an old phone with 840 MB memory and 1.2 GHz quad-core CPU. My application uses about 33% of the CPU while idle receiving and the whole Linux chroot uses 180 MB of RAM.

The application is free-software released under GNU GPLv3, see http://qradiolink.org for details and links to code. You should have no issues compiling for ARM under Debian Jessie or Stretch (or in fact any other derivate distros). You can either cross-compile on the host computer or directly on the phone (but will take longer). If you want to help you can try setting up a Travis build to provide binary packages for ARM HL architecture :slight_smile:

At some point I plan to release a ready made SD card image with the full GNUradio environment preinstalled, to be plug-n-play.
Oh, and the demo does not contain any reference to video transmission because frankly with the bad lighting and the small size of the screen nothing would have been visible.

Best,
Adrian YO8RZZ

2 Likes

Hi @adim
hope you’re still around. Which of these requirements has to be met to build it from source on armhf?

So far I have installed Ubuntu Xenial through chroot (with VNC support), and loaded soapysdr+limesuite.

Hi,
If you have a Linux chroot, the process is the same as if you were building on x86. Install gnuradio and gnuradio-dev, install gr-osmosdr (you may have to build it from source to have soapy support).
The rest of the packages are described in the readme. I noticed the Ubuntu instructions are missing libspeexdsp-dev though. I will add both libspeexdsp and libspeexdsp-dev as the guide was written before I added the dependency. You have to be careful with Qt. The Qt version you use to build qradiolink should be the same as the Qt version used by GNU radio.

Regards,
Adrian

Hi,
thanks for the help so far. I’m stuck on protocol buffer. I found binaries for x86 and x86_64, but not armhf or arm64 for both protoc and protobuf.
Any way around it (possibly without crosscompiling)?
Also I can’t find libspeexdsp and libspeexdsp-dev in artful repo.

W.

Okay, now it seems all dependencies have been fulfilled (including protobuf and protoc).
libspeexdsp and libspeexdsp-dev installed and still getting this error on ‘make’

g++ -c -pipe -O2 -D_REENTRANT -Wall -W -DQT_NO_DEBUG -DQT_SQL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I…/…/qradiolink -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtSql -I/usr/include/qt4 -I/usr/include/qwt-qt4 -I/usr/include/qwt -I. -I. -I…/…/qradiolink -I. -o main.o …/main.cpp
In file included from /usr/include/c++/5/mutex:35:0,
from /usr/local/include/google/protobuf/stubs/mutex.h:33,
from /usr/local/include/google/protobuf/stubs/common.h:52,
from …/ext/Mumble.pb.h:9,
from …/mumbleclient.h:29,
from …/mainwindow.h:28,
from …/main.cpp:17:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support
^
In file included from /usr/local/include/google/protobuf/stubs/common.h:52:0,
from …/ext/Mumble.pb.h:9,
from …/mumbleclient.h:29,
from …/mainwindow.h:28,
from …/main.cpp:17:
/usr/local/include/google/protobuf/stubs/mutex.h:70:8: error: ‘mutex’ in namespace ‘std’ does not name a type
std::mutex mu_;
^
/usr/local/include/google/protobuf/stubs/mutex.h: In member function ‘void google::protobuf::internal::WrappedMutex::Lock()’:
/usr/local/include/google/protobuf/stubs/mutex.h:63:43: error: ‘mu_’ was not declared in this scope
void Lock() GOOGLE_PROTOBUF_ACQUIRE() { mu_.lock(); }
^
/usr/local/include/google/protobuf/stubs/mutex.h: In member function ‘void google::protobuf::internal::WrappedMutex::Unlock()’:
/usr/local/include/google/protobuf/stubs/mutex.h:64:45: error: ‘mu_’ was not declared in this scope
void Unlock() GOOGLE_PROTOBUF_RELEASE() { mu_.unlock(); }
^
/usr/local/include/google/protobuf/stubs/mutex.h: At global scope:
/usr/local/include/google/protobuf/stubs/mutex.h:73:7: error: expected nested-name-specifier before ‘Mutex’
using Mutex = WrappedMutex;
^
/usr/local/include/google/protobuf/stubs/mutex.h:78:28: error: expected ‘)’ before ‘*’ token
explicit MutexLock(Mutex *mu) : mu_(mu) { this->mu_->Lock(); }
^
/usr/local/include/google/protobuf/stubs/mutex.h:81:3: error: ‘Mutex’ does not name a type
Mutex const mu_;
^
/usr/local/include/google/protobuf/stubs/mutex.h: In destructor ‘google::protobuf::internal::MutexLock::~MutexLock()’:
/usr/local/include/google/protobuf/stubs/mutex.h:79:24: error: ‘class google::protobuf::internal::MutexLock’ has no member named ‘mu_’
~MutexLock() { this->mu_->Unlock(); }
^
/usr/local/include/google/protobuf/stubs/mutex.h: At global scope:
/usr/local/include/google/protobuf/stubs/mutex.h:92:33: error: expected ‘)’ before '
’ token
explicit MutexLockMaybe(Mutex *mu) :
^
In file included from /usr/local/include/google/protobuf/arena.h:48:0,
from …/ext/Mumble.pb.h:23,
from …/mumbleclient.h:29,
from …/mainwindow.h:28,
from …/main.cpp:17:
/usr/include/c++/5/typeinfo:39:37: error: expected ‘}’ before end of line
/usr/include/c++/5/typeinfo:39:37: error: expected unqualified-id before end of line
/usr/include/c++/5/typeinfo:39:37: error: expected ‘}’ before end of line
/usr/include/c++/5/typeinfo:39:37: error: expected ‘}’ before end of line
/usr/include/c++/5/typeinfo:39:37: error: expected ‘}’ before end of line
/usr/include/c++/5/typeinfo:39:37: error: expected declaration before end of line
Makefile:728: recipe for target ‘main.o’ failed
make: *** [main.o] Error 1

@wqcr,

…And there’s my effort to put the Lime-Mini on a rooted LG G3 smartphone using Ubuntu Xenial and SDRAngel, too:

73 de Marty, KN0CK

3 Likes

@wqcr,

…And this post on the forum, too:

73 de Marty, KN0CK

That’s great, but I found SDRAngel quite unstable for transmitting wide band modes. It’s prone to dropping samples, also it’s not possible to tune below 30MHz.
QRadioLink also has slightly better UI in terms of working on a touch screen.

Further I’d appreciate help in the sense how to make it work rather than it’s possible, check out this demo.
I don’t mind sharing the disk img once I successfully run QRadiolink with Mini, for that however, the issue above has to be tackled.

One step forward but still not there.
The previous issue was solved by adding -std=gnu++11 to CXXFLAGS in Makefile.
But now getting this error (and lots of others with the same ‘undefined reference’:

mumbleclient.o: In function MumbleClient::authenticate()': mumbleclient.cpp:(.text+0x2d4e): undefined reference togoogle::protobuf::internal::fixed_address_empty_string[abi:cxx11]’
mumbleclient.cpp:(.text+0x2d52): undefined reference to google::protobuf::internal::fixed_address_empty_string[abi:cxx11]' mumbleclient.o: In functionMumbleClient::sendVersion()’:
mumbleclient.cpp:(.text+0x30be): undefined reference to google::protobuf::internal::fixed_address_empty_string[abi:cxx11]' mumbleclient.cpp:(.text+0x30c2): undefined reference togoogle::protobuf::internal::fixed_address_empty_string[abi:cxx11]’
mumbleclient.o: In function MumbleClient::createChannel(QString)': mumbleclient.cpp:(.text+0x3da2): undefined reference togoogle::protobuf::internal::fixed_address_empty_string[abi:cxx11]’
mumbleclient.o:mumbleclient.cpp:(.text+0x3da6): more undefined references to `google::protobuf::internal::fixed_address_empty_string[abi:cxx11]’ follow

Edit: This was fixed by adding SUBLIBS = -L/usr/local/lib to Makefile

OK, finally the compilation is done, however the UI is broken and now getting these errors:

Xlib: extension “XInputExtension” missing on display “:0.0”.
“11/Jul/2018 20:04:55”
QColor::setRgb: RGB parameters out of range
warning: The VAD has been replaced by a hack pending a complete rewrite
…/audio/audiointerface.cpp: pa_simple_new() failed:
…/audio/audiointerface.cpp: pa_simple_new() failed:
QNativeImage: Unable to attach to shared memory segment.
X Error: BadPixmap (invalid Pixmap parameter) 4
Major opcode: 56 (X_ChangeGC)
Resource id: 0x0
X Error: BadPixmap (invalid Pixmap parameter) 4
Major opcode: 56 (X_ChangeGC)
Resource id: 0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
Major opcode: 62 (X_CopyArea)
Resource id: 0x0
QNativeImage: Unable to attach to shared memory segment.
X Error: BadPixmap (invalid Pixmap parameter) 4
Major opcode: 56 (X_ChangeGC)
Resource id: 0x0
X Error: BadPixmap (invalid Pixmap parameter) 4
Major opcode: 56 (X_ChangeGC)
Resource id: 0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
Major opcode: 62 (X_CopyArea)
Resource id: 0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
Major opcode: 62 (X_CopyArea)
Resource id: 0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
Major opcode: 62 (X_CopyArea)
Resource id: 0x0
X Error: BadPixmap (invalid Pixmap parameter) 4
Major opcode: 56 (X_ChangeGC)
Resource id: 0x0
X Error: BadPixmap (invalid Pixmap parameter) 4
Major opcode: 56 (X_ChangeGC)
Resource id: 0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
Major opcode: 62 (X_CopyArea)
Resource id: 0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
Major opcode: 62 (X_CopyArea)
Resource id: 0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
Major opcode: 62 (X_CopyArea)
Resource id: 0x0

Hi, and sorry for the delay.

…/audio/audiointerface.cpp: pa_simple_new() failed:
…/audio/audiointerface.cpp: pa_simple_new() failed:

The means that Pulseaudio is not running, or that the client cannot connect to the server. You need to have Pulseaudio because Alsa support is not fully implemented.
The other errors point out to a problem with the X server configuration. Try to use the VNC output first. The Linux Deploy application can configure the SD card image automatically to use VNC. Then use something like AndroidVNC to view the Linux desktop. It’s not a simple operation, but after you have the VNC desktop, you can look at the X-server variant.

Regards,
Adrian

1 Like

Yes, I used VNC in the above instance (both from remote PC and from the phone - VNCViewer).
Unfortunately the above build failed to start, so I have to do it over again.

This is the interface:

Finally, fixed it.
This line has to be added to /etc/environment:
QT_X11_NO_MITSHM=1

Now comes the hardest part - get audio/mic working and Mini recognized…

No luck getting the Mini recognized so far, at least RTL-SDR worked.
Also getting no audio from the chrooted environment.
Found this : https://github.com/meefik/linuxdeploy/issues/223
and made a bash script to send these

amixer cset numid=1149,iface=MIXER,name=‘LINE_OUT’ 1
amixer cset numid=941,iface=MIXER,name=‘PRI_MI2S_RX Audio Mixer MultiMedia1’ 1
amixer cset numid=1142,iface=MIXER,name=‘RX3 MIX1 INP1’ 1

to enable sound device, however that applies to alsa, in pulse audio I’m still getting only dummy in/out.

@wqcr,

From all my experimentation with a Linux environment running from a rooted smartphone, the rooted environment exists on a shell of the Android OS (kind of like VirtualBox or the like) and the audio stream in that Linux environment is UDP packets unless you can route it out some other way…It takes a UDP player on the Android side that can connect to the UDP port on the Linux side to allow the audio packets to stream to the Android side so they can be processed and played…That was my deterrent (in January) since SDRAngel (at the time) didn’t have provisions to stream the audio out in UDP packets…Since then that’s been fixed and it’s possible to get audio out of the Linux side of a rooted smartphone…Just so you’re aware…I haven’t had time to play with it since January because SDRAngel didn’t apply that fix until May or so - so that’s on my ‘to-do’ list but the issue is still there until I pull down the latest SDRAngel, compile it and then connect up the audio using a UDP player on the Android side…

73 de Marty, KN0CK

If I can see the device being opened and closed on that Linux environment, it means I can theoretically send PCM data straight to it, without going circles using protoplayer, UDP player or pulsedroid.
And this is what I see after running alsactl monitor and playing back something on android - the above devices opening and on a time-out closing.
The thing is, pulseaudio works in a different manner to alsa, so I’m not sure how to make the device visible there.

The Pulseaudio server can run in the chroot, but you have to disable the Android sound system, because it will try to keep the audio device open and either Android or Pulseaudio will crash.
To disable the Android audio system temporarily, this resource might be useful to you:

The mixer_paths.xml also contains the paths you need to enable before having sound in Pulseaudio. You can use tinymix to do that from the chroot. If you rename this file and then make a new copy disabling the active paths, Linux audio will no longer have a conflict. I’ll try to attach the tinymix settings I used, but they might be different between phones, so you should look into your Android config as well.