Related
We've all seen it. We're stuck in traffic and the GPS signal starts going crazy! Or we're in a tunnel, or in an urban canyon.
It is possible to navigate using purely a g-sensor. The army does this.
The G Sensor information can be combined with the GPS signal, to clean the GPS signal, and make it more accurate.
Here's a thread about dead reckoning. Now we just need a brave soul to attempt it!
I can help with this. I'm a Java programmer and can help getting the maths required to do it.
I've noticed something strange with the Tomtom7 software.
I have never used TT7 before or any other TT product, have always used Route66 on my Nokia 6110.
When I was driving in an underground tunnel, there was no signal, but the car icon on TT kept on going? I think it's just taking last average speed and continuing on until it gets a signal lock again.
I thought it was cool.
MrDerrickC said:
When I was driving in an underground tunnel, there was no signal, but the car icon on TT kept on going? I think it's just taking last average speed and continuing on until it gets a signal lock again.
Click to expand...
Click to collapse
Yes, that's right. This behavior helps in tunnels, but it's quite annoying, when stopping the car underneath a huge bridge because of a red traffic light.
The GPS signal is lost and the navigation just drives along the route assuming you are still going about the same speed and gives nice advices while you're waiting on the traffic light. Then, when you start driving again the GPS reception comes back and the navigation realizes: "Uhh, I have some mismatch - need to recalc!". This route recalculation can lead to missing navigation advices - so everything has it's pros and cons.
this is where dead reckoning would be perfect. the g sensor would say "I'm not moving" and clean the gps signal to tomtom
the way it would be done by software is that an app would read the gps signal, and the g sensor signal, then provide a new serial port for tomtom to use. to that serial port, a cleaned gps signal would be given.
sama said:
this is where dead reckoning would be perfect. the g sensor would say "I'm not moving" and clean the gps signal to tomtom
the way it would be done by software is that an app would read the gps signal, and the g sensor signal, then provide a new serial port for tomtom to use. to that serial port, a cleaned gps signal would be given.
Click to expand...
Click to collapse
Of course, the sensor wouldn't say "I'm moving/not moving", but "my situation is steady/changes so and so" (just nit-picking!)
Anyway, yes, this would be a great idea, but I really doubt we'll be able to see something useful if the gps software companies do not choose to build it in...
We don't need to wait for GPS vendors to do this, it can be done with some s/w.
I would do this myself, but I'm a Java programmer and I'll have to learn .net thinking and syntax to do it, and I honestly have no time! The only tricky bit I see is configuring a kalman filter, but not for someone that's familiar with the maths.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
If you look at the picture above (taken from here, which is a detailed discussion of dead reckoning), you can see that the GPS signal stops after Kalman Filter #1, the dead reckoning block shown in blue would be the software filter.
I'm happy to help with the design, and will try my best to get the maths done as psudeo code.
so... one more time ... any takers?
ok maybe im missing something but this idea has issues with 2 things IMO
1) the G sensor will not be able to differentiate between travelling at a constant speed and not moving at all, because in both situations the G-force is zero [it can only detect acceleration/deceleration (hence accelerometer nomenclature) or phones orientation]
2) the phone may get all mixed up depending on how you mount the phone in the car (landscape, portrate, flat on dash), and if you move the phone in the car with your hand (eg you receive a call or just need to move it around in the car). lol
the way i can see to avoid problem 1 is if the G-sensor assumes that if you decelerate in a tunnel you are about to stop, if you accelerate you are moving, but the accuracy of this is affected by the hardware and problem 2, Overall i find it hard to see this working too well. *wonders how the army use it*
Defo worth a try tho is someone feels like putting the effort in
agreed regarding point 2. If you pick up the phone, you're not going to be able to use it, but then, if you're on the phone you won't be able to use the navigation either. Once the phone is stationary again, the filter would work.
Also, it's possible to detect erratic movement and use primarily the gps signal when that happens.
regarding point 1, this is where the combining magic happens. The GPS signal in a constant vector is an indication that all is good with the gps. when it starts to get erratic, we consult to the g-sensor's vector. In essence, both gps and innertia signals would be producing a stream of navigation data, and the filter would make the best of the data.
ps. left/right g is also measurable.
think of the g sensor data like a joystick top down view, recorded over time as a stream. that stream is the g-sensor's interpretation of the current path.
the gps signal, is also recorded as a stream.
overlay them, and if they agree, we're good. If one misbehaves, consult the other.
You guys forgot another problem. When you're moving into a tunnel or something the device will detect the declining of the angle of the car you're driving. So it will detect that you're actually accelrating even if you don't.
a raise/dip will have initial acceleration/deacceleration, but will become constant shortly after and would therefore be interpreted as vertical motion. vertical motion can be ignored here since we're only interested left/right and forward/back.
I've a friend that knows .net and we're going to work on this together. hopefully something will come out of it.
please keep any ideas/scepticism coming, they're all food for thought.
sama said:
think of the g sensor data like a joystick top down view, recorded over time as a stream. that stream is the g-sensor's interpretation of the current path.
the gps signal, is also recorded as a stream.
overlay them, and if they agree, we're good. If one misbehaves, consult the other.
Click to expand...
Click to collapse
ok i appreciate all the above points BUT surely the only reason one would want to implement the G-Sensor in the first place is so that it can provide data to the software during times when a GPS single is not available eg near high rise buildings and in tunnels...
when the software is depending on purely the data of the G-Sensor thats when it may have issues (like if u move the device) BUT i agree that it has to be better than no input at all... i am not trying to be negative here i am actually quite intrigued to see if someone would be able to get this working as the data provided by the sensor is probably just about accurate enough to work for short stints like in a tunnel etc
-=Dennis=- said:
You guys forgot another problem. When you're moving into a tunnel or something the device will detect the declining of the angle of the car you're driving. So it will detect that you're actually accelrating even if you don't.
Click to expand...
Click to collapse
this is indeed another issue
sama said:
a raise/dip will have initial acceleration/deacceleration, but will become constant shortly after and would therefore be interpreted as vertical motion. vertical motion can be ignored here since we're only interested left/right and forward/back.
I've a friend that knows .net and we're going to work on this together. hopefully something will come out of it.
please keep any ideas/scepticism coming, they're all food for thought.
Click to expand...
Click to collapse
well if you accelerate for a while that would be the same reading as going on an incline... the period of time for acceleration could be extended and hence be misunderstood as a gradient... hmmm but again this would only be an issue if it occurred when there was no GPS signal
no negativity at all, it's all positive food for thought.
I guess when you're accelerating... you're going forward! some 0-60 measuring units use g-sensors (hey that's another application )
Perhaps there are a few scenario's that would need to be profiled and modelled. so possible scenarios could be:
1- stationary, accelerate hard
2- stationary, accelerate softly
3- moving, accelerate hard (sharp speed increase)
4- moving, accelerate softly (slow speed increase)
5- moving, decelerate hard (sharp speed decrease)
6- moving, decelerate softly (slow speed decrease)
I guess Dennis is correct that hills/dips would skew the results a little by showing an acceleration for a brief time, but not a huge amount.
That's all for Z axis.
Then there's the X axis:
1- a small-small change in x means a long bend
2- a small-large-small (bell) means a sharp bend
This output can be used in conjunction with the map data, to guess where it is/has gone. When the strength of the GPS signal falls below a certain amount, then it would use this 'guessed' data.
hmm.. this approach may be too simplistic... I guess some experimentation is needed. some data will need to be collected from the g sensor, and from the gps, and then to take a controlled route, and then look at all the data in a time line. Should be interesting!
JanDaMan said:
ok maybe im missing something but this idea has issues with 2 things IMO
1) the G sensor will not be able to differentiate between travelling at a constant speed and not moving at all, because in both situations the G-force
(...)
but the accuracy of this is affected by the hardware and problem 2, Overall i find it hard to see this working too well. *wonders how the army use it*
Defo worth a try tho is someone feels like putting the effort in
Click to expand...
Click to collapse
i think that the army use a gyroscope instead of a g-force meter/sensor such as in a diamond. i don't know the exactly working of the army used gyroscope combined the gps but i can't find it out if you want to know
Greetz
sven
(gyroscope)
Re
Guys,
I work on a military boat so I cant give to much information, but thrust me. Dead reckoning on a Gsensor only is completely impossible!!!
First of all as said before you need a gyro (able to meassure roll, pitch and yaw), wich is far more accurat than a gsensor because it lacks the yaw option wich is absolutely critical. Then to make a system like this functioning you will need a lot extras, most important a compass (most prefferable a gyrocompas)
Also you need a lot of extra equipment, wind meters, acceleration meters, tilt meters, sideway movement meters etc. etc. etc.
Offcourse you can make a program wich use it a little bit, but I bet you will not be able to navigate more than 2 seconds with it and keep reliable information....
more info... inertial navigation system
anyway, I follow this just for fun
hehe i started good with my story
only the gyro part then ^^
My BMW iDrive GPS actually does this.
When in an underground park the "car" moves in the map, and it gets the position solid right when I exit the park.
These systems are not science-fiction - they're installed in every fighter jet, some commercial jets, and in fact the technology roots back to WWII.
See (also given a couple of posts up by swiftgs):
http://en.wikipedia.org/wiki/Inertial_navigation_system
Basically, if you have accurate angular and linear accelerometers, you can know exactly your position at any time, provided you knew your starting point.
The commercial/military systems have an accuracy of about 1NM/hour - i.e. after 1 hour of navigating it's about 1NM off. Of course with the aid of other navigational systems that can be recalibrated periodically.
swiftgs - you don't need any of the "extras" you mentioned - if your initial position, heading and velocity are known, you only need three gyros and three accelerometers. No compass, etc - those are there to supplement the system, minimize errors, etc.
I see two basic physical problems with implementing it in the Diamond:
1. Only 3 linear accelerometers present, angular movement information is missing (that's the "gyro" part)
2. Probably the accuracy is so low, that even internal thermal noise would give crazy readings quite fast.
joaormf said:
My BMW iDrive GPS actually does this.
When in an underground park the "car" moves in the map, and it gets the position solid right when I exit the park.
Click to expand...
Click to collapse
The BMW nav reads all sorts of telemetry data - wheel speed, steering turn, etc. not available to the diamond
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.
Has anyone else checked out Waze.com free open-source navigation and mapping software? Looks really cool.
Jamie
I started playing around with this software yesterday, I must say that its pretty brilliant. Hopefully it catches on with enough people and it gets popular.
i love this new app i was amaze to hear turn by turn and speed reading very good app just wish the police option was near me and not 900 miles away
Oh! There's more to this than just playing Pac Man with my car?
looks pretty cool, I'm gonna try it out!
It is THE killer app for all paid navigation software.
IF! the provider can stay alive long enough it will catch up globally.
Then within 5 years it will be the ONLY navigation app left.
The disadvantage is how to reach as much people possible and convince them to install. Then get in the car every day and turn it on and start driving.
I DL'd it and played with it this weekend. It does have huge upside, however, it will not be a threat to navigation software. They even say that Waze is about commuting and traveling around areas you normally travel. The software helps you inteligently see what might be affecting your commute and to route you to your location using real time traffic data.
A real world example, regular navigation software iGo, Garmin, etc, will help you find a grocery store. Where Waze will get you into the fastest checkout line, based on the speed of the customers checking out, while you were still shopping for milk. I know how to get to my work, I also know that there are several alternate routes, waze is supposed to be able to tell you which one would be faster on any given day based on real time info from other drivers.
I live in the Cleveland, OH area. We get Lake Effect snow storms. These snow storms can be very small, but very intesnse. It is not uncommon for a stretch of highway a mile long to be in near blizzard conditions, and it is sunny and clear all around. You have no idea that you are going to run into this storm until you are in it. Waze could detect the sudden drop in speed, and advise others that there is an issue, thus allowing us to pick a different route.
If you hadn't noticed I am excited by the potential. They have some bugs,the software is o.k., but it needs more developing. I was driving over the weekend and was notified of an accident 300+ miles away. However those issues are being worked on.
It has real promise
boufa said:
I DL'd it and played with it this weekend. It does have huge upside, however, it will not be a threat to navigation software. They even say that Waze is about commuting and traveling around areas you normally travel. The software helps you inteligently see what might be affecting your commute and to route you to your location using real time traffic data.
A real world example, regular navigation software iGo, Garmin, etc, will help you find a grocery store. Where Waze will get you into the fastest checkout line, based on the speed of the customers checking out, while you were still shopping for milk. I know how to get to my work, I also know that there are several alternate routes, waze is supposed to be able to tell you which one would be faster on any given day based on real time info from other drivers.
I live in the Cleveland, OH area. We get Lake Effect snow storms. These snow storms can be very small, but very intesnse. It is not uncommon for a stretch of highway a mile long to be in near blizzard conditions, and it is sunny and clear all around. You have no idea that you are going to run into this storm until you are in it. Waze could detect the sudden drop in speed, and advise others that there is an issue, thus allowing us to pick a different route.
If you hadn't noticed I am excited by the potential. They have some bugs,the software is o.k., but it needs more developing. I was driving over the weekend and was notified of an accident 300+ miles away. However those issues are being worked on.
Click to expand...
Click to collapse
We are both excited at the potential of this concept, but I think it could easily replace TomTom or Igo, IF Waze becomes widely and consistently used. It sounds like you think Waze is less useful when navigating to somewhere you haven't been before, but as long as other people on that route are also contributing data, Waze will still be more useful than even paid traffic subscriptions, because it is real time data from the road, not from observers. We all will need to use it all the time for it to live up to its promise.
I agree that more people need to use it. I was excited on a trip over the weekend to pass by someone going the other way... their icon showed up on my phone. Lots of cars around, no way to tell which one it was exactly, but kinda cool none the less.
The reason I think it is more of a commuter app than a navigation app it 2 things, 1) that is what it says on their FAQ page, and 2) I drove from Mentor, OH to Canton, OH a trip of about 90 miles. I knew close enough to where I was going, that I did not need navigation software, so I turned on waze and let it data collect... (It is important to let it collect data whenever possible, especially until the user base gets bigger)... the onscreen map showed only the map for the last "tile" i was in, and only showed a blank white screen for the space in front of me. On the way home it showed all of the map for the areas I was in on the way down. Now, I did NOT have it giving me directions, so that may have been the issue.
It was wet and slick, and we did see and accident on the other side of the road, a car slid off a curve on an exit ramp. I was impressed that it only took 3 or 4 presses of the screen to report it!
Cool
Hi there fellow Buckeye! I'm originally from Hubbard, a speck on the map north of Y-town.
I still believe that if we can get a large and diverse enough of a user base, we won't need to pay TomTom or Igo for maps or traffic data anymore.
BTW, have you had any trouble getting your GPS signal lately? I haven't been able to get a signal at all since yesterday. Prior to that it was nearly instant. I'd normally blame my device, but I know 2 others here in ATL who were having the same issue.
Can't say that I use the GPS that often to notice. As for Waze, I agree, there are a couple of people who drive around in my area that use it, it pops up. The software needs some significant development yet... but I am an eager early adopter. The key would be to get the truckers to use it... they are everywhere.
It's working again
Not sure what happened. It was wierd becuase one of the things I love about this program is how fast I get a lock. It is almost instant. With Igo sometimes it takes minutes to get a fix.
Thats a great idea about the truckers, btw
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.
I picked up a Google Cardboard for some fun, but the picture constantly rotates while trying to use it on my XZ. The axis of the rotation is that of going from portrait to landscape (Y axis??)
I've tested the accel, compass, and gyro using the service tests and they all seem to be fine. My XZ is completely stock and up-to-date (OTA).
Not sure what the problem could be? It works fine on my SGS5. I'd appreciate any feedback as the XZ looks and fits inside SO much cleaner than the SGS5, plus its not my daily driver so I won't have to take it out often.
I vaguely recall the same error happening on an app a long time ago, can't remember for the life of me what it was.
Hey. I also play with VR for almost month now(got two vr goggles with are WAY better lenses and quality than cardboard)
And also I have this problem of rotating screen. And to be honest its all depend on app and orientation provider. Most of the time app use indirect/direct sensor fusion but this method just suck...
I found only one solution for that and its to put phone on flat surface for few second with screen face up, and then phone calibrate sensor itself.
Of course its not helping for too long, but its always something...
My favorite VR game: Corridoom is best example for problem that we have.
Fast movement of device constantly move gyro starting point to one direction and when you sit in chair and look straight after a while you need to almost turn 180* because device lost this starting point. App does provide only simple calibration in main menu and Dev that I write about that said that for now its not gonna change this option.
So even if gyro in our xz is really accurate, because i use it as a VR goggles for PC gaming thanks to app Trinus VR
Only real solution for that is actual app that have option to block or reset roll effect. For example my main movie app for watching VR movies Cardboard Theater have such option and for most of time I dont have this problem when I watch movies.
I also tested it via service tests and you can see this problem, when you start app and this Rubik's cube is faced to you green move phone right and left and after few moves its not facing green, but red or blue... And for that app should have that option to reset yaw and roll when you stop moving, but for now most of devs that create VR apps and games just dont think to put such options.
And its not only XZ problem I tested it with galaxy S5 and galaxy Grand Prime and its also have that problem but not that often, mostly when I move my head very fast or for too long, screen start rotating.
maybe it would be possible to fix that in device it self to reset that roll effect but I dont think that anyone with knowledge would like to check that... :/
Trackers are pretty sensitive without some kind of reference point such as a camera. I expect a small amount of bias error over a duration, but using cardboard movie theater the screen turns 180 degrees (roll) in less than 10 seconds. The sensor tests are nowhere near as inaccurate.
Obviously any phone will have the issue over time though, they are cheap parts in small housing. There's multi thousand dollar systems with small degree of wander that are only IMUs. It's the severe amount the xz has that bugs me.
I'll try the laying it flat so it can reset its bias, might work. I noticed yesterday that when facing west it wasnt half as bad.
If you were actually able to enjoy a movie without locking the orientation then yours is far better than mine. My sgs5 I might have to adjust the orientation once every 30 minutes, the xz I have to reset it every seconds lmao.
Thank you for the input!
update:
Letting the bias adjust helped immensely. Thanks for the advice!
Hi did u manage to sort it out. I have xperia z and have same problem. I can play some games but everytime i use 'view in cardboard ' on youtube the screens spin, also when i use googke cardboard apps. Maby its a google problem and not our phones? Like you iv testedband recalibrated my phone byt to no avail
If you got it fixed giz a shout mate
Cheers