Related
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This application is made for enhancing or changing some feature for galaxy S
Requirement
1. machine
galaxy S (all variant)
2. version
Froyo (kernel 2.6.32.9)
3. rooted phone*
(*After checking "use with unrooted" option, you can remove rooting)
Feature
1. IO scheduler change
It can change CFQ(default) to deadline for some block device.
This change affect response time of disk IO.
(If you are using the application which handle many small files. You can feel better responsive reaction)
2. LCD color adjustment
(Test version)
This can be helpful to adjust so blue or yellow LCD.
3. Sound (3D, Hardware Equalizer)
It affect all system sound. so, If you change some parameter, all system sound(music, movie, radio..) will be affected.
How to test.
When you are hearing the music, As soon as changing the parameter, you hear different sound.
4. Memory Manager
Because It is controlled by kernel and android framework, It is more powerfull and efficient then memory killer.
for more info visit this link (thank to androcheck)
http://forum.xda-developers.com/showthread.php?t=622666
5. Over Clock (1.2Ghz)
OC feature is harmful to your phone. so, I put some restriction for preventing abuse.
(OC kernel user do not use this feature. I didn't consider OC kernel. and, I don't know about OC kernel)
6. Firmware(kernel) writing
you can write kernel(zImage) directly. and. can enter into recovery,download mode via this app.
7. use this app with unrooted
(Fort this. you must check "use with unrooted" option. before unrooting)
8. Bad block check (for ext filesystem)
If There are bad blocks on your ext filesystem. You can experience lag,abnormal app exit,slowness
9. key(Button) remaping Feature added
Volume Up,down key can be remapped to other key. (This is tested on M110S)
10. Touch gesture
It can map total 6 key button with Touch gesture.
11. Orientation Fix (especially Landscape mode)
It is helpful to view Landscape lying
How to download
search with this keyword on the market (galaxy tuner or d.w.kim)
Technical note
* LCD color and Sound function is accessing chipset resister directly.
* because, I don't have mDnie(LCD), wm8994(Sound) datasheet. I could not implement many feature.
* all system changing is volatile. so, If you reboot your phone. all system state is identical to original state
* OC function in this app change governor(performance, conservative..) policy. so, consider changing governor policy from like set cpu app
* running without rooting is a little tweak. It still require root privilege.
* more detail technical note
http://blog.naver.com/dowkim10/120122503306
* more about sound Howto
http://forum.xda-developers.com/showthread.php?t=921736
(Thanks to supercurio and studiominal)
Version note
1.3
The first version for all galaxy variant.
1.4
memory manager feature added
1.5
- color, sound (on boot adoption)
- memory manager (add some reinforced feature)
- bug fix for voodoo 5.2 patched kernel user (previous user must reboot once or reinstall for working)
1.6
OC (Over Clock 1.2Ghz) feature added
1.7
working on unrooted state.
1.8
Firamware(kernel) writing Feature added.
1.9
Bad block check(ext) Feature added
2.0
key(Button) remaping Feature added
fix bug (running Galaxy Tuner service at any time)
2.1
Orientation Fix (Feature added)
Sound (add option)
(it will clear user sound profile)
Memory Manager (Enhancement)
bug fix (on boot adoption is not worked sometimes)
2.2
Memory Manager (add VM control)
Key mapping( more button mapping added)
2.3
key mapping(Power key as Power+ headsetHook)
touch gesture feature added
Bug note
beta test version note
It is pre version for testing bug fix and add-on feature before releasing market
try attached file
Thanks dw kim. The app is amazing. I tried it with a couple of Mr Big songs. Is it like a parametric equaliser? Anyway, it's amazing how bassy it can achieve. The color temperature is great, I've always thought colours of my pictures were way too greenish, now I can adjust it to look more natural. Any way we can save it as boot settings?
Thank you very much.
I'm very happy It's working on your phone.
(You are first user except korean)
According to wm8993 manual(I don't have wm8994 manual). It is parametric equalizer.
It does not support on boot setting.
(but, I consider this function. I suggest you saving and loading user profile)
Haha, I am glad I am the first customer. Yes, the user profiles helps a lot.
Well, I think Supercurio, maker of Voodoo kernel, (maybe you already know him) has the Wolfson WM8994 manual? You could try ask him, he has a thread about sound here.
http://forum.xda-developers.com/showthread.php?t=806195
Btw, my phone is the international I9000.
Thanks a lot.
but, I don't have update plan right now, and I know him as very famous people.
so, I don't want to bother him.
No worries, dw kim, he's super helpful guy! Okay, relax, that app will make many ears happy already.
Btw, my favourite settings is +9, +6, +5, +7, +11. I think it's perfect. Using stock SGS earpiece.
It is too high gain.
How about extracting constant value on every band. and, volume up. (maybe same effect)
Too high value can make sound noisy
3d sound doesn't seem to work. o_0
one more thing: I'm using bluetooth A2DP.
stfudude said:
3d sound doesn't seem to work. o_0
one more thing: I'm using bluetooth A2DP.
Click to expand...
Click to collapse
This application access Sound chipset register directly. It is not software Equalizer.
If sound stream is transfered via bluetooth devcie. (without path of sound chipset)
you can not experience sound effect.
How about earphone or headphone ?
What is your phone model?
Great app!!!
Is there any posilibity to make it "autostart"...?
every time i reboot my phone I have to turn the settings on...
pandomu said:
Great app!!!
Is there any posilibity to make it "autostart"...?
every time i reboot my phone I have to turn the settings on...
Click to expand...
Click to collapse
I am considering. It is not difficult to implement.
(IO scheduler menu has this option)
but, I am afraid to add this option (LCD, Sound)
because, It handle hardware.
If There is no special case (after changing Sound, Phone is died)
I will add on boot option.
This application is not background application or service.
After setting a sound parameter, you can kill or remove from memory.
Just reporting that it works perfectly well with international GT-I9000 version.
For me, CFQ scheduler works best.
Thanks very much, i haven been waiting months for this
Hi Dowkim,
Thank you very very much. I have been waiting months for an application to adjust LCD color, but i had to either flash a kernel or accept that the camera stopped working. Your app works perfectly, thank you!
A suggestion: in the screen when adjusting color, you could add a colour testpattern so one can see the effect of the changed colors immediately.
Galaxy 9000 International Speedmod Rom
pwhooftman said:
Hi Dowkim,
Thank you very very much. I have been waiting months for an application to adjust LCD color, but i had to either flash a kernel or accept that the camera stopped working. Your app works perfectly, thank you!
A suggestion: in the screen when adjusting color, you could add a colour testpattern so one can see the effect of the changed colors immediately.
Galaxy 9000 International Speedmod Rom
Click to expand...
Click to collapse
Thanks. That is good idea.
I'll try. (but, I am poor at android programming)
dowkim10 said:
(but, I am poor at android programming)
Click to expand...
Click to collapse
I didn't notice for sure
Awsome work on this app. The music controls all work perfectly and make a huge difference in volume which i always thought was to low.
Hi dowkim10, this is interesting work.
I thought a lot about how to design the Voodoo sound driver and the consequences of the design chosen.
I took a different approach than yours: coding also a new driver, not as an independent .ko but using hooks in the actual source of the sound drivers to stay portable.
I believe a few limitations of the design you use are :
- It will be hard to add improvement like the microphone input auto-gain I prepare for the next version.
- Same thing for the FM radio bass solution
- Next to impossible for the upcoming audio jitter issue resolution
- Pretty hard and encumbered for adjusting other various input/ouptut gains/levels here and there
As kernel modules, like the scolor.ko and ssound.ko have a lot of power, in theory everything is possible but Galaxy S devices have so much different versions that implementing a module overriding some functions from the actual driver without breaking anything on a device or another will probably lead to very dirty code and headaches to maintain.
I thought of implementing everything using the wm8994_write dynamic register rewrite technique described here, also by inserting .ko modules like you do.
But here is what's in Voodoo sound source code:
https://github.com/project-voodoo/l...-voodoo/Kernel/sound/soc/codecs/wm8994.c#L215
https://github.com/project-voodoo/l.../Kernel/sound/soc/codecs/wm8994_voodoo.c#L270
By sniffing sequences of register address / value pairs, you should be able to recognize some patterns and add custom changes into it to extend your implementation.
But again, quite a dirty design
Good think of course it's the awesomeness of not requiring a custom kernel.
Of course my approach requires to publish every single piece of Kernel work as GPL and convince a lot of kernel developer to apply these patches, including eventually Samsung and Google.
But it's how I like it
As you distribute and insmod .ko modules, you're not forced to release source for them, but I advocate for Open Source.
Also, you will find a lot more code and ideas you will be able to re-use in the next Voodoo sound versions, about how to handle the parametric EQ and avoid saturation, and a lot of things like that.
Again, GPL will be a lot preferable.
bug report: mDNIe settings you use are lost after running Video player, Camera application (every app sending new mDNIe settings affecting the color response)
PS: don't be afraid to contact me, I am 70% of the time connected to IRC to discuss with and provide support to users and developers in real time.
dowkim10 said:
This application access Sound chipset register directly. It is not software Equalizer.
If sound stream is transfered via bluetooth devcie. (without path of sound chipset)
you can not experience sound effect.
How about earphone or headphone ?
What is your phone model?
Click to expand...
Click to collapse
International I9000
supercurio said:
Hi dowkim10, this is interesting work.
I thought a lot about how to design the Voodoo sound driver and the consequences of the design chosen.
I took a different approach than yours: coding also a new driver, not as an independent .ko but using hooks in the actual source of the sound drivers to stay portable.
I believe a few limitations of the design you use are :
- It will be hard to add improvement like the microphone input auto-gain I prepare for the next version.
- Same thing for the FM radio bass solution
- Next to impossible for the upcoming audio jitter issue resolution
- Pretty hard and encumbered for adjusting other various input/ouptut gains/levels here and there
As kernel modules, like the scolor.ko and ssound.ko have a lot of power, in theory everything is possible but Galaxy S devices have so much different versions that implementing a module overriding some functions from the actual driver without breaking anything on a device or another will probably lead to very dirty code and headaches to maintain.
I thought of implementing everything using the wm8994_write dynamic register rewrite technique described here, also by inserting .ko modules like you do.
But here is what's in Voodoo sound source code:
https://github.com/project-voodoo/l...-voodoo/Kernel/sound/soc/codecs/wm8994.c#L215
https://github.com/project-voodoo/l.../Kernel/sound/soc/codecs/wm8994_voodoo.c#L270
By sniffing sequences of register address / value pairs, you should be able to recognize some patterns and add custom changes into it to extend your implementation.
But again, quite a dirty design
Good think of course it's the awesomeness of not requiring a custom kernel.
Of course my approach requires to publish every single piece of Kernel work as GPL and convince a lot of kernel developer to apply these patches, including eventually Samsung and Google.
But it's how I like it
As you distribute and insmod .ko modules, you're not forced to release source for them, but I advocate for Open Source.
Also, you will find a lot more code and ideas you will be able to re-use in the next Voodoo sound versions, about how to handle the parametric EQ and avoid saturation, and a lot of things like that.
Again, GPL will be a lot preferable.
bug report: mDNIe settings you use are lost after running Video player, Camera application (every app sending new mDNIe settings affecting the color response)
PS: don't be afraid to contact me, I am 70% of the time connected to IRC to discuss with and provide support to users and developers in real time.
Click to expand...
Click to collapse
Hello supercurio
First, I am honored to meet you.
I know someone in korea said existence of this application. and, talked with you.
I also know you did very great job on galaxy kernel.
When I saw your sound code and mDnie code. I think you developed all passion and soul with many trial and error.
Absence of document maybe a excuse.
I have worked for ten years on embed linux. and treating many architecture(arm, ppc,mips,x86.) and treating kernel from 2.2 (now 2.6)
and, a few years ago, I ported android kernel to many board(arm v5,6,7 and xscale) and implemented HAL layer(GPS, alsa, bluetooth..) (android 1.0 around)
but, now I don't have relation Android in my job. so, I am doing this for my hobby. (I don't have enough time)
I know the risk of kernel module. wrong code or accessing bad address can cause system dieing.
but, basically, built-in and kernel module is same.
And, I didn't use your code. this module is treating only a few register.
Anyway, I am very nice to meet you. and many thanks for your advice.
( I hesitated to contact you. I'm a little shy)
If I keep my composure. I'll contact you via IRC.
Thank you.
dowkim10 said:
Hello supercurio
First, I am honored to meet you.
I know someone in korea said existence of this application. and, talked with you.
I also know you did very great job on galaxy kernel.
When I saw your sound code and mDnie code. I think you developed all passion and soul with many trial and error.
Absence of document maybe a excuse.
I have worked for ten years on embed linux. and treating many architecture(arm, ppc,mips,x86.) and treating kernel from 2.2 (now 2.6)
and, a few years ago, I ported android kernel to many board(arm v5,6,7 and xscale) and implemented HAL layer(GPS, alsa, bluetooth..) (android 1.0 around)
but, now I don't have relation Android in my job. so, I am doing this for my hobby. (I don't have enough time)
I know the risk of kernel module. wrong code or accessing bad address can cause system dieing.
but, basically, built-in and kernel module is same.
And, I didn't use your code. this module is treating only a few register.
Anyway, I am very nice to meet you. and many thanks for your advice.
( I hesitated to contact you. I'm a little shy)
If I keep my composure. I'll contact you via IRC.
Thank you.
Click to expand...
Click to collapse
Hi! be sure the honor is shared.
Thanks for your answer,
I see you not only speak Korean and English languages with ease but also I2C at least
Yes the absence of any sign of documentation about mDNIe forced to use the reverse-engineering approach ^^ as I had no experience in Kernel development a few months ago it was a lot of trial and error.
Now Samsung have given a little details in their new source code release about mDNIe controls, which is definitely a move in the right direction.
I'll try to get the doc for this chip.
I agree the first Voodoo sound implementation was crude, that's why I never activated and rewrote it from scratch for the release.
You're a much more experienced kernel and embedded developer than me!
Come on, don't be so shy, I'm just a rookie compared to you
See ya!
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.
On Linux one can run $sudo iwconfig to get details about the WiFi hardware. CM used to ship with iwconfig, but this has gone. I've built iwconfig from source in https://github.com/servalproject/batphone yet when I ran it on a couple of CM ROMs it doesn't give any info about the interface. The reason why I'm bothered about this is that in the past, I've seen Android phones showing 32dBm when queried via iwconfig txpower which is incredible: that's over 1W. Not only is it illegal but, possibly damaging for health, wasteful of battery and leaking my whereabouts further than is necessary. Pengus77 implemented a sys interface for the Kowalski kernel: https://github.com/pengus77/kowalski and I'd like to see this accessible via the WiFi advanced options.
dabl8 said:
On Linux one can run $sudo iwconfig to get details about the WiFi hardware. CM used to ship with iwconfig, but this has gone. I've built iwconfig from source in https://github.com/servalproject/batphone yet when I ran it on a couple of CM ROMs it doesn't give any info about the interface. The reason why I'm bothered about this is that in the past, I've seen Android phones showing 32dBm when queried via iwconfig txpower which is incredible: that's over 1W. Not only is it illegal but, possibly damaging for health, wasteful of battery and leaking my whereabouts further than is necessary. Pengus77 implemented a sys interface for the Kowalski kernel: https://github.com/pengus77/kowalski and I'd like to see this accessible via the WiFi advanced options.
Click to expand...
Click to collapse
Two possibilities:
1) Illegal, damaging for health/hardware, etc.
2) Since Android doesn't use that interface, the OEM who wrote the wifi driver didn't test the txpower interface and it returns bogus data and does nothing.
I'm leaning towards 2)
Entropy512 said:
Two possibilities:
1) Illegal, damaging for health/hardware, etc.
2) Since Android doesn't use that interface, the OEM who wrote the wifi driver didn't test the txpower interface and it returns bogus data and does nothing.
I'm leaning towards 2)
Click to expand...
Click to collapse
I agree with 2. I haven't looked into this, but since there's legal issues here, that argues that there's some sort of inspection (like the FCC) that has to happen before consumer release. It obviously passed that to be allowed in the market, so it's probably just feeding bad/generic data, especially since it doesn't come with that app by default.
You're probably right about the data being wrong. However the law is different in different countries. Last time I checked, in France the law is 10mW outdoors and there are restrictions in military zones; it's even less in New Zealand. So if I buy a phone in the U.S. and bring it to France I could be breaking the law. Therefore it surprises me that the OEM wouldn't test this. In Symbian it was possible to switch between 4mW/10mW/100mW in the settings but I've never seen this on Android.
dabl8 said:
You're probably right about the data being wrong. However the law is different in different countries. Last time I checked, in France the law is 10mW outdoors and there are restrictions in military zones; it's even less in New Zealand. So if I buy a phone in the U.S. and bring it to France I could be breaking the law. Therefore it surprises me that the OEM wouldn't test this. In Symbian it was possible to switch between 4mW/10mW/100mW in the settings but I've never seen this on Android.
Click to expand...
Click to collapse
Android does it by sending a wifi region code to the kernel driver (which passes it on to the firmware in most cases). This enforces frequency band limits, and (I am assuming) power limits.
For example, if a device defaults to EU region, you can't see a bunch of 5 GHz USA channels until you change region code. (There's a reason why I'm the one that wrote the region code settings patches. )
Original objective was to adj high temp property and thermal daemon mitigation. Curiosity led me into test mode and was able to get out of mini OS. However, upon reboot all options are represented by their coded counterpart, or an alphanumeric label instead of the traditional name. Having had the device for a week I haven't quite memorized the menus making the following of tutorials a challenge without pictures.
Is it possible to rectify without hard resetting?
Thanks in advance for any insight.
I just bit the bullet did a hard reset since it was affecting usability and I rely on this for business, but an alternative solution may be helpful for some,.
Hey,
Germany is implementing EU-Alert (ETSI TS 102 900 [1]) at the moment and referring to the local News, it is a huge mess [2].
But let's start at the beginning.
CellBroadcast is a core component of each mobile network generation (2G,3G,4G,5G,...) and part of the 3GPP spec. CellBroadcast basically allows the network to send a simple SMS to all mobile phones connected to a specific base station. Thes SMS-CB are sent with a Message Identifier (aka Channel, aka Topic) which gives them a special purpose by convention. e.g. ID / Channel 50 is often used for area related information [3], while channel 207 might broadcast local weather information. Since not all Channels are standardized, there is also the option to broadcast an Index that lists all channels with a description. And since users probably don't want any message broadcasted, users have to subscribe to these channels.
Since decades now, CellBroadcast is also used for public Emergency Warnings. This means that, by definition of a country, a specific channel is used to broadcast Emergency Warnings. Long time ago, in many countries it looks like Channel 919 was used for this purpose. For this to work properly, mobile phones were instructed to subscribe to channel 919 by default and also use a special ringtone (even if muted) to alert such a message.
Later - over 12 years ago - additional channels from 4370-4399 were standardized in ETSI TS 123 041 [4] for public warning systems like CMAS, EU-Alert, KPAS. All using the same channels which is beneficial for global roaming.
Android of course supports these public warning systems specified in ETSI TS 123 041 [4] since at least Android 4.2.2 [5]. And nations that use these systems already, like CMAS in the US, report very high and reliable coverage.
However, referring to German news [2] and government, not many phones that are currently on the market will actually support EU-Alert in Germany, despite already supporting EU-Alert in Netherlands or CMAS in the US.
How is this possible when exactly the same SMS-CB is broadcasted, just in a different country?
Golem [2] says that Samsung and Google already confirmed that EU-Alert is currently not supported in Germany, but updates will be rolled out to recent devices.
This strongly suggests to me that OEMs like Samsung and Google actually added country specific filters/configurations for these public warning systems to their phones without deploying a reasonable fallback. Public warning systems based on ETSI TS 123 041 [4] thus may only work in countries that were known to use these systems when the phone was released.
Isn't this an obvious issue?
Google said, starting with Android 11+ it will be possible to update the CellBroadcastReceiver App via Google Play. So devices with Android 11+ will likely receive an update to support EU-Alert in Germany. For Android 10 and older, OEMs will have to supply updates.
What also confuses me is the fact that all Android Phones I own (Nexus 4 with Android 5, Nexus 5X with Android 8, Pixel 3a with Android 12) here in Germany do actually offer the setting for Emergency Warnings and they are already enabled by default. So I assume they would work? Did Google actually deploy a sane default configuration here already?
But if they did - why isn't it working on ALL Android 11+ Phones already? I'm pretty sure my Pixel 3a uses Googles CellBroadcastReceiver App which is provided through the Play Store. So all Android 11+ phones should already use the exact same App?! Or am I wrong here? So what is this update Google actually needs to provide?
And does this also mean that with Android 11+ OEMs are not allowed / cannot implement their own Emergency Warning CellBroadcastReceiver?
This topic is really confusing to me
Shouldn't it be really simple?
All phones, regardless of the OEM, should have a proper SMS-CB Application which allows you to subscribe to custom channels, view the index, and manage your SMS-CB Messages.
Phones should also be aware of special channels to apply special ringtones etc if needed, but they should have a sane fallbacks!
A phone that knows about NL-Alert and CMAS may call messages on Channel 4370 received in the Netherlands "NL-Alert". But when it receives the same message in Germany, it shouldn't just drop it! It should display it as warning and call it whatever it wants. And if it doesn't know about CMAS / EU-Alert, it should just receive it as regular SMS-CB.
Can't be that hard?
Interestingly enough, Samsung phones allow you to subscribe to custom channels. Google phones do not :/
Should there be a better / more enforced standard, so that a country that wants to implement CMAS/EU-Alert in the future doesn't have to rely on OEMs help?
And finally some technical Questions:
I found zero Apps for Android that would allow me to subscribe to custom CellBroadcast Channels on my Google Android phones. Is this even possible?
Also, is it possible to test these CellBroadcasts somehow? Is it possible to write an App that can inject SMS-CB into the system?
Sorry for the long post, but I think this an important Topic.
Let me know what you think
Do you have experience with these Emergency Warnings already?
[1] https://www.etsi.org/deliver/etsi_ts/102900_102999/102900/
[2] https://www.golem.de/news/cell-broadcast-warum-es-am-warntag-ruhig-bleiben-koennte-2206-165822.html
[3] https://source.android.com/devices/architecture/modular-system/cellbroadcast#channel-50
[4] https://www.etsi.org/deliver/etsi_ts/123000_123099/123041/11.04.00_60/ts_123041v110400p.pdf
[5] https://cs.android.com/android/plat...ternal/telephony/gsm/SmsCbConstants.java;l=58
Hey! I was just researching something about this. Thanks for your detailed post.
I am from Chile and, in my case, my operator had subscriptions to two channels: 919 and 920.
In order to see the Cell Broadcast menu in the Messages app, I had to override a CSC setting (I use a Samsung device), particularly "CarrierFeature_Message_DisableMenuCBMessage") because it seems some Chilean operators ordered Samsung to hide it.
Even then, the Google Cell Broadcast app would not let me modify settings other than test alerts.
In my country these emergency alerts are quite unreliable and are often sent by mistake or to the wrong place (i.e. sending a tsunami alert to an area more than 100 km away from the coast).
Shooting Star Max said:
Hey! I was just researching something about this. Thanks for your detailed post.
I am from Chile and, in my case, my operator had subscriptions to two channels: 919 and 920.
In order to see the Cell Broadcast menu in the Messages app, I had to override a CSC setting (I use a Samsung device), particularly "CarrierFeature_Message_DisableMenuCBMessage") because it seems some Chilean operators ordered Samsung to hide it.
Even then, the Google Cell Broadcast app would not let me modify settings other than test alerts.
In my country these emergency alerts are quite unreliable and are often sent by mistake or to the wrong place (i.e. sending a tsunami alert to an area more than 100 km away from the coast).
Click to expand...
Click to collapse
Can you explain how you disabled this CSC setting and on what samsung phone/os?
You can see Googles/Androids latest default configuration for Chile (MCC 730) here:
https://cs.android.com/android/plat...apps/CellBroadcastReceiver/res/values-mcc730/
The config.xml really has some restrictive features enabled :/
Thanks for your reply!
Please note that all the following information assumes you have rooted your device. It's impossible to override this configuration otherwise.
My device is a Galaxy Note20 Ultra (Exynos version, SM‑N985F) running Android 12, One UI 4.1.
As you might know, Samsung devices include several packages named “CSC”, which define settings according to a sales code matching with a region. For example, a device sold in Chile without a carrier uses the sales code CHO, while one sold by operator Movistar uses the sales code CHT.
In the Galaxy Note20 Ultra, the CSC packages are stored in /optics/config/carriers/single (older Samsung devices might use /omc/).
Once you find the sales code matching with your current configuration, you can grab two files: cscfeature.xml and customer_carrier_feature.json. Taking CHO again as an example, the files would be /optics/config/carriers/single/CHO/conf/system/cscfeature.xml and/optics/config/carriers/single/CHO/conf/system/customer_carrier_feature.json.
These files are encoded, but OmcTextDecoder can take care of that.
In the case of CHO, customer_carrier_feature.json has the value "CarrierFeature_Message_DisableMenuCBMessage":"TRUE", which hides the cell broadcast menu in the stock Messages application. Just replace “TRUE” with “FALSE”, save the file and push it to its location. The next time you reboot your system, it will be applied.
Regarding the link you sent, I think we could get around that configuration by decompiling the GoogleCellBroadcastApp.apk through Apktool, modifying the restrictive values, and then pushing the APK to the device, replacing the original version.
Thank you!
Let me know if you managed to patch your original CellBroadcastReceiver.apk!
I actually tried using Runtime Resource Overlays (RROs) which is described on the official docu about CellBroadcast in Android.
You can find the result here: https://github.com/xsrf/android-de-alert
However, I didn't quite get these RROs. It looked like in Oreo you can use RROs to overlay any resource of any app without any permissions or matching signatures, which is quite a surprise to me?!
On my phones with more recent OS, I get signature mismatch errors and also it looks like apps now have to define what resources can be overlayed ...