Database Develop

TILT Geocaching

I havent had my tilt very long, but I have noticed that with Tom Tom 6 using thr built in GPS it doesnt trak unless im moving faster than 5mph. Has this issue been addressed? (the search tool isnt working for me) I have a bluetooth GPS and it so far is way more acurate than the built in GPS. I would like not to have to carry the bluetooth GPS for Geocaching.

I use my Tilt for geocaching all the time. I use visual GPS Beeline software. it shows me moving at walking speeds. I think Tom Tom being designed for use while driving filters the movement so that the display is stable.
http://visualgps.net/BeeLineGPS/default.htm

I think you'll really want to stick with the bluetooth GPS for geocaching. I use a GlobalSat BT-338, which in itself seems to be more accurate than the built-in GPS on the tilt, which would be better for caching. Also, there is no way (as far as I know) to turn static navigation on and off on the built-in receiver, which is going to contribute to your unit not tracking when going less than a certain speed. Thirdly, when the phone goes into standby, the GPS receiver shuts off, so you would need to keep the phone active, and just turn the screen backlight off to save battery life. There are programs to do this, but the battery is going to drain pretty quickly regardless. With an external receiver this isn't an issue, as it isn't affected by whether the phone is in standby or not, and it has it's own battery so the amount of time you can use both obviously increases.

static navigation
I have tried both a Gtop gps and the built in gps for geocaching on my tilt and neither are really good. Both seem to be affected by static navigation and/or are just very slow to reflect my position. I have tried beeline gps and others and they are afflicted by the same problem. Has anyone found a good way to turn off the static navigation on the tilt or some way to geocache effectively with it?

birdheh said:
I have tried both a Gtop gps and the built in gps for geocaching on my tilt and neither are really good. Both seem to be affected by static navigation and/or are just very slow to reflect my position. I have tried beeline gps and others and they are afflicted by the same problem. Has anyone found a good way to turn off the static navigation on the tilt or some way to geocache effectively with it?
Click to expand...
Click to collapse
As said here, and many threads. Do not use the built-in GPS. There are several reasons:
It's very slow to power up
In some apps it dumps a bunch of data every 3-4 seconds, making things very jumpy
It sometimes doesn't power off and continues to use power
It uses lots of power running (100ma+, combined with the screen, that's just 3-4 hours of power)
It wanders all over the place at walking speeds, or doesn't 'move' at all.
It'll zero out in a huge radius in real use (100 feet away from the cache for me once)
I'm sure there are more, but I was getting bored listing them.... buy a bluetooth GPS. You can get 'em for $60. The built-in GPS is okay for car navigation, and nice to have built-in, but IMO is not usable for geocaching. I've tried several times. When I first got the Tilt I hunted one cache in a huge radius and it kept going 150 feet one direction, then zeroing out, then 100 feet the other direction. Plus the data stream seems to dump every 2-3 seconds, making it very annoying to track with.
A bluetooth GPS uses no phone power, so you'd easily be able to geocache for 10+ hours in a day if you needed to. I carry mine in my pocket, it just disappears into my cargo pants.
If you're curious about software, I've tried several but I thought they all stunk, PARTICULARLY BeeLine. The interface is god awful. I never found one that I liked at all, and wound up buying StyleTap and using GeoNiche like I did on my previous Palm Treo. Works great.

static navigation
for those with static navigation problems try this. I have a PPC with Igo and same issue when you don't walk fast enough it does not register. If you use this it will fix your problem while goecaching as it has for me.
Install MMSirfSetup, available free, direct from Memory Map :
http://www.memory-map.com/MMSirfSetup.exe
Obviously you will need to install it on your PC then whap it over to your PDA.
On your PDA, run MMSirfSetup before you run your mapping software, and turn Static Navigation off.
If you use TomTom, or go above a certain speed, your unit will default to turn Static Navigation back on again.

Sorry, that won't work. the Tilt does not use a SIRF GPS chip.

GPS-lag: A misunderstood feature

Hi,
I read a lot of threads about GPS-lag on the Diamond, and found no such effect on my device. Finally, I remembered one thing which I learned about GPS-devices a long time ago:
Most of them use a feature called "static navigation" which effects the behaviour at slow speeds or stand-still, especially when walking. This is a feature which the developers of the devices may choose to activate, but it is usually not at the user's discretion to enable or disable.
When static navigation is active, the device will give less information when it moves at low speeds, typically at least up to 6km/h (ca. 4mph). Above this fixed speed, it behaves normal, under this speed, it will not give speed- or directiondata, and will often average the location data, so not every movement will be reported to the software.
When static navigation is not enabled, the reading tends to "jump" when the device is standing still, like in front of a traffic light. I remember my first receiver which had no static navigation, and when I stood at a crossing, the software would reroute after some seconds. The reason: My GPS showed me on the wrong lane and in the wrong direction, and the software believed that I was on the wrong road and had to reroute.
While static navigation is a little annoying for pedestrians, it is a blessing for people who use their devices in a car or on a bike. Here, it will smoothen the operation with road-bound software a lot.
Fwiw: I can experience the same thing. When I move by foot, the reading in Google Maps will lag a little, however when I'm on my cycle or in my car, the reading is very accurate. I have no real problem with the lag in GMM, and prefer a device which works well with Route 66.
Have fun!

this information isn't new it's in most of the threads and your post is misleading. early on you claim you don't have a problem on your device. whereas what you mean is that your device behaves as everyone else's but it doesn't bother you.
edit: I see you have edited

i interpret that as,
"my device behaves as everyone elses, and here's why.."

my icon is shown about a block behind where i actually am while driving through nyc at 30mph. that's unacceptable. your big words and lengthy explanation don't make it no better lol

MY GPS works fine once it gets a lock. But it takes a while to getb that first lock. No real lag that is noticable.

Benchmarking GPS Performance - Brainstorming

Ok..this is going to be a little long-winded so bear with me.
So there seems to be a new fix posted for gps every other day, some are just snake-oil while others might actually be doing something. The problem is how to tell what is working and what is not...and to what degree. Trusting the word of some guy on a forum with 200 posts is NOT the answer. What we need are some objective tests that produce quantitative data. It would also be nice to objectively compare our device's performance to the performance of other android devices out there too...to get an idea of what a realistic gps performance expectation would be.
So far MyTracks seems to have been the best approach but it's still a very poor method for several reasons:
The software acts as an abstraction layer - it's unknown what kind of filtering may be occurring here.
The data is only meaningful to the originator; we don't know which street(s) you were really on.
At best only 1 dimension of the error is preserved; we might be able to assume you were driving down street X, but how do we know how far down the street you actually were when the sample was captured?
Bottom line, there is no way to programmatically extract quantitative results.
I've got half of the solution: Collect a series of samples from a stationary position and collect lat/lon/alt/time, reported gps accuracy, number of satellites used, time to lock, device make/mode, device uptime (to weed out the "I rebooted and it works!" phenomenon) etc.
With this data we can calculate things like jitter, deviation, acquisition latency and all kinds of other interesting things.
I know that sounds like lots of work, but I've already done all of the above (scroll down to the bottom to read more about that) and for the most part the data collection and result presentation components work. The problems I am running into are related to the details of how the above data maps to real world performance.
So let's talk about some potential algorithms:
1. Deviation
This was my first hope as a solution; grab bunch of gps coordinates and use the lat/lon positions along with reported accuracy to get a centroid location. Then using the centroid, calculate the distances between each point and the centroid to measure accuracy. In theory, if the distribution was random, this would work. In practice however, I found that:
A - You get A LOT of duplicate points that throw off the statistics.
B - Even if you throw out duplicates, the coordinates you get are usually very close to one another, in spite of being far from the true location. In hindsight, I think that should have been obvious. Oh well.
In any case, let me illustrate:
I took 30 samples sitting in front of my office. The distribution looks like this:
http://maps.google.com/maps/api/staticmap?size=512x512&maptype=hybrid&markers=color:blue|label:1|37.280015489448,-121.943445407709&markers=color:blue|label:2|37.280015489448,-121.943445407709&markers=color:blue|label:3|37.2799150689755,-121.943469689324&markers=color:blue|label:4|37.2798287737251,-121.943507481842&markers=color:blue|label:5|37.2797409130025,-121.943532462122&markers=color:blue|label:6|37.2796490544446,-121.94354159922&markers=color:blue|label:7|37.2796117648545,-121.943468886907&markers=color:blue|label:8|37.2796034813727,-121.943455640717&markers=color:blue|label:9|37.2795946561935,-121.94344227994&markers=color:blue|label:10|37.2795861462627,-121.943431154687&markers=color:blue|label:11|37.2795786087998,-121.94342342341&markers=color:blue|label:12|37.2795720667083,-121.943418240036&sensor=false&sensor=false
And the centroid I calculated from these looks like this:
http://maps.google.com/maps/api/sta...7,-121.943465819874&sensor=false&sensor=false
Looks pretty good so far right? Not even close. You can almost predict where the gps will say I am going to be next just by looking at those points. Unfortunately, there's no data there about where I actually am. I was actually standing outside of the building, smack in the middle, which is about 30 meters south of the closest sample I got.
Which brought me to idea #2:
Measure reported accuracy, sampling frequency/jitter, time it took to acquire the initial lock and call it a day.
Which brings me here - I'd like to do this right and so I'd love to get anybody's feedback on what kind of algorithm to use to characterize gps performance.
Also, if anybody wants to take a peek at whats been done so far, here's a link to a page with the latest version of the android client. Just install it and start it up. It will pop up and error if it can't connect to the server and the server does go down from time to time, so if you get a connection error, try again a little later. The other thing to be aware of is that I enforce the "stationary collection" rule by monitoring the accelerometer. When you hit start you will have 3 seconds to put your phone on a table or the sidewalk or somewhere else that isn't moving. Once the collection starts, it will monitor GPS until it gets 30 samples. You can cancel at any time by moving the phone. If any samples were collected, they will be uploaded and you will get an option to view the results. The results aren't too terribly meaningful for now, but there are a couple interesting statistics there and you will be helping me out by stress testing the server. Feedback appreciated!
Thx

The only problem is I believe there may be some hardware variation. I've read some posts where they took two completely identical stock phones and got completely different results.

I don't see a problem with stationary data. It will always jump around. That's hardware. The hardware cannot accurately track anything less than 10 meters.
I'm more worried about why it's jumping around and losing accuracy when it's in motion.
I would make a data collection for TTTF , satellites in view, satellites with fixed, signal strength (SNR), bearing, hasAlmanac(), hasEphemeris() and accuracy.
I was thinking of writing an app but I really don't have the time for it. I have a bunch of projects lined up and really won't see any real free time until a month or two. I program for a living and currently have a private android application that uses GPS that I wrote for my clients. It's a shame the GPS is borked with the Galaxy S because I was going to use it to market my application. I have to resort to the Xperia X10. My interest in fixing the GPS is both personal and business related.
Regardless, if you need any help, let me know.
PS: I believe we need a program to really compare our "fixes" and narrow down what changes makes things better and worse. I would like to get to the point where we can calculate: X # of satellites with an average of Y dbHZ of signal strength gives you Z% accuracy

ThisWasATriumph said:
The only problem is I believe there may be some hardware variation. I've read some posts where they took two completely identical stock phones and got completely different results.
Click to expand...
Click to collapse
I dont really think that the variations are hardware related, at least I've not seen any solid data to support that assertion. Different results, even wildly different between two identical phones is expected to some degree...theres too many variables involved to directly compare two phones and expect to get identical results, even side by side. For instance, reboot one of the phones and try again. The rebooted phone will have much better performance. If we get some averages based on device and software version / configuration with a large number of samples behind it, actual differences should emerge from the noise. In any case, if there truely is a hardware problem, that will probably also be discoverable as an abnormally high standard deviation compared to other devices.

CLShortFuse said:
I don't see a problem with stationary data. It will always jump around. That's hardware. The hardware cannot accurately track anything less than 10 meters.
I'm more worried about why it's jumping around and losing accuracy when it's in motion.
Click to expand...
Click to collapse
In theory, there shouldnt be any functional difference between a moving receiver and a stationary one. At least over relatively short distances. Yes one will be cross cutting various geometric relationships with the satellites, but they are so minute that its a moot point.
On top of that, benchmarking while moving introduces two problems:
1 - Telephone poles, buildings etc. Will periodically obstruct the signal introducing an error that cannot be subtracted out.
2 - As mentioned above, there is no known point of origin. One of the consequences of that is that the conditions surrounding the data collection of user A can vary wildly from those of user B. In essence you stop measuring performance alone and start measuring performance plus the dynamics of the neighborhood. With a stationary position at least you know that your gps shouldnt be showing you moving.
From my own testing, I can say that the Captivate typically does not even calculate stationary locations correctly, as seen in the links posted above. Sadly the error signal bears no obvious relation to the true origin. And although there is a definite pattern I don't know how to analyze that pattern. I'm humble enough to admit that I'm not smart enough to figure it out. Hopefully somebody else here is though At the very least, I think that the error patterns generated from a stationary position are a solid basis for a standard test.

You should try cognition 2.2 with CLShortfuse's jupiter tweaks. For the first time I was driving 55mph with 9-11/11 sats locked on the whole time, kept an accuracy of 5-10 meters and it accurately reported my speed dead on with my speedometer. I'm pretty satisfied with the performance right now.

Have you done any tests at a benchmark site to see how accurate it is? I have been at a benchmark site one day and gotten really accurate results, only to return on another day and have trouble getting within 300 ft. accuracy. And this was done with a "real" GPS.... I think that it is going to be difficult to get good results with a smart phone acting as a handheld GPS device. Maybe I am wrong ..... I'm no engineer or programmer...
Sent from my custom EVO PC36100 Using XDA app

halfhp said:
From my own testing, I can say that the Captivate typically does not even calculate stationary locations correctly, as seen in the links posted above. Sadly the error signal bears no obvious relation to the true origin. And although there is a definite pattern I don't know how to analyze that pattern. I'm humble enough to admit that I'm not smart enough to figure it out. Hopefully somebody else here is though At the very least, I think that the error patterns generated from a stationary position are a solid basis for a standard test.
Click to expand...
Click to collapse
I haven't taken a look at your program but collecting mass amounts of information is a start. We can draw a correlation between signal strength, # of antenna and accuracy.
There is another option, that I believe would be best to identify the underlying issue. Have different Android GPS units side by side both running the same application, and have them report data for each satellite (based on PRN). They SHOULD be identical (azimuth, elevation and if possible, the reported time). Also, we would check the system times and see if they are synchronized.
According to Garmin:
Sources of GPS signal errors
Factors that can degrade the GPS signal and thus affect accuracy include the following:
Ionosphere and troposphere delays - The satellite signal slows as it passes through the atmosphere. The GPS system uses a built-in model that calculates an average amount of delay to partially correct for this type of error.
Signal multipath - This occurs when the GPS signal is reflected off objects such as tall buildings or large rock surfaces before it reaches the receiver. This increases the travel time of the signal, thereby causing errors.
Receiver clock errors - A receiver's built-in clock is not as accurate as the atomic clocks onboard the GPS satellites. Therefore, it may have very slight timing errors.
Orbital errors - Also known as ephemeris errors, these are inaccuracies of the satellite's reported location.
Number of satellites visible - The more satellites a GPS receiver can "see," the better the accuracy. Buildings, terrain, electronic interference, or sometimes even dense foliage can block signal reception, causing position errors or possibly no position reading at all. GPS units typically will not work indoors, underwater or underground.
Satellite geometry/shading - This refers to the relative position of the satellites at any given time. Ideal satellite geometry exists when the satellites are located at wide angles relative to each other. Poor geometry results when the satellites are located in a line or in a tight grouping.
Intentional degradation of the satellite signal - Selective Availability (SA) is an intentional degradation of the signal once imposed by the U.S. Department of Defense. SA was intended to prevent military adversaries from using the highly accurate GPS signals. The government turned off SA in May 2000, which significantly improved the accuracy of civilian GPS receivers.
Click to expand...
Click to collapse

rtdrumz said:
Have you done any tests at a benchmark site to see how accurate it is? I have been at a benchmark site one day and gotten really accurate results, only to return on another day and have trouble getting within 300 ft. accuracy. And this was done with a "real" GPS.... I think that it is going to be difficult to get good results with a smart phone acting as a handheld GPS device. Maybe I am wrong ..... I'm no engineer or programmer...
Sent from my custom EVO PC36100 Using XDA app
Click to expand...
Click to collapse
I have neither used nor heard of gps benchmark sites - do you have any that you've used that you recommend?
I'm fully expecting the variance you are talking about, but I also believe that the variance is there because of measurable variables...it's just a matter of identifying enough of those variables to make the results understandable. For example, we know a reboot can temporarily fix gps issues so we wouldnt want to compare the gps results of a device that was just rebooted with the results of one that has been running for days.

CLShortFuse said:
There is another option, that I believe would be best to identify the underlying issue. Have different Android GPS units side by side both running the same application, and have them report data for each satellite (based on PRN). They SHOULD be identical (azimuth, elevation and if possible, the reported time). Also, we would check the system times and see if they are synchronized.
According to Garmin:
Click to expand...
Click to collapse
I briefly started down that road by grabbing the raw NMEA sentences but quickly abandoned that path due to the volume of data being pumped. Maybe I should take a second look.
Regarding the dual phone test, thats an interesting idea. I wouldnt have expected the clock times to vary at all. I'll check into it!

Also, for whoever is interested, here is a link to some results generated by the app in progress:
http://www.halfhp.com:8080/ggs/results/show/1?mode=mobile
It only shows a small subset of the data collected, but you get the general idea of what I'm going for.

I disabled the automatic time sync. I'm going to look for an app to synchronize my clock. I'm going to disable AGPS and take a test run. It could be wrong timing that makes it unable to grab a fix
WOW, talk about a difference. I disabled time sync and I used an application called "Micro Second".
Clock difference: 5.41638 seconds
That GPS trailing/sliding issue seems about 5 seconds as well......

CLShortFuse said:
I disabled the automatic time sync. I'm going to look for an app to synchronize my clock. I'm going to disable AGPS and take a test run. It could be wrong timing that makes it unable to grab a fix
Click to expand...
Click to collapse
Shouldnt the chip be keeping track of it's own time? One common use of gps is to provide a time signal accurate to the microsecond. As far as I know, all gps devices are capable of that kind of accuracy - they have to be in order to work at all, they just dont advertise it because many dont provide a physical interface to the PPS necessary for external devices to utilize it.

halfhp said:
Shouldnt the chip be keeping track of it's own time? One common use of gps is to provide a time signal accurate to the microsecond. As far as I know, all gps devices are capable of that kind of accuracy - they have to be in order to work at all, they just dont advertise it because many dont provide a physical interface to the PPS necessary for external devices to utilize it.
Click to expand...
Click to collapse
"Should" and "does" aren't the same thing. That's under the assumption that the NMEA data is provided by gps device itself. I don't believe it is. I think the GPS device gives raw satellite data and the driver wrapper calculates NMEA data back to Android.
Also, factoring the clock desync from the correct atomic-based time should be in the data.

CLShortFuse said:
"Should" and "does" aren't the same thing. That's under the assumption that the NMEA data is provided by gps device itself. I don't believe it is. I think the GPS device gives raw satellite data and the driver wrapper calculates NMEA data back to Android.
Also, factoring the clock desync from the correct atomic-based time should be in the data.
Click to expand...
Click to collapse
I think you might be at least partially right as far as the NMEA sentences being generated outside the chip. I did a little bit of digging on the BCM4751 chip and it appears that the protocol used is MEIF, which according to the internet is a proprietary nokia protocol. I havn't found a description of the protocol yet, but I would think that it offers at least the same amount of data that NMEA offers, meaning time is kept on-chip as expected. I just cant imagine the system clock being anywhere close to useable for such a time sensitive calculation as gps triangulation. I'm gonna keep looking though.

Something else to consider guys...
I've seen lots of people referencing GPS accuracy when in motion versus standing still. I'm not so sure that all of them are complaining about what they think they're complaining about.
My primary vehicle is a motorcycle. For crappy weather, I've got a Jeep Wrangler with a fiberglass hardtop. In both cases, the phone has no sheet metal between it and the sky. And in both cases, the GPS appears to track just fine. It may not show me in the proper lane of a multilane highway, but it at least always shows me on the right side of the road, and it never lags behind my actual position. Nor does it suffer from any 'inertia' problems. When I turn, so does it. When I stop, it does too.
Now... I'm out of town at the moment on a business trip and am driving a rental car - one with a fixed sheet metal roof (no sunroof either). Since my GPS had been working at home, I was expecting it to work over here as well. Wrong! It takes forever to get a lock, and when it finally does, it drifts in and out of lock. And as I'm driving along, it's sometimes as much as 5 seconds behind me. Or sometimes along side me on a side street. Or when I stop it keeps going. You know, all the crap that everybody's been complaining about.
So. Is it a setting issue, a driver issue, or is it a problem with the hardware? I can't tell you. But what I can say is that when there's any significant metal obstruction between the phone and the sky, the GPS is hit and miss... mostly miss.

[Q] Issue with Navigation apps and power fluctuations

Hi, I'm pretty sure this is a unique or rare situation I've experienced, so I'm starting a new thread, but will endeavour to find similar issue threads.
On my motorcycle I have mounted a Brodit powered cradle for my Xperia Z. I figured it would be the ideal way of providing power to the phone while I travelled, and would allow me to use the phone as a Sat-Nav, utilising one of the many sat-nav apps (Google's offering, mapquest, copilot etc etc). Using the Brodit allows full use of the waterproof attribute of the phone - no socket ports need to be opened, and the phone doesn't need to be in a transparent case in inclement weather to prevent damage. I chose the Xperia Z (over other phones eg HTC) with this usage in mind.
It's worth nothing that I had a previous similar setup for my HTC Desire HD: without the powered mount, but using the charging socket and a transparent case over the phone for rainy days. It worked perfectly.
However - I currently am experiencing the following issues with the Xperia Z setup:
Firstly - The Brodit mount is 'not' weatherproof. (this is not Brodit's fault - it's not marketed as weatherproof) It provides power to the phone perfectly, until the first bit of rain, and then it starts to fail - either cutting out completely, or not providing enough current to keep the phone charged while the GPS / Mobile Data / Sat-Nav-App systems are turned on. (Previously it would provide enough power to increase the battery charge even while all the navigation systems were active). This is something I shall look into but I'm not really aggrieved about it - the cradle is NOT sold as an outdoor item so I'm not going to blame Brodit for this. I suspect that the issue is water getting into the 'spring-stud' connections and reducing the current flow. I'm going to see if I can adapt these connectors. If anyone has any further ideas or suggestions for better powered cradles too - I'd greatly appreciate it!
Secondly - and this is the main issue - when the power supply fluctuates (see above) the Sat-Nav Apps behave in a highly irritating manner : They instantly kill the viewport (it goes black), and also forget the current GPS location coordinates, and forget the viewport display setting: ie - show my current location in top down or perspective viewpoint and viewpoint relative to 'North'. When the power returns, the viewport, depending on how the app is being used, either returns to the start of the journey, or to a point in the journey where it remembers, but always loses the current location viewpoint settings.
This is obviously highly distracting, firstly you instantly lose your whereabouts which is dis-orienting, and secondly you then have to stop and reset all the settings so that the sat-nav display is back to doing what you want it to do. On a motorcycle this is further aggravated with the need to remove a glove in order to control the phone. On a recent trip to France I had this happen no less than 5 times in as many minutes right at the start of the journey.
It should be noted that I wasn't using the GoogleNav system in full directions mode. I find this mode misbehaves terribly if you're trying to use a customised route (see below for more info), and so I tend to load up my customised route so that it displays over the maptiles, and then I either just center my viewpoint on my location, or utilise the 'Preview' mode and again, center the viewpoint on my location (this mode displays a useful 'current direction of travel' arrow on your location).
Has anyone experienced issues like this, and if so - did you solve them? Or does anyone have any ideas for how to get into the configuration settings so that I can turn off the screen blanking and signal losses when the power fluctuates?
Thanks
Notes on Customised routes in Google Nav:
As I noted in this Google Product forums thread (just in case anyone else is involved) : https://productforums.google.com/d/msg/maps/DwPoT0pklas/sG0-sFYozT4J :
When in full 'Directions' mode, Google Maps a) doesn't poll your location accurately or often enough when slip-roads (off-ramps) are involved, and re-calculates the route to the next/final destination every time this happens - thus abandoning your carefully planned route.

So - I take it no-one has seen a similar issue or knows of a way to stop Google Maps losing all it's signals when the power is cut off?

What are the main Android Auto advantages?

I used Android Auto for the first time yesterday in a rental 2016 VW Jetta. The Phone and Music interfaces look nearly identical to what I get when pairing bluetooth and using the Car's native interface. I'm not seeing much added functionality. As for Navigation, it is nice be able to see it on the car's display. However, since it is landscape mode, only half the screen actually displays the map since there not enough height. When comparing it to what I see on my phone, it is nearly the exact same size. The other half displays the same info I would see on the phone, actually a little less. I suppose the buttons are a little bigger. One small issue is that my phone supports Qualcomm Quick Charge 2 but since I Android auto must use USB, I am left with whatever power the car ouputs. It seemed to be enough to slowly charge my phone even with Nav,Music, Phone, Bluetooth. Is it actually necessary to keep bluetooth on since the USB cable is connected? Another minor nag is that it seems to trigger night mode if I turn on the headlights which got annoying. I'd much rather it uses the light sensor.
I'm not really seeing the advantage. Am I missing some big features?
It seems its about the same to just use my phone and by doing that, I get access to more notifications and all my apps and can see my Nav plus music/phone at the same time.

Youve posted in the wrong section - this is the Android head unit forum, you want the Android Auto forum.

I think the main advantage is you don't have to mount your phone, and you can use the steering wheel to initiate choice controls. I understand what you are saying though. There is nothing life changing
Sent from my SM-G935T using Tapatalk

I've used it a bit longer. I think the major issue I have found is that it is buggy and slow, at least for me. There were probably maybe 3 major issues I found.
1. From sitting down in my car til when it was fully connected and working with nav took way too long.
2. It was very buggy. When the Nav needs to talk, it lowers the volume of the music temporarily. However sometimes, it just completely stops the music with no way to restart it other than unplugging and plugging in again (which would be very distracting while driving). Even then, often it wont reconnect correctly sometimes even causing the car part to reboot
3. It blocks my ability to text. Even on the phone. I can get it to work by going to recent apps and switching but it makes it harder to do it. They shouldn't be deciding what is "safe" and what isnt. If I'm stopped at a red light, I feel it is safe enough to send a txt, but with the blocking it makes it harder. Also it doesnt consider that I may have a passenger in the car that might want to use my phone to send or read a txt. Also, it didnt seem to read google voice or show gmail notificaitons.
It could be so much better

"safe"
eng3 said:
I've used it a bit longer. I think the major issue I have found is that it is buggy and slow, at least for me. There were probably maybe 3 major issues I found.
1. From sitting down in my car til when it was fully connected and working with nav took way too long.
2. It was very buggy. When the Nav needs to talk, it lowers the volume of the music temporarily. However sometimes, it just completely stops the music with no way to restart it other than unplugging and plugging in again (which would be very distracting while driving). Even then, often it wont reconnect correctly sometimes even causing the car part to reboot
3. It blocks my ability to text. Even on the phone. I can get it to work by going to recent apps and switching but it makes it harder to do it. They shouldn't be deciding what is "safe" and what isnt. If I'm stopped at a red light, I feel it is safe enough to send a txt, but with the blocking it makes it harder. Also it doesnt consider that I may have a passenger in the car that might want to use my phone to send or read a txt. Also, it didnt seem to read google voice or show gmail notificaitons.
It could be so much better
Click to expand...
Click to collapse
I understand you may feel it is safe to text at a stop light, but most people fell this too and get caught up in the use of their devices in a car. Texting from a car should be outlawed PERIOD! Even stopped, you need to pay attention to your surroundings while in a vehicle. This is the only way to drive safely. Technological advantages like Android Auto help us band-aid the problem by getting people to look up and away from their screen to hopefully see what is going on around you. Too many people have lost their lives to others not being fully aware of what is happening on the road. I am a tech junkie, but I know it needs to be moderated to keep everyone safe. I see someone on their phone at a light and I feel they are a danger to me and everyone around. Please, stop texting all together from the car. Trust me, if you are important enough......they will wait.
That being said....Sorry (very emotional today). Android Auto does have its advantages with offering Nav in a vehicle without paying for the upgraded interior or having to pay for OnStar Nav. Plus, it keeps heads pointed in the right direction. Up. It would be nice to have it be wireless and not be tethered with a USB cable, but I understand with the amount of data that needs to be passed. Soon all features from the phone could be hands free with inventions like Android Auto paving the way.
Thank you for listening to me rant.

The advantages are:
1. Phone gets GPS signal and speed data from car head unit antenna. This is much accurate than phone.
2. AA integrates with car multimedia and you can control it with steering wheel buttons
3. You can launch Google voice control and read some notifications.
Potentially AA could be much better, but Google had capped most of the good functions:
1. Driving GPS applications are limited to online apps (Gmaps and Waze) which are not offering the capabilities of good apps like Sygic TomTom or iGo.
2. Notification reading of all notifications.
3. Integration of email.
4. Video when not moving.
Brgds
Sent from my LG-H870 using Tapatalk

jisenberg said:
I understand you may feel it is safe to text at a stop light, but most people fell this too and get caught up in the use of their devices in a car. Texting from a car should be outlawed PERIOD! ...
Click to expand...
Click to collapse
Sorry, that is a bit ridiculous. One could argue that being on a call (on a hands free phone) is more distracting. What about people that eat while they drive. Maybe we should outlaw having conversations with passengers too. Alot of distractions are dangerous, it is the driver's responsibility to behave safely. I haven't even mentioned that the driver isnt necessarily the one interacting with android auto. The passenger might be the one that wants to use the device but they are blocked out too.
Oh and guess what, a nag message isnt going to stop someone from doing what they need to do. It just makes it harder and even more distracting.
ypsmav said:
The advantages are:
1. Phone gets GPS signal and speed data from car head unit antenna. This is much accurate than phone. ...
Click to expand...
Click to collapse
I didn't realize this, good point, my phone's GPS reception isnt so great.
ypsmav said:
...
2. AA integrates with car multimedia and you can control it with steering wheel buttons
3. You can launch Google voice control and read some notifications.
Click to expand...
Click to collapse
I don't need AA. If I connect bluetooth, I can control my media with the steering wheel buttons. At least the basic stuff (play/stop, prev, next, vol)
On some cars, I found that hitting the voice button will trigger it on my phone, otherwise, its fairly easy to press the button on the screen. I can also swipe down to read notificaitons. (ofcourse everything looks smaller)