I know I’ve seen lots of projects about making cell phone networks with the LimeSDR, but has anyone tried connecting a LimeSDR to a phone? From what I’ve been seeing from connecting to RPis and similar boards, it sounds like it would work, but has anyone tried using smartphones? (If it used thunderbolt, I bet you’d just need a converter to USB 3). I guess with the LimeSDR mini and a phone, you could probably even make the ultimate HT.
Yes. QRadioLink ( http://qradiolink.org ) works with a mobile phone and the LimeSDR-mini. I will make a video demonstration of an analog/digital transceiver as soon as some TX issues are solved in the software.
3 Likes
Thanks, I’m kind of wanting to see if I can get my LimeSDR (or future LimeSDR-mini) to talk to a nearby FaradayRF, at around 915 MHz, while using my phone. I’m betting it’d also make a really useful AMSAT Phase 4-B GS node (with proper up/down converters), if it were on a phone too, although I have no idea if even a Qualcomm Snapdragon 835 would have enough processing power for that.
@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 
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
…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
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.
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.
