Could I operate the LimeSDR from my Android device and run it? Pothos for 'Droid? LimeSuite? I may have missed this but I don’t remember anyone mentioning it or seeing it anywhere. If it is possible then the applications are, hmmmm, well, you choose an adjective.
I hate coding (I am dyslexic) but if I have to I will. More time I don’t have. Maybe not.
Cheers!
Sorry no driver for android i wish there is.
Power I would guess might be a major issue. As well as most phones only supporting USB 2.0. It is a bit like buying a jet engine and trying to hook it up to a tricycle. Can it be done, probably, if you turn everything down to the lowest possible setting, in which case an RTL-SDR might be superior. I do suspect you will need an additional external power source.
I took the external power source as granted. I was just thinking about a control head. RTL can’t transmit.
External power is not issue since you can plug one on the card but first make a driver for it then appz.
He posted that almost 2 years ago and nothing still happened even hackrf is not yet supported imagine limesdr.
Access on Linux systems is via libusb and I would suspect that when those cheap RTL-SDR USB dongles are used on Android that access is also via libusb.
LimeSDR hardware can also be accessed via the UHD API if you have a build of this installed that has loading modules enabled, together with SoapySDR and it’s UHD module, plus Lime Suite.
As noted the performance isn’t going to be great if you just had USB 2.0.
1 Like
Are there any instructions to build Lime Suite for Android? We can use gr-osmosdr with soapysdr, but it will need libraries from Lime Suite.
At present there are not as far as I know.
HackRF One is supported on Android devices. There is also an app that can be downloaded for replay attacks.
I don’t think that would be worth the trouble to port this to android, you would only get between 5MSPS and 10MSPS.
You may well be right. The HackRF with RF Analyzer, is limited to its circa 20 Mhz Bandwidth. Not quite the Spectrometer I wanted for discerning 5.8Ghz Analogue FPV signals at a Drone Racing Competition for traffic analysis and Frequency/Channel Assignment. Being ex-military, I really miss my toys. But my time with decent $100K+ Rhodes & Schwartz type equipment is sadly gone.
Who can afford a decent spectrum analyser that covers Mil HF to Mil K band or even C/X Bands.
I was not trying to be Narky when I mentioned the Android App for HF. I get the limitations of Bandwidth via USB. as well as computational power.
But lets remember, the LimeSDR has 2 x Rx and 2 x Tx. An Android phone has USB, and it also has probably Bluetooth, Wifi, and now days GSM LTE.
Most phones these days have 4/8 Cores and God only knows how many threads they support. There is more than one way to skin a cat. I just wish I had the coke bottle glasses of the guys who made the equipment I used to maintain and the abilitity to code.
When I asked too many questions on how some things worked during Cat School, one of my infamous Instructors used to sit there, look at me, and say “Tomo it just does it, its grass skirt ooga booga shit, just change out the OP Amp and be done with it” or words to that affect, on multiple occasions when I was trying to understand circuits of various Rx/Tx amongst other equipment.
They just never had the time to spend to train us to understand, it was more about if it breaks, what to swap out. 4 year courses in 11 months, not much time to sit down and have a latte over regulated power drawings.
There will be a way to have Android accept the LimeSDR. And with devices like the UDOO X86 / Latte Panda etc that will run Windows Linux and Android, who knows, maybe its a logical conclusion to a lot of mess. My Udoo X86 advanced plus has 3 x USB 3 ports. I bought it thinking about using it as the heart of a surveillance device, hook it up with Kali, a Wifi Pineapple, HackRF Ubertooth,and LimeSDR, and you have the makings of a portable comms sweeper / surveillance / penetration tester / penetration detector. The Lime SDR has everythign from what 300K to 3.8Ghz, (with some HF mods), the HackRF has everything from 1Mhz to 6 Ghz. Ubertooth has BLE in the bag, and 2.4Spectrum covered. Wifi Pineapple has 2.4 and if you have a Tetra 5.8GHz covered. If you can get a Yaesu 817/857/897 into the same box, all you need is the CAT/CI-V cables and antennas sorted out.
My vision anyway.
VK2WAR
2 Likes
I’m running my LimeSDR on a Win10 64-bit LattePanda (and the 7" LCD/Touchscreen) and it’s running perfect using SDRAngel. I see no reason why it wouldn’t work on that same board running Android or Linux, too…
73 de Marty, KN0CK
Awesome Marty, Id like to see Ham Radio Deluxe natively support SDRs a little better than having to use Virtual Cables or Networked Devices (in lieu of Cat Cabled radios). I miss DM780 and its full spectrum (pardon the pun) of digital modes. (I also miss my Yaesu FT-950 and Emtron D2SP and 40M). When your talking radios that utilise up to S & C bands 99.9% of that is going to be non voice, digital, and digital data. AM, NFM, WFM, LSB, USB isnt going to cut it. Raw and a good panadapter image might give you a hint of whats happening.
But even 160M to 23cm trying to figure out whats what is not exactly simple when you see the plethera of modes that HRD covers. Sure you can always record, throw it into Audacity and see if you can discern the binary and have a light bulb moment. Im not too sure I want to sit down for that long to figure out if its PSK31, HellSchrieber, or Base64 OOK with or without a parity bit and 10 to 1 at 3Ghz its not going to be.
Im not sure what the answer is. I certainly wish I could code. Im looking at a screen for my UDOO X86, it also takes arduino hats, so I might just be starting my career in coding using that. My Assembly Language days are long gone, but at least that made more sense to me than python does presently.
I wish you well and 73s de Tomo, VK2WAR
ANDROID UPDATE:
I’ve done a fair amount of research online and have installed the latest Android Studio 3.0 on my PC I use for development and I see some things that would obviously have to be remedied to make the LimeSDR compatible with Android, that being:
1.) LimeSuite (and any of its dependencies) would have to be compiled into libraries (<filename.so>) and then integrated into the environment that eventually builds the .APK. You use the Java Native Development Kit (NDK) to ‘compile’ the C++ code into the libraries that will be used to develop the final APK file.
2.) Functions that need to be exposed have to be defined in the Java Native Interface (JNI) and then REALLY called from the app’s Java ‘main’ such that the environment knows what library and exposed function - a pretty good example is shown here ----> https://developer.vuforia.com/forum/faq/android-how-can-i-call-c-methods-java
3.) It goes without saying too much that you have to rely on Android Studio’s ability to hook up the GUI to the app - trying to use QT or some other interface that’s leveraged in the reuse C++ code is a nonsrtarter. You’re better off just encapsulating all the functions, with exposure, as libraries in Android and just using the underlying code to the interface elements to make calls in and out of the compiled C++ libraries
4.) The core functions that keep the app running are no different in Android than they’d be as a compiled app in Linux or Windows - it’s just wrapped with the JNI to be compatible with the Android environment and be capable of interoperating with the higher level Java main. So a lot of what goes on happens in those libraries and is managed by the Android environment and its associated GUI.
There’s still a fair amount of research to do, but when I took the dive to get into this because what’s apparent at the get-go is that you can’t just compile or import a bunch of stuff from reused C++ from some other app and just jam it all into the Android Studio environment and make it build properly. There is a clear delineation to where the C++ ends (as a library) and where the Gradle picks up. but it’s totally possible to reuse C++ code that exists from LimeSuite, Soapy, etc and with enough massaging you can get it to work. Just look at SDRTouch for the RTL-SDR…That’s a perfect example of how they reused gr-osmo libraries in C++ to make that app play with some Android main and GUI code glued to it. Nobody put that together as a ‘straight-up’ Java app. So this isn’t impossible to do given that you’re creative enough to take what’s out there and re-purpose it as a shiny new Android app for the LimeSDR - - I’m gonna try and do it.
More to follow - stay tuned…
73 de Marty, KN0CK
2 Likes
Marty,
Qt5 works in Android with Ministro and is often much faster than the native Java widgets. It’s possible to port a Qt application easily and with minimal changes. The problem is weak userland.
1 Like
@adim - Adrian,
Thanks very much for the info…! That will help a lot for porting an app that exists for the Lime that uses the QT interface. I took a look at QT Creator app and it looks like it may be useful when this step has to be taken with the development of am Android app for the LimeSDR. More to follow on this as I have it - thanks again for the info…!
73 de Marty, KN0CK
1 Like
Just a few days ago there was a blog post about running QRadioLink on an Android smartphone in combination with the LimeSDR Mini. I haven’t tried it myself yet, but it seems they are using ChrootOnAndroid. This gives you the advantage of using known Linux tools instead of porting everything to a complete new platform (Google Android).
1 Like
Yes, I made the demo. You are correct regarding the chroot environment and it is indeed a lot more powerful than Android, including complete access to all GNU radio based apllications and native support for most SDR devices out of the box.
Feel free to ask any questions.