Related
Hello,
I am new to the forum and also the owner of an HTC Fuze. I have been playing around recently with the GPS on the phone and got me thinking. I live in NY and we have a CORS network of gps base stations that are fed by the use of ntrip.
I was wondering if their was any way to use the gps signal on my phone and the connection to this CORS network to give me sub inch accuracy on my phone...then not sure what I would do with it then. But I do live on a farm and I would like to see some type of precision agricultural use.
I guess I need a way to have the GPS on the phone talk with the GNSS internet radio and then give me spot on guidance and such.
Please let me know your thoughts or if I need to explain better.
Thanks,
Clayton
bump
bump. Any ideas? Anyone
Great idea cwrisrey !
That will save the cost of a geodetic device, which is many times the cost of a Fuze. Further, it will lead the accuracy of the buildin GPS into millimum class.
Not dig into this further, would you go further to tell these:
Is that CORS data encrypted?
Is that accessible through public internet or VPN?
Is there copy right or intellectuall property right issue involved? (I don't think so, but better make it clear first)
Once again, great idea. Please do remember to update this thread once you got any progress. Thanks.
More info
Hello wg5566,
This site would probably answer alot of your questions clearer than I could:
http://www6.nysdot.gov/spiderweb/frmIndex.aspx
* Is that CORS data encrypted?
-I don't believe so, I think that it is just a form of compression, to distribute across the internet.
* Is that accessible through public internet or VPN?
Yes, the NYS CORS anyway. It accessible from the public internet (although they require you to register with them) But I believe there are other free streams. I also believe it was modeled after being able to be sent threw GPRS.
* Is there copy right or intellectuall property right issue involved? (I don't think so, but better make it clear first)
-I believe the ntrip is based on a GNU, I think the source code is available. http://igs.bkg.bund.de/index_ntrip_down.htm
Windows CE version:
http://www.ilmb.gov.bc.ca/crgb/gsr/downloads/installGNSS.CAB
Please, let me know your thoughts...
Thanks,
Clayton
My fast thoughts:
First make sure there is no satisfied freeware currently available for WM.
If so please ask a moderator to move this to the development & hackings section. And Add tyis sentence on the title: Call for developers for revolutionary GPS app!
I'm sure somebody here can develop this. You know the geodetic device was invented many years ago with very weak profiles comparing to current WM devices. The hardware on our phone should be capable to deal with these calculations, and the WM Pro platform should be capable to support such an app. Anyway it should not be a biggy for many masters here. But it is a biggy for gps users with high accuracy demand for any reason.
Edit: Did you try install that wince cab on your phone? I think some of WINCE apps can just run on WM. Please backup your data first.
Edit2: I tried to install it on my device, at first it did not show up in start menu, then I found the cab just put files and shortcut in the folder names in French. But there is no registry involved in the cab. Only three files. And then program UI itself is in English. Just run the executable from the folder will go right out of the box. So please try it. I did not try to connect & loggin yet, due to not registered account.
Edit3: Looks like the cab is only access the data from internet, convert the data format and export the data, but we still need a geodetic/gps software to process/use the data.
Disclaimer: I attatched these three files for the only purppose of exchanging software developement infomation. Anybody if download it please do not use it for any purppose other than this. Thanx.
Some thoughts on the subject
Hi All,
The idea of using NTRIP to make a Windows Mobile GPS device sub-meter accurate crossed my mind. After some research I found this thread.
Unfortunately, I haven't been able to find any software capable of doing this. My idea is that it should be possible to accomplish this goal, using a combination of existing tools (which would be really cool!).
As wg5566 notes, there is a (WM) tool called GNSS Internet Radio, which is capable of downloading NTRIP corrections. It turns out this software works, but does have some flaws. Someone wrote another open source tool which is better (?), but unfortunately it isn't built for Windows Mobile (see: http://lefebure.com/software/).
More searching revealed a (dead?) project on codeplex: SharpGPS. It's an unfinished demo. It does however seem to be designed to do exactly what we're suggesting in this thread.
My idea: Completing the WM version of SharpGPS with parts of GNSS Internet radio / lefebure NTRIP client should result in a tool that's capable of upgrading a WM devices' gps signal to sub-meter accuracy through RTK/DGPS corrections over NTRIP.
Any ideas / suggestions about this?
It's already been done for the commercial market
Land surveyors, construction companies, and farmers use RTK GPS and RTK GNSS correction services on a regular basis. Some are free and some are paid subscription. They can be either NTRIP protocol with casters or individual TCP or UDP connections. Examples of software available are Carlson SurvCE and MicroSurvey. Read Carlson's support site for how they deal with the data flow using such networks on SurvCE (Windows Mobile and CE).
I have worked in land surveying using such equipment, and it generally requires dual frequency receivers, RTK corrections, and high quality antennas to achieve 1-2cm 95% CI horizontal precision. The current GPS chips in cell phones are only single frequency and so the best you could expect under ideal conditions is 2'-3' precision using some form of differential correction like WAAS or beacon or DGPS via NTRIP. Under average conditions, the precision will likely be in the 10-20' range. The dual frequency receivers take care of the large errors caused by radio waves traveling through the ionosphere.
Due to the limitations of batteries, antennas, and space for more chips in cellphones, the future of location accuracy will likely include some combination of GPS/GLONASS and cellular radio signal frequency timing calculations from cell towers. True Position, with its U-TDOA technology, is one example of measuring the time differences of cell phone radio waves using cell towers with known coordinates. Rumors (from surveying journals) have it that there are current patents in place that can allow for sub foot precision using such methods when sufficient cell towers are present for multilateration.
Has anyone found success on this topic? WM or Android...
Would be very interested, since there is a free NTRIP feed available in Switzerland... anyone?
*bump* it up
Been there still trying. Problem is no carrier phase off internal gps.
Grimli said:
Hi All,
The idea of using NTRIP to make a Windows Mobile GPS device sub-meter accurate crossed my mind. After some research I found this thread.
As wg5566 notes, there is a (WM) tool called GNSS Internet Radio, which is capable of downloading NTRIP corrections. It turns out this software works, but does have some flaws. Someone wrote another open source tool which is better (?), but unfortunately it isn't built for Windows Mobile (see: /lefebure.com/software/).
Click to expand...
Click to collapse
Lance lefebure is a really cool guy I'm sure he wouldn't have any problem building a wm version but it is going to takea lot more than that to get rtk to a cell phone.
Very good ,thanks.
Ed hardy bikini said:
Very good ,thanks.
Click to expand...
Click to collapse
If you are confused just ask questions and I will do my best to answer them. I am in the ag industry and deal with RTK networks and different ways of connecting them and tons of different gps units on a daily basis.
Look at this:
http://stakemill.wordpress.com/2010/07/19/ashtech-mobile-mapper-100-supports-esri-arcpad-10-0/
and this:
http://www.ashtech.com/-2359.kjsp?RH=1272644205746&RF=1270806507068
Is that still a phone !?
wg5566 said:
Look at this:
Is that still a phone !?
Click to expand...
Click to collapse
Nope PDA with support for external GPS with a builtin reciever that even sees glonass satellites (russian constelation). That was made specifically to do RTK mapping. It does have a GSM radio for data to connect to the cors.
Phone positioning using CORS
To perform a CORS (Network Reference correction we need a GGA stream from the GPS in your device. This allows us to remove the anomalies and provde the correction stream. As phones use a sirf II chip or similar they do not have input capability to output the NMEA stream to achieve this.
This one works great! it will connect to an Rtk receiver and get the nmea string from it or will use the internal GPS to be able to register on the CORS network. It will then stream the corrections over Bluetooth to a receiver or even a repeater radio. It won't however correct the internal GPS. http://antrip.dyndns.biz/Home/DownloadTrial
Hi! I saw that many (myself initially) fail to understand the discussions of various topics of modding on this and other forums because of certain terms that are now characteristic of speech in any argument.
-Android operating system for mobile devices based on Linux kernel. Android is an open source project developed by the Open Handset Alliance (OHA). Google was the first company to work on Android and HTC has designed and implemented the first Android phone.
-AOSP: The term stands for AOSP Android Open Source Project, which is an initiative created to guide the development of the Android mobile platform.
-ADB (Android Debugging Bridge): application via command line (command prompt, DOS), is used to flash rom, make changes to the system, backup, install applications (using the command: adb push nomeapp.apk / system / app /), copy files from your device to PC (via the command: adb pull / path / inside / of / Android / filename nome_file_destinazione) and more. ADB is a tool included in the SDK of Android that allows you to manage your phone simply by connecting it via USB. For programmers, ADB is also used to execute commands on a virtual machine Android. detailed instructions.
- Apk (short for Android Package): is the file format used to install the Android software (it works similar, more or less, that is for Windows. Exe). Renaming the extension of this file. Zip you can open it with any operator of compressed files.
-App or Apps: abbreviation of the term application or applications
-App2sd (A2sd): procedure inherent in many Roma coocked, to move applications installed, or install later, the memory card instead of phone memory. to use it you must have an ext2 or ext3 or ext4 on the memory card. part of the application (the Dalvik cache) is still stored in the smartphone does not reduce the speed of execution. app2sd this is not to be confused with the various applications on the market, as those of the market allow the movement or storage of only applications that allow it.
-Bootloader (FASTBOOT): phone mode (while connected to USB mode with usb debug enabled) through which you can do many things, including obtaining root permissions, flash ROM, make backups, pushare files, remove files etc. ... the bootloader mode varies from terminal to terminal, refer to those sections for how to go into bootloader on your device.
-Brick (brickare, brickato): literally (translated in Italian) "BRICK". making the cell like a brick, a something of unusable if not as paperweights.
-Digital compass: The digital compass is able to detect the direction in which the device is pointing. This information can be used together with an appropriate mapping software to assist in navigation to unknown places.
-BusyBox: BusyBox is important because it lets you install it on your Android poteziare with many basic Linux commands. In fact, some powerful programs, such as Titanium backup and others, use busybox to carry out the instructions. In virtually a few kb there are so many beautiful little programs. guide: using titanium or backup.
-Cache: a temporary memory in which data are stored as may be eliminated without compromising the functionality of the system.
-Digital certificate: encrypted code issued to two or more parties by an authorized organization, and used to verify the identity of those parties by exchanging their public keys.
-Cupcake: Android 1.5 or relaise first official operating system pounces April 13, 2009
-Encryption: Procedure for the encoding of a systematic bit stream before transmission, aimed at avoiding that the contents can be decrypted by third parties.
Dalvik-Cache: cache used by the system to increase the execution speed of programs.
USB-Debug: mode of Android that is (turning the feature on your device via menu / settings / apps / Development / Debug USB) to allow the system to undergo special modifications.
Direct-Push Technology: Direct Push technology (push e-mail capabilities), developed by Microsoft, lets you receive new e-mail messages on their device, they are not received by your mailbox Inbox or Exchange Server. Items such as contacts, calendar and tasks are immediately updated on the device if they are changed or added on the Exchange Server.
-Emulator: it is found in the SDK and is a software that allows you to emulate (simulate) an android device. usually serves to developers (developers) to test applications.
-Digital Signature: A digital signature assures the recipient about the identity of the person who sent the file, and the absence of alterations made after signing this.
-Firmware: Software comlpleto the phone, android rom often contains (the only operating system) the radio (software designed to handle all communications) and hboot (the part on the base, and boot management and partition of the phone) . The format depends on the parent company that issues them and shall be flashed through the tool or program.
-Flash (flash, flashed): install, installed.
-G. E. often written or GE (Google Experience): There are those phones that have the OS (see ROM for a definition) fully developed by Google without any addition or customization by the manufacturer that sells the device (for example the number of mobile Nexus is entirely GE). This designation often means that these phones are the first to receive updates of new versions of Android, because there being no additional software, as well as those developed by Google, the release is much quicker.
Another (more common) is that With Google.
Are those phones that despite having some customization software by the manufacturer, are fully compatible with the Google software and services with Android.
-GPRS: GPRS (General Packet Radio Systems - Radio systems for generic packages) is a data service for mobile devices. It is available for the devices that meet the GSM standard.
-GPS: GPS (Global Positioning System - Global Positioning System) is a radio navigation system based on satellites that allows the DENTIFICATION of a geographical position through a triangulation of points. The GPS is used on mobile devices for applications software for navigation.
-GSM: Short for Global System for Mobile communications (Global System for Mobile Communications), is the platform for mobile computing worldwide.
-HSDPA: HSDPA (High-Speed Downlink Packet Access) is a technology for mobile devices that allows higher data speeds than traditional networks. Often referred to as 3.5G for faster downloading.
-HSPA: HSPA (High-Speed Packet Access - High Speed Packet Access) is a technology for mobile devices that improves the speed at which you can send and receive information on their mobile device. HSPA technology is used in 3G networks.
HSUPA: The HSUPA (High-Speed Uplink Packet Access - access to packages for the high-speed) is a technology for mobile devices that provides (along with HSDPA) the possibility of having connections with fast download and upload very high by optimizing use of bandwidth.
-HVGA: The HVGA (Half-size Video Graphics Array) indicates a particular display resolution of 480 x 320 pixels.
-hboot: the part on the basis of partition and boot management and the phone
-Kernel: is the essential part of any operating system. Without going into technicalities, it manages hardware (drivers and other information about the hardware, for example). Android uses a modified Linux kernel and is entirely open source (ie source code is freely available and modifiable).
- Launcher: It 's the software that handles the desktop (icons, widgets, wallpapers etc..) Android operating system. In essence, is what appears when you access the phone after the unlock screen, called Lock Screen (see below) if it is enabled.
Android allows for excellent customization Lacuncher. Although all versions of Android will already have a default, it is possible (when this option is not blocked by the manufacturer) install as many as you want from those in the Market. Launcher The best known of those owners are not ADW Launcher, Launcher Pro, Helix Lancher.
Most producers customize more or less heavily, their phones (as long as they are not GE, see above), and modification of the launcher is usually the most common personalization. Motorola for example sviluppaMotoBlur (non-removable, and includes an additional set of changes including the Launcher), the HTC the Sense (removable; this also includes modifications to the deepest only launcher which also include the framework), Samsung TouchWiz the (removable) etc..
The change of Lacuncher makes it very often no longer available widgets developed for another Launcher.
-Leak Leaked or (escaped): this refers to the ROM or firmware that (strangely) escape to the Mother House, and is circulated on the net. are semi-official, in the sense that they are developed directly from 'manufacturer, but are not officially released (and therefore not fit to restore the guarantee of a device).
Screen-Lock or unlock screen: is the screen that appears after turning on and / or whenever you press the on / off the phone. Used to not press the keys when not using the phone. It requires a combination of specific touches, or gestures to be "removed"
-Nandroid (found in the recovery as amended): application that creates an image of the entire operating system, like norton gost and true image for windows.
-ODEX: type of compression that is used to free up memory and speed up your system. ODEX unzip the file compresses everything and creates a file. ODEX dall'apk deleting the file. dex then you end up with after launcher.apk and launcher.odex (so 'you have saved so much space and improved
the speed reading application). rom the ODEX can not be changed the subject.
-OTA: Over The Air - system that allows applications to receive updates directly from the network or system
Ext2/ext3/ext4-partition: partition on the memory card (which usually can be made using modified recovery) used to install applications on this media instead of filling up the phone memory. the ext is a type of file system used on Linux and is seen as part of the Android smartphone's internal memory. to partition the SD card in the sections and guides for your device.
-Profile A2DP: Advanced Audio Distribution profile (Advanced Audio Distribution) is a specification that refers to how two Bluetooth devices can transmit and receive streaming high quality audio. The A2DP allows the transfer of a unidirectional stream audio in stereo with two channels, such as music from one phone to a headset.
-Pull: used command in command prompt (eg adb pull / path / inside / of / Android / filename nome_file_destinazione) copy to your PC for a file or folder in the Android system.
-RUU: (Rom Updater Utility): A RUU is an executable for Windows, used by service centers, which basically formats all phone memory and you install an image of the official system. In general, the RUU ROM version containing a specific stock, the image of the baseband and radio, and bootloader, the versions are listed in the file name.
Radio-or banda or baseband (not the FM radio): software designed to manage all the communications device (phone, wifi, bluetooth, gps, etc. ...
-Recovery: a kind of mini operating system that is used to retrieve the cell from critical situations (brick, malfunction, etc. ....), do nandroid backup, perform the wipe, flash rom coocked and file format. Zip. The Recovery is properly called Recovery Mode and means the recovery mode in which you can perform actions such as, installing updates, format the phone, format and partition the SD and more. Updating the recovery.img (you can also do without the root) with a different and we have modified provisions advanced features without having to do other steps.
-RSS: RSS (Really Simple Syndication - Guild simple): indicates an Internet protocol used to distribute information that is updated frequently, such as a blog on the Internet, audio or video broadcasts or news headlines.
-Rom: the operating system. coocked roms are usually in. zip and go through recovery flashate
Coocked-Rom: cooked rom, created by chefs (who put together parts of rom applications, modifications, patches and so on) composed and enriched with new features
-ROOT (I take verbatim from androidpedia): What is root? In Unix-like operating systems is denoted by the root user with the highest privileges, ie, system administrator, also known as super user or superuser. (Cited in Wikipedia). Android being a linux system, then the user is root, which allows you to have total control of the phone. What a privilege we have to have root permissions? We have TOTAL control of the telephone. rootare the procedure for your device varies from terminal to terminal, consult the relevant sections to find out how to make your root device ..
G-sensor (gyro): The G sensor detects the position and movement of your device. It helps to orient the display to view both vertically or horizontally depending on how you hold the device. The G-sensor can be used in games to control the actions and other applications that require a movement to be able to be activated.
-SDK (software development kit): Software development kit, which we find in the tools folder that contains the file ADB. You can download it from for all platforms (Windows, Linux, Mac OS).
-S.O. (operating system): see ROM. In fact ROM and SO tend to coincide but while the first term is used to indicate the contents of any memory or the memory itself (it is in fact for Read Only Memory), the second indicates more specifically at a very specific piece of software and not any content that a memory can accommodate.
-Streaming: The term indicates the transmission of streaming audio or digital video using the Internet.
-Superboot: method to become the superuser (root-administrator) of your smartphone, with which you can make changes to the system, such as flash ROM, modify system folders etc. ...
-Tap (capped, plugged): equivalent of left-click on PC, then click in, clicked. TAP LONG = equivalent to right click on pc
-Thetering (wifi, bluetooth and usb): Mode is a connection between the phone is another device (mostly PC), through which you can take advantage of the internet's first, and basically use it as a modem, the second ( which as I said before can be a PC or another phone yet). May be predominantly via USB connectivity, bluetooth or wifi phone.
-Tablet is a tablet device that differs from a smartphone to the screen size (usually greater than the 5 "and for its strong propensity to navigation and document management. It usually does not incorporate a module for telephone calls (one exception is the Galaxy Tab), but often have a data connection via 3G or 4G as well as the WIFI.
Google has developed a special version of Android, called HoneyComb (3.X) for release in 2011. Nevertheless, there are Tablet with Froyo.
-VGA The VGA (Video Graphics Array) indicates a resolution of the display of 640 x 480 pixels.
-WCDMA: The WCDMA (Wideband Code Division Multiple Access) is a protocol for the transmission of data in a 3G cellular network.
-WVGA: The WVGA (Wide Video Graphics Array) indicates a display resolution of 480 x 800 pixels.
Wipe Dalvik-CACHE: reset the system cache. amended by recovery takes place.
Wipe-DATE (factory reset): hard reset (reset phone to factory settings, deletes all data and applications in your phone, no memory card). some recovery in the wiping the data format factory, not a complete hard reset, but a reset of all data in your phone, for a complete hard reset you should also wipe the system and boot from the recovery of the advanced settings or proceed with the procedure manual keystroke! how to do the hard reset via keyboard shortcut see the guides in their respective sections of your smartphone.
-ZIPALIGN: A form of compression that is used to speed up execution of applications. zipalign unzip the file and aligns the compressing apk file limit so 4byte 'Android takes up less ram to read and read more' quickly and then recreates the file. apk ^ ^
If you know other terms that do not understand, this thread is yours.
P. S. I hope to be helpful
this is actually pretty helpful words kinda like a mini dictionary for newbies coming into the modding world of android thank buddy
This should be stickied! :good:
I will see if I can not get mf2112 to add a link to this in his new user thread here.
Kudos for the effort & the great thread. Voted for sticky!
T-Macgnolia said:
This should be stickied! :good:
I will see if I can not get mf2112 to add a link to this in his new user thread here.
Click to expand...
Click to collapse
is a good idea, it would be useful
Couple of people asked me to direct them to a guide or something else which explains these terms and I literally searched pretty hard to find a good one
Now I have no worries
Thnx stempox
Sent from my pyramid.. Through blazing fast sonic waves
ganeshp said:
Couple of people asked me to direct them to a guide or something else which explains these terms and I iterally searched pretty hard to find a good one
Now I have no worries
Thnx stempox
Sent from my pyramid.. Through blazing fast sonic waves
Click to expand...
Click to collapse
Thanks man, I'm writing 'cause today I finished shots thanks
T-Macgnolia said:
This should be stickied! :good:
I will see if I can not get mf2112 to add a link to this in his new user thread here.
Click to expand...
Click to collapse
Very helpful, great work, added it just now. Rated it 5 stars and added a couple of thread tags. Stempox, you might also want to add more thread tags to make this more searchable.
mf2112 said:
Very helpful, great work, added it just now. Rated it 5 stars and added a couple of thread tags. Stempox, you might also want to add more thread tags to make this more searchable.
Click to expand...
Click to collapse
very nice thanks, good idea, because it is often difficult searching for material
Great guide ! Nice job!
Sent from my HTC Sensation 4G using xda premium
realsis said:
Great guide ! Nice job!
Sent from my HTC Sensation 4G using xda premium
Click to expand...
Click to collapse
for new users is very useful
if you suggest other terms to write
updated
new updated
Very helpful indeed...took quite a while to read and I had to subscribe to it since I won't remeber everything...but now I have something to go to when I have doubts...as a newbie, I sincerly give my thanks...
Sent from my SAMSUNG-SGH-I747 using xda app-developers app
This is a great guide for those transitioning from iOS to Android... In other words, noobs.
Sent from my SPH-D710 using xda premium
Mattix724 said:
This is a great guide for those transitioning from iOS to Android... In other words, noobs.
Sent from my SPH-D710 using xda premium
Click to expand...
Click to collapse
In did it is...I am one of those!!
Sent from AT&T Galaxy S3 SGH-i747, just in case you were wondering...
thanks!!
I can only say the same as in thread "What does * mean? - GLOSSARY" by benjamingwynn...
I have some problems to understand all of this, because my English is not so good. But the parts I understand, are very helpfully for me. So many thanks for this informations and spending so much time for it.
Greetings, 77777772
What is virtual SD ?? I read on some instruction to place the "ROM and Gapps" in your virtual SD .
There is no thanks button for the author of this list .
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.
Hello,
I want to figure out the Samsung Accesory Protocol in order to create a "open source" Gear Manager app replacement. This thread is to ask if anyone has been trying to do the same thing as well as try to gather as much information about this protocol as possible. Generic discussion is also accepted, in case anyone has better ideas.
Right now all I know is that this protocol is based on RFCOMM, albeit it can be transported over TCP too. It has a level 1 "framing" which consists basically on
Code:
packed struct Frame {
uint16_be length_of_data;
char data[length_of_data];
}
packed struct FrameWithCRC {
uint16_be length_of_data;
uint16_be crc_of_length;
char data[length_of_data];
uint16_be crc_of_data;
}
I also know that there are various types of packets. "Hello" packets are exchanged early during the connection and contain the product name, etc. Authentication packets are exchanged right after the initial "hello" and contain some varying hashes (crypto warning!). Then the normal data packets are "multiplexed", as in usbmuxd: they have 'session' IDs which described towards which watch program they are talking with. All Hello and authentication packets are sent without CRC, but normal data packets are. The CRC implementation used is crc16, same poly as in the linux kernel.
I suspect that whatever we uncover about this protocol might be useful to e.g. pair Gear with an iPhone, with a PC, things like that.
Note: most of this comes from viewing Bluetooth logs. However it's clear that reverse engineering will be required for the cryptographic parts. In this case I believe it's legally OK to do so in the EU because it's purely for interoperability reasons. I don't want to create a competitor to the Gear2, I just want to talk to it.
Motivation: I bought a Gear2 in order to replace a LiveView that was dying (buttons wearing out, broken wriststrap clips, etc.) . I used it both for notifications as well as map/navigation.
Since I have a Jolla, no programs are available to pair with most smartwatches, but I've been developing my own so far (MetaWatch, LiveView). Thus I decided on a replacement based purely on hardware characteristics and price. Also Tizen seems more open than Android, thus I figured out it would be easier for me to adapt to the watch.
However it seems that I understimated the complexity of the protocol that connects the Gear with the GearManager. So my options in order to make use of this watch are:
Sell Gear2 back and buy something that's easier to hack (e.g. another LiveView ),
Figure out the SAP protocol and write a replacement Gear Manager app (what this thread is about),
Write replacement Tizen applications that don't use SAP. This involves writing new programs for Calls, Messages, Notifications, Alarms, Camera, watchOn, Pulse monitor, etc. i.e. a _lot_ of work if I want to exploit all features of the watch.
But at least one can reuse the existing Tizen settings app, launcher, drivers, etc. (I started porting Qt to the Gear2 with this idea)
Use a different Linux distro on the Gear 2. Such as Sailfish, Mer, etc. This involves all the work of option 3 + possibly driver work.
As of now I've not decided which option is easier for me so I'll keep trying to push them all.
javispedro said:
Hello,
I want to figure out the Samsung Accesory Protocol in order to create a "open source" Gear Manager app replacement. This thread is to ask if anyone has been trying to do the same thing as well as try to gather as much information about this protocol as possible. Generic discussion is also accepted, in case anyone has better ideas.
Right now all I know is that this protocol is based on RFCOMM, albeit it can be transported over TCP too. It has a level 1 "framing" which consists basically on
Code:
packed struct Frame {
uint16_be length_of_data;
char data[length_of_data];
}
packed struct FrameWithCRC {
uint16_be length_of_data;
uint16_be crc_of_length;
char data[length_of_data];
uint16_be crc_of_data;
}
I also know that there are various types of packets. "Hello" packets are exchanged early during the connection and contain the product name, etc. Authentication packets are exchanged right after the initial "hello" and contain some varying hashes (crypto warning!). Then the normal data packets are "multiplexed", as in usbmuxd: they have 'session' IDs which described towards which watch program they are talking with. All Hello and authentication packets are sent without CRC, but normal data packets are. The CRC implementation used is crc16, same poly as in the linux kernel.
I suspect that whatever we uncover about this protocol might be useful to e.g. pair Gear with an iPhone, with a PC, things like that.
Note: most of this comes from viewing Bluetooth logs. However it's clear that reverse engineering will be required for the cryptographic parts. In this case I believe it's legally OK to do so in the EU because it's purely for interoperability reasons. I don't want to create a competitor to the Gear2, I just want to talk to it.
Motivation: I bought a Gear2 in order to replace a LiveView that was dying (buttons wearing out, broken wriststrap clips, etc.) . I used it both for notifications as well as map/navigation.
Since I have a Jolla, no programs are available to pair with most smartwatches, but I've been developing my own so far (MetaWatch, LiveView). Thus I decided on a replacement based purely on hardware characteristics and price. Also Tizen seems more open than Android, thus I figured out it would be easier for me to adapt to the watch.
However it seems that I understimated the complexity of the protocol that connects the Gear with the GearManager. So my options in order to make use of this watch are:
Sell Gear2 back and buy something that's easier to hack (e.g. another LiveView ),
Figure out the SAP protocol and write a replacement Gear Manager app (what this thread is about),
Write replacement Tizen applications that don't use SAP. This involves writing new programs for Calls, Messages, Notifications, Alarms, Camera, watchOn, Pulse monitor, etc. i.e. a _lot_ of work if I want to exploit all features of the watch.
But at least one can reuse the existing Tizen settings app, launcher, drivers, etc. (I started porting Qt to the Gear2 with this idea)
Use a different Linux distro on the Gear 2. Such as Sailfish, Mer, etc. This involves all the work of option 3 + possibly driver work.
As of now I've not decided which option is easier for me so I'll keep trying to push them all.
Click to expand...
Click to collapse
I think your thread should probably go in the Dev section for Tizen. Have you made any development? If your want it moved, report your own post with the button in top right labeled report. You can then suggest your thread be moved to the new Tizen Development section. Ok, I wish you all the luck, you seem to be very talented programmer/dev. Thanks for your contributions.
Chris
noellenchris said:
I think your thread should probably go in the Dev section for Tizen.
Click to expand...
Click to collapse
Well, some mod already moved this thread from Development, where I originally posted it, into Q&A. This is not exactly "Tizen" development (SAP is used in may Samsung devices seemingly).
noellenchris said:
Have you made any development?
Click to expand...
Click to collapse
Yes, lots of progress. I have been able to write a program that connects to the Gear2 from my PC, succesfully "completes" the setup program and synchronizes the date&time. Things like changing the background color etc. are now trivial. I will soon port it to my Jolla.
I am now looking into how to send notifications to the watch. I've not been able to get Gear Manager to actually send any notifications (to use as "reference"), because goproviders crashes when I try to simulate notifications on my android_x86 VM
If anyone can send me an HCI / Bluetooth packet capture of their Android device while it is sending notifications to the Gear2 I would really appreciate it.
Unfortunately, the main problem here is that Samsung uses some cryptographic authentication as a form of "DRM". I am not exactly sure why.
There was no way for me to discover how the crypto worked so I took the unclean approach and dissasembled their crypto code (libwms.so). That means there's no way I would be able to distribute the code now without risking a lawsuit from Samsung.
Sadly this means that while I can distribute the protocol specifications I obtained, legally distributing "Gear Manager replacements" is probably impossible.
javispedro said:
Well, some mod already moved this thread from Development, where I originally posted it, into Q&A. This is not exactly "Tizen" development (SAP is used in may Samsung devices seemingly).
Click to expand...
Click to collapse
Ya, I was kinda in a Gear 1 mind set, and they have separate threads for Android and Tizen....
Chris
javispedro said:
Unfortunately, the main problem here is that Samsung uses some cryptographic authentication as a form of "DRM". I am not exactly sure why.
There was no way for me to discover how the crypto worked so I took the unclean approach and dissasembled their crypto code (libwms.so). That means there's no way I would be able to distribute the code now without risking a lawsuit from Samsung.
Sadly this means that while I can distribute the protocol specifications I obtained, legally distributing "Gear Manager replacements" is probably impossible.
Click to expand...
Click to collapse
I would gladly write a MIT-licensed C library implementing your protocol specifications. That would be correctly following the chinese-wall approach to reverse-engineering, right?
Anyway, AFAIK, being in Europe decompiling for interoperability purposes is allowed -- I know that wikipedia is not to be taken at face value, but: en.wikipedia.org/wiki/Reverse_engineering#European_Union
Antartica said:
I would gladly write a MIT-licensed C library implementing your protocol specifications. That would be correctly following the chinese-wall approach to reverse-engineering, right?
Anyway, AFAIK, being in Europe decompiling for interoperability purposes is allowed -- I know that wikipedia is not to be taken at face value, but: en.wikipedia.org/wiki/Reverse_engineering#European_Union
Click to expand...
Click to collapse
Well, the problem is not the protocol specifications per se, which I'm actually quite confident I'd be able to redistribute (I'm in EU). The problem is the cryptography part, which is basically ripped off from the Samsung lib "libwsm.so" . Unless we can find out what cryptographic method that lib uses, distributing alternate implementations Is a no-go.
javispedro said:
Well, the problem is not the protocol specifications per se, which I'm actually quite confident I'd be able to redistribute (I'm in EU). The problem is the cryptography part, which is basically ripped off from the Samsung lib "libwsm.so" . Unless we can find out what cryptographic method that lib uses, distributing alternate implementations Is a no-go.
Click to expand...
Click to collapse
If you have the time, I don't mind researching the possible crypto used (although I've only studied DES/3DES, AES and Serpent, hope that whatever scheme used is not very different from them).
Some ideas to start from somewhere:
1. As you have used its functions, it is a block cipher? I will assume that it is.
2. What is the key size and the block size?
3. Are there signs that it is using a stack of ciphers? (that is, applying one cipher, then another to the first result and so on)
Antartica said:
If you have the time, I don't mind researching the possible crypto used (although I've only studied DES/3DES, AES and Serpent, hope that whatever scheme used is not very different from them).
Some ideas to start from somewhere:
1. As you have used its functions, it is a block cipher? I will assume that it is.
2. What is the key size and the block size?
3. Are there signs that it is using a stack of ciphers? (that is, applying one cipher, then another to the first result and so on)
Click to expand...
Click to collapse
Hello, I've not forgotten about this, just somewhat busy and been using the MetaWatch lately
1. Yes it is clearly a block cipher, and the block size Is 16bytes.
2. I don't know about the key size, it is obfuscated.
3. Doesn't seem like a stack of ciphers. It looks like some overcomplicated AES. But to be honest AES is the only encryption I know of
By the way I think I will upload my current test "manager" source code to somewhere after removing the crypto specific files . Since the protocol itself has been obtained cleanly. Note I've used Qt (not the GUI parts) so it's useless for creating a library; the code will probably need to be rewritten to do so, but it may be useful as "protocol specs".
javispedro said:
Hello, I've not forgotten about this, just somewhat busy and been using the MetaWatch lately
Click to expand...
Click to collapse
No problem. Curiously, I've transitioned from the metawatch to the Gear1 fully (null rom, not pairing with bluetooth to the phone but gear used as a standalone device).
[off-topic]I'm not using my metawatch anymore. I was modifying Nils' oswald firmware to make it prettier and to have some features I wanted (calendar, stopwatch), but it was very inaccurate, supposedly because of missing timer interrupts (the existing LCD drawing routines were too slow). I rewrote the graphics subsystem just to stumble into a known mspgcc bug, and trying to use the new redhat's mspgcc resulted in more problems (memory model, interrupt conventions). In the end I couldn't commit enough time to fix that and my metawatch is now in a drawer[/off-topic]
Returning to the topic:
javispedro said:
1. Yes it is clearly a block cipher, and the block size Is 16bytes.
Click to expand...
Click to collapse
Good. We can at least say it isn't DES/3DES nor blowfish (64 bits block size). Regrettably there are a lot of ciphers using 128-bits block size; that I know: AES, Twofish and serpent.
Perusing the wikipedia there are some more of that size in use: Camellia, sometimes RC5 and SEED.
javispedro said:
2. I don't know about the key size, it is obfuscated.
3. Doesn't seem like a stack of ciphers. It looks like some overcomplicated AES. But to be honest AES is the only encryption I know of
Click to expand...
Click to collapse
I understand that to mean that you cannot use that library passing your own key, right?
What a pity! One way to test for these ciphers would have been to just cipher a known string (i.e. all zeroes) with a known key (i.e. also all zeroes) and compare the result with each of the normal ciphers :-/.
javispedro said:
By the way I think I will upload my current test "manager" source code to somewhere after removing the crypto specific files . Since the protocol itself has been obtained cleanly. Note I've used Qt (not the GUI parts) so it's useless for creating a library; the code will probably need to be rewritten to do so, but it may be useful as "protocol specs".
Click to expand...
Click to collapse
Perfect. I don't need anything more .
Ok, so I've uploaded my SAP protocol implementation: https://git.javispedro.com/cgit/sapd.git/ . It's "phone" side only, ie it can be used to initiate a connection to the watch but not to simulate one. In addition, it's missing two important files: wmscrypt.cc and wmspeer.cc which implement the closed crypto required to "pair" the watch. The most important file is sapprotocol.cc which implements the packing/unpacking of the most important packet types. The license of those files is GPLv3 albeit I'm very happy if you use the information contained on them to build your "Gear Manager" program under whichever license you'd prefer.
For anyone who hasn't been following the above discussion: I've figured out a large part (useful for at least establish contact with the watch and syncing time/date) of the SAP protocol used between the Gear watch and the Gear manager program on the phone. This has been done mostly by studying traces and afterwards talking to the watch using my test implementation above to figure out the remaining and some error codes. The debug messages left by the watch's SAP daemon were also immensely helpful. As long as I understand this is perfectly safe to do, publish and use as I'm in the EU and is basically the same method Samba uses.
Unfortunately, the protocol contains some crypto parts required for the initial sync (subsequent connections require authentication). However, the communication itself is not encrypted in any way, which helped a lot with the process. Because it's impossible for me to figure out whatever authentication method is used, I had to disassemble the library implementing this stuff (libwms.so). This is still OK according to EU law, but I'm no longer to release that information to the public. I'm looking for alternatives or ideas on how to handle this fact.
In the meanwhile, let's talk about the protocol. It's basically a reimplementation of the TCP(/IP) ideas on top of a Bluetooth RFCOMM socket. This means that it's connection oriented and that it can multiplex several active connections (called "sessions") over a single RFCOMM link. Either side of the connection can request opening a connection based on the identifier of the listening endpoint (called a "service"). Strings are used to identify services instead of numeric ports as in TCP. For example, "/system/hostmanager" is a service that listens on the watch side. Once you open a session towards this service (i.e. once you connect to it) you can send the time/date sync commands. In addition to be the above the protocol also seems to implement QoS and reliability (automatic retransmission, ordering, etc.). It's not clear to me why they reimplemented all of this since RFCOMM is a STREAM protocol, and thus reliability is already guaranteed!! So I've not focused much on these (seemingly useless) QoS+reliability parts of the protocol.
Let's start with the link level. There are two important RFCOMM services exposed by the watch: {a49eb41e-cb06-495c-9f4f-aa80a90cdf4a} and {a49eb41e-cb06-495c-9f4f-bb80a90cdf00}. I am going to respectively call those two services "data" and "nudge" from now on. These names, as many of the following ones, are mostly made up by me .
The communication starts with Gear manager trying to open a RFCOMM socket towards the "nudge" service in the watch. This causes the watch to immediately reply back by trying to open a connection to the "data" service _on the phone_ side. So obviously this means that your phone needs to expose the "data" RFCOMM service at least. In addition, the watch will try to open a HFP-AG connection (aka it will try to simulate being a headset) to your phone. Most phones have no problem doing this so no work is required. Of course, if your phone is a PC (as in my case ) then you'll need to fake the HFP profile. I give some examples in my code above (see scripts/test-hfp-ag and hfpag.cc).
Once the RFCOMM socket from the watch to the phone "data" service is opened, the watch will immediately send what I call a "peer description" frame. This includes stuff such as the model of the watch as well as some QoS parameters which I still don't understand. The phone is supposed to reply back to this message with a peer description of its own. See sapprotocol.cc for the packet format.
After the description exchange is done, the watch will send a "authentication request" packet. This is a 65 byte bigint plus a 2 byte "challenge". The response from the phone should contain a similar 65 byte bigint, the 2 byte response, and an additional 32 byte bigint. If correct, the watch will reply with some packet I don't care about. Otherwise the connection will be dropped. It obviously looks like some key exchange. But this is the crypto part that's implemented in libwms.so....
After these two exchanges link is now set up. The first connection that needs to be opened is towards a service that is always guaranteed to be present, called "/System/Reserved/ServiceCapabilityDiscovery". It is used by both sides of the connection to know the list of available services present on the other side. Despite this, you cannot query for all services; instead, you must always know the name of the remote service you're looking for. There's some 16-byte checksum there which I don't know how to calculate, but fortunately the watch seems to ignore it!! I suspect that you're expected to actually persist the database of available services in order to shave a roundtrip when connection is being established. But this is not necessary for normal function. This service is implemented in capabilityagent.cc, capabilitypeer.cc . This part was actually one of the most complex ones because of the many concepts. I suggest reading the SDK documentation to understand all the terms ("service", "profile", "role", etc.).
If everything's gone well, now the watch will try to open a connection to a service in your phone called "/system/hostmanager". Once you get to this message things start to get fun, because the protocol used for this service is JSON! It's implementation resides in hostmanageragent.cc, hostmanagerconn.cc . For example, Gear Manager sends the following JSON message once you accept the EULA: {"btMac":"XX:XX:XX:XX:XX:XX", "msgId":"mgr_setupwizard_eula_finished_req", "isOld":1}. At this point, the watch hides the setup screen and goes straight to the menu.
Well, this concludes my high-level overview of the SAP protocol. Hope it is useful for at least someone!
Things to do:
Personally I'm looking for some traces of the notification service. Ie the one that forwards Android notifications towards the watch. For some reason it doesn't work on my phone, so I can't get traces. I suspect it's going to be a simple protocol so a few traces will be OK. It's the only stuff I'm missing in order to be able to actually use the Gear as a proper smartwatch with my Jolla.
We still need to tackle the problem of the cryptographic parts. Several options: either "wrap" the stock libwms.so file, try to RE it the "proper way", .... I'm not sure of the feasibility of any of these.
Many other services.
javispedro said:
After the description exchange is done, the watch will send a "authentication request" packet. This is a 65 byte bigint plus a 2 byte "challenge". The response from the phone should contain a similar 65 byte bigint, the 2 byte response, and an additional 32 byte bigint. If correct, the watch will reply with some packet I don't care about. Otherwise the connection will be dropped. It obviously looks like some key exchange. But this is the crypto part that's implemented in libwms.so....
Click to expand...
Click to collapse
About that 65-byte bigint... that is a 520-bit key. The usual length of ECDSA keys is exactly 520-bits, so we may have something there: it is possible that they are using ECDSA signing (just like in bitcoin, so there are a lot of implementations of that code).
Not forgotten about this!
Just an status update:
I'm still in the process of defining the API of the C library using javispedro's sources as template.
It's tougher than I originally supposed because the C++ code has a lot of forward-declarations of classes, which is very difficult to map into C. To counter that I have to move elements between structures and I'm not so comfortable with the codebase yet.
And then there is still the hard work of translating the Qt signals/slots to plain' old callbacks... and implementing the bluetooth part using bluez API... and... well, I hope that is all.
Anyway, patience .
I've now had access to a Samsung S2 and thus I have been able to obtain more traces. The latest Git now contains code to connect to the notification manager service, thus allowing to send notifications from the phone to the watch.
That was the last missing part to be able to use the Gear 2 as a 'daily' smartwatch with my Jolla, so I've now also ported the code to run under Sailfish. In fact I'm using this setup at the moment. My first comment is "wow the vibrator IS weak".
You can find a log of sapd's (ie my code) startup qDebug() messages; they may be useful (if you can't yet get your code to run)
I suspect that there may still be some important battery issues because the watch keeps printing error messages about SAP services it can't find on the phone (and instead of sleeping, it starts busy polling for them.... :/ ). It does not seem to happen while the watch is out of the charging cradle, so it may not be important, but not sure yet.
As for the encryption, I'm not sure how to proceed. I could describe the code to you, but that would be risky, because I don't understand what it does. Thus the only way (for me) to describe it would be to pass on the mathematical formulas/pseudocode ... Apart from that, we also have the problem of the keys...
Antartica said:
The usual length of ECDSA keys is exactly 520-bits, so we may have something there: it is possible that they are using ECDSA signing
Click to expand...
Click to collapse
They do use ECDH indeed, and they link with OpenSSL and import the ECDH functions. However it's not clear if they use ECDSA; while the crypto algorithm DOES resemble DSA, I cannot fully identify it.
Congratulations for managing to make it work with the Jolla .
I have finally found a suitable "flattened" class hierarchy as to be able to map your code into C; see the attachs. Basically, I have to move the functionality of SAPConnectionRequest, SAPSocket, CapabilityPeer and SAPConnection into SAPPeer, and then it is suitable for my needs.
javispedro said:
As for the encryption, I'm not sure how to proceed. I could describe the code to you, but that would be risky, because I don't understand what it does. Thus the only way (for me) to describe it would be to pass on the mathematical formulas/pseudocode ... Apart from that, we also have the problem of the keys...
They do use ECDH indeed, and they link with OpenSSL and import the ECDH functions. However it's not clear if they use ECDSA; while the crypto algorithm DOES resemble DSA, I cannot fully identify it.
Click to expand...
Click to collapse
If you manage to describe it using mathematical formulas as in
http://en.wikipedia.org/wiki/Ellipt...ture_Algorithm#Signature_generation_algorithm
it would be perfect, but I reckon that to be able write that you need intimate knowledge of the code and don't know if you have time for that :angel:
And identifying the hash function used would be a problem in itself...
One idea: how about a ltrace so we have the calls to the openssl library? That may uncover new hints.
Anyway, I have a lot of work before me until I need that, so don't fret over it.
Hi there! Any chance that the Gear can (really) work with an iPhone?
gidi said:
Hi there! Any chance that the Gear can (really) work with an iPhone?
Click to expand...
Click to collapse
agreed. Needs iPhone support please.
Antartica said:
Congratulations for managing to make it work with the Jolla .
I have finally found a suitable "flattened" class hierarchy as to be able to map your code into C; see the attachs. Basically, I have to move the functionality of SAPConnectionRequest, SAPSocket, CapabilityPeer and SAPConnection into SAPPeer, and then it is suitable for my needs.
Click to expand...
Click to collapse
You may want to look at the official Samsung SDK docs to match their class hierarchy. I tried to match my hierarchy to theirs, but this happened very late in the development process, so there is some weirdness.
Antartica said:
One idea: how about a ltrace so we have the calls to the openssl library? That may uncover new hints.
Click to expand...
Click to collapse
I more or less know what it is doing with OpenSSL, but that's because I looked at the dissassembly. They use OpenSSL for key derivation (ECDH), but the actual cryptographic algorithm is their own. This 'block cipher' is the part they have tried to obfuscate. Not much, but still enough to require more time than what I have available It is basically a set of arithmetical operations with some tables hardcoded in the libwsm.so binary, so no external calls to any library. The hardcoded tables are probably derivated from their private key, which is most definitely not on the binary. In fact I suspect this is basically AES with some changes to make it hard to extract the actual key used, so that's where I've centered my efforts.
Technically it should not even be copyrightable, so maybe I could just redistribute my C reimplementation of the algorithm, but as with any other DRM who knows these days... and that still leaves the problem of the tables/"private key".
Digiguest said:
agreed. Needs iPhone support please.
Click to expand...
Click to collapse
Well you are welcome to implement one such iPhone program yourself. Will be happy to resolve all the protocol questions you have.
(But please stop with the nagging).
Wasn't nagging at all. Just agreeing with him. I am no programmer so I have to rely on others for answers. Sorry if you thought otherwise.
Looking for to see more work on it though. Keep it up.
Hi there! Nice work on getting Gear2 to work with Jolla.
I'd love to get Gear1 to work with WP8.1. Do you have the code for Jolla
on github/bitbucket so I could give it a peek? Thanks in advance.
Duobix said:
Hi there! Nice work on getting Gear2 to work with Jolla.
I'd love to get Gear1 to work with WP8.1. Do you have the code for Jolla
on github/bitbucket so I could give it a peek? Thanks in advance.
Click to expand...
Click to collapse
javispedro had the sources in gitorius, but they are not there anymore (surely related to gitlab buying gitorius).
I attach a tarball with javispedro sources as of 19 October 2014.
Note that it lacks the files implementing the crypto, so just porting it is not enough to be able to communicate to the gear. OTOH, I know that there are some differences in the protocol between the Android Gear1 and the Tizen Gear2 (if the gear1 has been updated to Tizen, it uses the same protocol as gear2). Specifically, to be able to communicate with both watches, the gear manager package has both gear manager 1.7.x and gear manager 2.x. javispedro's code implements the gear 2 protocol.
Personally, I have my port on hold (I have problems with bluetooth in my phone, so there is no point in porting sapd right now as I would not be able to use it).
I'm an engineer/developer and know myself around Linux and a number of programming languages. I have however never programmed on a phone before and find myself on a project where I need to do just that.
We are building a field unit to capture radiometric data using custom shields on an Arduino. Due to power restrictions we cannot use more powerful hardware, yet we need to upload 8 to 10MB of data every 24 hours. I had the idea of using a mobile phone with Android, rooting and installing linux, then using the processing power and internal components to get GPS information, re-sync RTC, and then upload the data to the remote server. (The Arduino by itself is too small handle the SSH library and it doesn't have enough memory to upload the entire file using FTP. One could stream the data to the FTP protocol, but that requires multi-core processing which the Arduino doesn't support. )
I have rooted the device and installed Debian using "Linux Deploy", however I'm having a real hard time figuring out how to access the modem and GPS. It is a Motorola Moto E6. I couldn't find the modem and even install modem-manager to see if it would detect the device, but it didn't.
If anyone could point me in the right direction (drivers, documentation, instructionals, etc.) it would be very much appreciated.
Thank you.
Hi,
question is open here for quite a time, did you meanwhile figure out how to access the sensors? Some devices like accelerator are found via i2c, on my phone this is /sys/bus/i2c/devices, also current cpu frequency can be retrieved via cat /sys/bus/cpu/devices/cpu0/cpufreq/cpuinfo_cur_freq. The linux package lm-sensors and i2s-tools might help to access the devices. /sys/bus/platform/devices or /sys/devices, The current battery percentage is available from /sys/class/power_supply/battery/capacity and you can play with the leds via /sys/class/leds/<color>/brightness. Important for linux-deploy is to echo 1 > /sys/power/wake_lock to prevent the android from disabling the network while display is off.