Listen to live FM broadcasts on devices that don't have a built-in FM radio!
Description
SDR Touch turns your mobile phone or tablet into a cheap and portable software defined radio scanner. Allows you to listen to live on air FM radio stations, weather reports, police, fire department and emergency stations, taxi traffic, airplane communications, audio of analogue TV broadcasts, audio amateurs, digital broadcasts and many more! Depending on the hardware used, its radio frequency coverage could span between 50 MHz and 2.2 GHz. It currently demodulates WFM, AM, NFM, USB, LSB, DSB, CWU and CLW signals.
You can get a compatible USB receiver for under $20 online from eBay. Just plug in your rtl-sdr compatible USB DVB-T tuner into your Android device using a USB OTG Cable and turn on SDR Touch. For list of supported Realtek RTL2832U based dongles, please see the end of the description.
Compatible USB DVB-T tuners
- Generic RTL2832U (e.g. hama nano)
- ezcap USB 2.0 DVB-T/DAB/FM dongle
- Terratec Cinergy T Stick Black (rev 1)
- Terratec NOXON DAB/DAB+ USB dongle (rev 1)
- Terratec Cinergy T Stick RC (Rev.3)
- Terratec T Stick PLUS
- Terratec NOXON DAB/DAB+ USB dongle (rev 2)
- PixelView PV-DT235U(RN)
- Compro Videomate U620F
- Compro Videomate U650F
- Compro Videomate U680F
- Sweex DVB-T USB
- GTek T803
- Lifeview LV5TDeluxe
- MyGica TD312
- PROlectrix DV107669
- Zaapa ZT-MINDVBZP
- Twintech UT-40
- Dexatek DK DVB-T Dongle (Logilink VG0002A)
- Dexatek DK DVB-T Dongle (MSI DigiVox mini II V3.0)
- Dexatek Technology Ltd. DK 5217 DVB-T Dongle
- MSI DigiVox Micro HD
- Genius TVGo DVB-T03 USB dongle (Ver. B)
- GIGABYTE GT-U7300
- DIKOM USB-DVBT HD
- Peak 102569AGPK
- SVEON STV20 DVB-T USB & FM
Interaction with battery savers
It turns out some manufacturers such as Huawei and Samsung have very aggressive power saving policies and force close background apps without notice. If the system decides to kill the RTL-SDR (or SdrPlay) driver while SDR Touch is running, the app will stop playing and become unresponsive eventually showing a "Disconnected unexpectedly" error message.
If you are experiencing this issue, the only solution that currently exists is to manually whitelist *both* the SDR driver app and SDR Touch in your phone's power saving settings to prevent the operating system from unexpectedly stopping the apps. More information and instructions on how to do this based on your particular phone make and model can be found on this website: dontkillmyapp.com
Feedback
An article about SDR Touch - Android Meets the RTL2832U from HamRadioScience
A user submitted video showing off advanced features of SDR Touch running on a mobile phone:
Any additional feature suggestions, comments or feedback will be much appreciated!
looking good sir looking good
Fantastic work. I am excited to see squelch on the list of improvements. Is there any chance that you will ever support a plugin architecture or P25 decoding? There is a decoder called DSD which can decode P25. Squelch+P25 would make it replace my scanner entirely. I would pay additional $$ for each of these features and it would still be more affordable and interesting than carrying around a scanner.
daniel_reetz said:
Fantastic work. I am excited to see squelch on the list of improvements. Is there any chance that you will ever support a plugin architecture or P25 decoding? There is a decoder called DSD which can decode P25. Squelch+P25 would make it replace my scanner entirely. I would pay additional $$ for each of these features and it would still be more affordable and interesting than carrying around a scanner.
Click to expand...
Click to collapse
Thanks for the support! Squelch is coming soon! I will look into P25 but we might need to work together on this - you may need to provide me some I/Q recorded samples - but I would say this would be a bit later since I just started my second semester and have some studying to do as well
P.S. Squelch is now on top of my TODO list
Although this seems to be a great app, I couldn't make it to work with Xperia Ray... ("no tuner found" error)
Anyone here had success with making it work on a Xperia phone?
martintzvetomirov said:
Thanks for the support! Squelch is coming soon! I will look into P25 but we might need to work together on this - you may need to provide me some I/Q recorded samples - but I would say this would be a bit later since I just started my second semester and have some studying to do as well
P.S. Squelch is now on top of my TODO list
Click to expand...
Click to collapse
Fanastic, thank you. I can't wait for squelch!
I'll supply whatever data/info you need to implement P25. I/Q samples are no problem. I understand completely that your time is limited and there is a larger audience to serve, but if you need resources, please let me know what you need and I'll see how I can help.
My account here is new, so I can't post links, but "DSD" and "radioreference wiki" will get you to the DSD source.
Amazing work! Well worth the $9.99USD pricetag. Gave you a nice review on the Google Market/Play Store as well.
FYI: Works wonderfully on an Acer A500 w/ Android 4.2.1.
SDR Touch has been removed by Google from Google Play! I will investigate the issue and will report back as soon as I have more information!!!
If somebody needs the latest version of SDR Touch, please download it from the attachment. Keep in mind that as soon as SDR Touch goes back to Android market you might need to reinstall it in order to get the latest updates!
Ok, just to make it clear for everybody that is concerned.
SDR Touch DOES NOT violate the GPL license!
SDR Touch is merely a client for - https://github.com/martinmarinov/rtl_tcp_andro-. rtl_tcp_andro is released under GPL2+. SDR Touch and rtl_tcp_andro are separate works in the sense of GPL. They are neither statically or dynamically linked and they are two separate executables that communicate over a TCP connection. rtl_tcp_andro is bundled with SDR Touch merely to help the user and with accordance to point 2. of GPL Terms and Conditions. You can think of SDR Tocuh as an "installer" of rtl_tcp_andro. It just launches rtl_tcp_andro with Runtime.exec("");. Furthermore SDR Touch could happily work without the bundled rtl_tcp_andro in network mode by connecting to a remote computer running either rtl_tcp_andro or the original rtl_tcp.
Therefore GPL is not violated. Saying that GPL is violated would be like saying that you can't listen to online radio with your proprietary music player because the radio is being streamed with a GPL based software.
A quote from GPL-3.0:
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Click to expand...
Click to collapse
Did you read that quote ?
... and which are NOT combined with it such as to form a larger program, in or on a volume of a storage or distribution medium ...
Click to expand...
Click to collapse
A single .APK _is_ a single distribution medium ... and they definitely _ARE_ combined to form a larger program. The "SDR Touch" .APK is the larger program, containing both your own code and the rtl_tcp_andro binary. That clause is meant for when you ship a CDRom with different stuff on it for example where they have no special relation ship. Here the relation ship and dependency is clear (even says so in the damn description of the app)
The problem is not with SDR Touch or the way it's a client for a rtl_tcp version, that's the right way to do it.
The problem is that both are distributed bundled.
SDR Touch and rtl_tcp_andro need to be two separate packages to be installed independently by the user.
There is also the requirement to make a written offer and include the full license terms when distributing rtl_tcp_andro, usual way is to include both the license in the .APK and also accessible to the user in the UI (menu often).
Cheers,
Sylvain
smunaut said:
Did you read that quote ?
Click to expand...
Click to collapse
But rtl_tcp_andro is a separate binary and the apk is just a container like a CD Rom. That's precisely the point. The binary classes of SDR Touch are separate entities in the apk file and are not linked to rtl_tcp_andro!. The GPL allows using an "installer" to install proprietary software as well as GPLed software in one go. The Android apk installer grabs the contents of the archive (which is like a rar archive) and unrars it ("installs") it onto the device. When the user is using the program, the two entities are still different and separate!
The license is linked in the Help section of SDR Touch. The thing that I haven't done is to put the license physically on the apk as well.
But that's a good point,
Thanks,
Martin
martintzvetomirov said:
But rtl_tcp_andro is a separate binary and the apk is just a container like a CD Rom. That's precisely the point. The binary classes of SDR Touch are separate entities in the apk file and are not linked to rtl_tcp_andro!. The GPL allows using an "installer" to install proprietary software as well as GPLed software in one go. The Android apk installer grabs the contents of the archive (which is like a rar archive) and unrars it ("installs") it onto the device. When the user is using the program, the two entities are still different and separate!
Click to expand...
Click to collapse
Mmm, first, I'm not sure the APK is uncompressed on the flash.
But you're missing the point that in this case it's a single "application", no matter what binaries it's composed of. It's not pulled independently (as a dependency or not) and via that "installer" you can't get it independently, it's just a single package, even presented as a single application to the user (aren't they both under the same 'title' in the "Application" tab of android ?)
So really, I don't see how you could consider this as not being a "whole" without, like I said, distribute it as two different packages (which would also allow other "users" to use the rtl_tcp_andro for eg) and give a undeniable separation between the two.
smunaut said:
Mmm, first, I'm not sure the APK is uncompressed on the flash.
But you're missing the point that in this case it's a single "application", no matter what binaries it's composed of. It's not pulled independently (as a dependency or not) and via that "installer" you can't get it independently, it's just a single package, even presented as a single application to the user (aren't they both under the same 'title' in the "Application" tab of android ?)
So really, I don't see how you could consider this as not being a "whole" without, like I said, distribute it as two different packages (which would also allow other "users" to use the rtl_tcp_andro for eg) and give a undeniable separation between the two.
Click to expand...
Click to collapse
Ok, I see your point and this looks like an option. I still can argue that they are separate but in order to prove that, as you say, I might split them into two packages.
Will see how things go, will keep you posted!
Like smunaut said, this definitely counts as a derivative work as they are being presented to the user as one cohesive application via the Play Store.
This is the same problem that SDR# had some time back, where they tried to distribute the GPL RTL-SDR with their proprietary UI. They thought that, since the UI only communicated with RTL-SDR and wasn't technically part of SDR#, they could include it; but that's not the case. (http://dangerousprototypes.com/2012/08/05/confusion-over-sdr-vs-opensdrsharp/)
The solution in this case will be the same as it was for SDR#: Either make the entire application GPL, or break rtl_tcp_andro into a completely separate package. Make sure that the description for the rtl_tcp_andro package clearly states its license, and make sure you link to the GitHub page for it so the source is clearly available. That should cover all the bases.
MS3FGX said:
Like smunaut said, this definitely counts as a derivative work as they are being presented to the user as one cohesive application via the Play Store.
This is the same problem that SDR# had some time back, where they tried to distribute the GPL RTL-SDR with their proprietary UI. They thought that, since the UI only communicated with RTL-SDR and wasn't technically part of SDR#, they could include it; but that's not the case. (http://dangerousprototypes.com/2012/08/05/confusion-over-sdr-vs-opensdrsharp/)
The solution in this case will be the same as it was for SDR#: Either make the entire application GPL, or break rtl_tcp_andro into a completely separate package. Make sure that the description for the rtl_tcp_andro package clearly states its license, and make sure you link to the GitHub page for it so the source is clearly available. That should cover all the bases.
Click to expand...
Click to collapse
Ok, this makes sense.
Actually this won't be a bad idea after all, I mean if there is a separate app "rtl_tcp_andro" that can do I/Q samples, this might help other developers write their own SDR based applications so therefore help the community.
I don't want to release the processing bit under GPL since it took me quite some time to optimize the algorithms to run on Android so I want to keep my work with this private and this is what Pro users are paying for but rtl_tcp_andro is in the public domain anyways, I will just wrap it around with an apk and release it under GPL.
Please add NetSDR support for RFSpare radios like NetSDR or SDR-IP.
I would pay 10x the Pro price for this! http://sourceforge.net/projects/cutesdr/ and http://cutesdr.svn.sourceforge.net/...face/sdrinterface.cpp?revision=36&view=markup will probably reveal how NetSDR format works.
stejc said:
Please add NetSDR support for RFSpare radios like NetSDR or SDR-IP.
I would pay 10x the Pro price for this! http://sourceforge.net/projects/cutesdr/ and http://cutesdr.svn.sourceforge.net/...face/sdrinterface.cpp?revision=36&view=markup will probably reveal how NetSDR format works.
Click to expand...
Click to collapse
I already have sever requests about this. I will keep this idea in the record. I will first need to make sure SDR Touch is working properly and implement the list of features in the first post.
Also, I was able to rapidly prototype so far but now I'm back in University and I am forced to slow down the development speed. So it may take some time.
Any chance to make the whole app Open Source? This would be a nice recognition of the hard work done by the rtl-sdr folks, and solve your packaging problem.
I have licensed APRSdroid (which btw. can modulate and demodulate Packet Radio using audio in/out) under the GPL, and I can not complain about people not getting the paid version from Google Play.
To the contrary, 80% of my users actually bought the app, and all without evil nag screens!
martintzvetomirov said:
Actually this won't be a bad idea after all, I mean if there is a separate app "rtl_tcp_andro" that can do I/Q samples, this might help other developers write their own SDR based applications so therefore help the community.
Click to expand...
Click to collapse
Absolutely. That is the idea behind the GPL in the first place, that other developers can benefit from improvements made to the code. Having a separate download for rtl_tcp_andro would definitely be a positive for the community, I could personally think of a couple interesting projects with it.
martintzvetomirov said:
I don't want to release the processing bit under GPL since it took me quite some time to optimize the algorithms to run on Android so I want to keep my work with this private and this is what Pro users are paying for but rtl_tcp_andro is in the public domain anyways, I will just wrap it around with an apk and release it under GPL.
Click to expand...
Click to collapse
Of course, it's your right to keep your own software closed source. I don't personally believe in keeping this kind of software closed, but it's your decision.
Though I would like to point out that this type of software is going to get paid downloads either way. The type of users you will attract with this kind of software are the same kinds of users who have no problem donating to open source projects. We aren't talking about some casual game here that just anyone will be downloading, this is an application developed for more technical users who have a pretty good idea of the amount of effort that goes into a project like this.
In any event, I'm glad to see you taking the proper steps to make sure your software is GPL compliant.
FUNcube Pro & FUNcube Pro Plus Support
Any chance FUNcube Pro & FUNcube Pro Plus Dongles Support can be added in the future.
So wanted to connect my XZ Premium to my 4K PC monitor, but got response from Sony that they disabled this feature...
Snapdragon 835 has Displayport functionality through the Type-C, anyone know how to enable it?
Don't expext Sony to unlock this feature anytime soon even though it would only take them a minute or two.
They have a history of bottlenecking their smartphones by removing special features with every new device.
Don't believe me? Then check out this list. And that's only the tip of the ice berg.
https://forum.xda-developers.com/xz...xz-premium-t3660441/post73724764#post73724764
You'd have to get in touch with the folks at Qualcomm and ask them directly.
Please let us know their response here in this thread.
Good luck.
In theory, it is also considered that not all mobile devices and OTG are supported, but in practice exists an option for the rooted phone to change in some system xml code files.
Something similar must be possible here as well.
TL;DR: Could you check with AIDA64 if your phone support Wi-Fi Aware and report the result here?
Hello everyone, I am trying to create a list of the Android devices compatible with Wi-Fi Aware.To this date, the Pixel 3/3XL and the Galaxy Note 10/10+ are the only certified smartphones for Wi-Fi Aware. Oddly enough, none of them actually advertise that they support it on their storage page.I discovered that some other devices, like the Pixel 2 or Xiaomi Mi 8 and Pocophone are compatible with this technology but do not advertise their compatibility as well.
In a nutshell, I have no way to know which phones are compatible without getting my hand on them.
For this, I would like to request you to check if your phone is compatible with this technology. You must have Android 8 or more to have support for Wi-Fi Aware. If you match this requirement, you can know if your phone support Wi-Fi Aware by using the application AIDA64, which provide multiple specifications of your phone. The information can be find in the Network page, in Wi-Fi category. It requires to have the Wi-Fi switched on in order to test the API access.
Whether your phone support or not the technology, please report the result here, alongside with your phone model.You can report the result the way you want, screenshot, text. I will then add your phone capability to this list (That I cannot link yet because of this forum restriction...)
I am currently especially focused on smartphone having Snapdragon 845 or Snapdragon 855 processors
The phone is supposed to support dual-frequency GNSS.
Can someone use GPSTest (https://play.google.com/store/apps/details?id=com.android.gpstest&hl=en&gl=US)
and show a screenshot that demonstrates that the phone can pick up both frequencies?
Attached screenshot, you can see L5 and E5a in use there.
Looks like the screenshot got lost in the mail ;-) But yet I can confirm that dual-frequency is supported.
B2a too
Dual-frequency GNSS works. Positioning in general seems to be quite fast and accurate outdoors, also in forests.
Unfortunately it does not record carrier phase data with GPSTest or other apps (only outputs zeroes), so post-processing (PPK or others) are not usable. Does anybody know whether a custom rom can help with that?
I've seen it couldn't output "Navigation Messages", is that what's missing ? The Mi 8 could do that though I think. Is it really worth doing post-processing with an Android phone though where you're going to be limited by the poor antenna ? What post-processing tools do you use ?
You're probably right about the antenna. I wanted to see how far you can get with this phone. For some of my applications it could be useful to have sub-meter or at least the best accuracy available.
I wanted to use https://jason.rokubun.cat/#!/
Thanks for the link, they do indeed mention Android Smartphones under https://jason.docs.rokubun.cat/examples/ and give instructions on how to log data with GNSS Logger (GNS Logger v3 keeps crashing on me, does it work for you ?). They don't mention Navigation Messages that the Mi 10 '(and all 765G devices) is not capable of but "measurements" should be ok. Did you activate the "Full GNSS measurements" in the Developer Options ?
PS - I tried to create an account on Jason but I'm not getting the confirmation email. I tried "forgot password" and got an email but it won't reset. Looks like the site might have a few issues !
GNSS Logger always crashed on my phone, too. I have successfully used "GNSS/IMU Logger" as well as "GPSTest" instead (I prefer the former but since the last MIUI update (12.1.3) it has some bugs). I have enabled "Full GNSS measurements" in the developer settings.
The site worked just fine for me. At first files from the GPSTest app were not readable by the engine but the developers changed this immediately. They have also been very fast and helpful with my problems so far so maybe try contacting them via mail.
Good to hear, so what phone were you using when you got your data processed by Jason ? I received the email so I'll give it a try with both GPSTest and GNSS Logger v2 with my Mi 10 Lite just in case.
EDIT : so the GPSTest recording was...empty so same problem as you it seems (or I did something wrong while recording) but the GNSS Logger file is 1.8MB and is currently processing but stuck on "Looking for closest CORS station" so I'm not sure what's going on.
Ah sorry, my message was unclear. I have produced valid rinex and raw log files with the Xiaomi Mi 10 Lite but the fields with the carrier phase data were empty. Jason then still processes the files but the output data are not helpful, with positions way worse than what a standard gpx recorder delivers.
Jason usually didn't take long with my files.
Gotcha, I opened the log with excel and the CarrierPhase fields are indeed empty. Is that why we get the " Could not set-up parameters for PPP processing: Cannot perform PPP on Rinex because SP3 orbits for 2021-01-21 16:00:17.429569 could not be found " message in Jason ? That sounds more like a CORS station problem but anyway it won't help with our problem.
The result was indeed poor, worse than what I was seeing on GPSTest actually but I think GPSTest shows the "Android Position", i.e. fused GPS/WiFI/4G
By the way, which rom are you using?
I don't use 4G or Wifi for positioning.
Stock ROM with Miui 11.0.4.0
I'll try turning off data to see what that does to the position. It might be using the accelerometers too to keep it steady.
About the empty CarrierPhase data fields I wonder if the data isn't being made available differently after reading the paper made available here : https://www.researchgate.net/public...g_Xiaomi_Mi_8_Dual-Frequency_Raw_Measurements
Where it says : " Not all available public methods in these two classes are actually in use or of interest for satellite-based positioning. In fact, some variables (e.g., ‘CarrierPhase’) have been deprecated starting from API version 28 [11]"
EDIT : ok, what we need is the "AccumulatedDeltaRangeMeters" and it is indeed shown as 0.0 on the Mi 10 Lite
Looking for some Mi 8 logs now, I'm pretty sure I've seen some somewhere !
See here for example:
https://www.kaggle.com/google/android-smartphones-high-accuracy-datasets
From the "awesome GNSS" list. You can also find a list of device capabilities there:
https://docs.google.com/spreadsheets/d/1jXtRCoEnnFNWj6_oFlVWflsf-b0jkfZpyhN-BXsv7uo/edit#gid=0
The Mi 10 Lite 5G is supposed to support carrier phase data /accumulatedDelta. It just seems like they are not calculated.
I'm sure you know the GPSTest group:
https://groups.google.com/g/gpstest_android
I'll leave the link for other interested people.
Yes I'm there too ;-) I just mentioned the GeolocPVT app, I managed to build it starting from the .aab, what a hassle ! Unfortunately it can't get a fix with the Mi 10, maybe because of the lacking ADR data ?
Talking of which I ran GNSS Logger v2 on a lowly Redmi 9 and...it logs ADR data ! I'll see if I can post-process some data with Jason.
Thanks for the links for the logs, the video presentation was interesting too. Do you know what the "Ground Truth Data" is ? A geodetic receiver getting RTK corrections maybe ?
I wonder if the Mi10 will ever get proper ADR data...have you had other Android phones that provide that data ?
Sorry, no. I didn't check with the Realme X2 Pro and now no longer have it.