What GPS unit, either Bluetooth or USB, w/ or w/out external anteanna capability will do 5-10Hz update and what software will actually follow that as I have read that Microsoft MapPoint / Microsoft Streets and Trips will only do 1Hz?

Also, obviously the most up to date maps would be nice

thx,
bob

Hi Bob,

Welcome to Laptop GPS World.

Several months ago I tested Garmin Mobile PC with a 5Hz GPS receiver. The software noticably updated map location more frequently than with a 1Hz unit. Unfortunately I didn't test any other software with it, so I cannot tell if other programs will benefit from higher refresh rate. At the moment I have no GPS receiver that does anything else but 1Hz. Your question has actually prompted me to place a quick order for a Qstarz BT-Q818X few minutes ago, so I will be able to do more testing and post some info if/when needed in near future.

One of our members recently ordered a Qstarz BT-Q1000X, and there are a few other models that do 5Hz.

Marvin, when we were doing the testing in the thread regarding the "jumpy" display updates, I tested Mobile PC and iGuidance with the i.Trek M7 set at 5Hz. Both worked fine at that setting. But I didn't think it provided any particular benefit.

Here's the thing ... it should be noticable if you are staring at the screen continuously. That is, it should provide a somewhat smoother display update because the map is not "jumping" so far between updates.

However, when I'm driving I would much rather be staring out the windshield, NOT at the nav screen. I really don't care what the nav screen is doing when I'm looking out the windshield. I just want it to be readable and displaying reasonably close to my actual location if I need to take a quick peak at it for some reason.

I'm not concerned if it shows where I was a second ago versus one-fifth of a second ago. In practical use ... in the testing I mentioned above ... it appears that the map display will always have about a 3 to 4 second "lag" no matter what the update frequency is set to. That seemed to be independent of the nav software. If I recall the details of the testing correctly, there was a small variance between the different receivers I tested in how long they took to make sure they were passing stable and accurate location data to the nav software.

I never saw anything to persuade me that there was any benefit in normal navigation use to a faster update frequency ... not if it cost any more money. Perhaps there is some other use of the receiver for which the faster update might be a benefit??

...ken...

I'm with Ken on this one. I do not believe it serves anyone using regular navigation software to promote faster data refresh rates. I am sure there are applications that will benefit from this data but low speed navigation is not one of them.

Terry

Okay, here's one message in the earlier discussion thread I mentioned above. There's a lot more detail in the discussion both before and after this message, but I think this covers the details most relevant to the issue here. Warning: this message is long and the discussion it's part of is even longer.

http://www.laptopgpsworld.com/1749-garmin-mobile-pc-vs-garmin-nuvi-7xx-accuracy#post12450

I had forgotten about the jittery display when I was running the i.Trek M7 at 5HZ. I really did find it annoying.

...ken...

Appreciate the info and will read that long thread. FWIW, usually I am the navigator, and in some instances, a more real time placement would be beneficial, as i am the one looking at the laptop and not the road - the wife loves to drive . For me, it comes down to a "I want to see exactly where I am in as close to real time as possible" mentality. When I drive alone, like you guys, 1Hz is fine as I will take the audio clues and really won't look at the laptop much at all, but I wouldn't mind 5Hz or higher just for when I am the navigator, especially in cities when we go on vacation. Even @ 25MPH, 1Hz is quite slow in residential areas.

I am also of the thinking that w/ the power of today's computers, the bandwidth of Bluetooth, or even straight USB, I just can't see why to stay @ 1Hz when we could have 5-10Hz updates.

For software I have Mappoint 2k9 (which I use for different data onto maps) and happen to use it for navigation, but on my phone I have iGuidance 4, but don't have a problem getting new software w/ the most current maps to take advantage of the new setup - I am not married to any software, it is easy enough to get use to the different GUI.

And for a different use - I have been toying around w/ the idea of converting a radio controlled car into a GPS navigated vehicle and figure if they can take advantage of the 4Hz+ GPS units, we should be able to, too.

Also, I haven't programmed in quite some time, and honestly don't want to code something that is already done...

I guess in the end it just comes down to me being a rather anal geek.

Well, I'm an anal geek, too. However, my geekness does not extend to wasting money.

(Keeping in mind that this is a relative thing. My wife thinks all of the money I spend on electronic toys is wasted.)

Because there's no useful difference?

Please read that message in the link I supplied in my last message to see what I mean. Specifically, as far as the accurate placement of the vehicle icon on the map display goes, there is no practical difference with 1HZ versus 5Hz updates.

When you start with the fact that consumer-grade GPS receivers are never better than a positional accuracy of a vehicle length or more when stationary and worse when you're moving, then add to that the ~3 second lag in the receiver that I describe in the linked message, sending data from the receiver to the nav software five times more frequently buys you nothing when it comes to the accurate placement of the vehicle icon on the moving map.

If you have some other application in mind that would benefit, go for it.

If you just want a neat toy to play with, absolutely go for it. (It's the law for geeks.)

But if you're expecting better positional accuracy of the vehicle icon on the moving map display in any PC nav program, forget it. (Of course if you want the ability to test it yourself and prove me wrong, that's the ultimate geek excuse ... go for it!)

...ken...

I read that other post and see what you are saying. w/ a built in 2-3sec delay, like you say, 5-10-100Hz won't matter at all if it is still 3sec late. I have excellent accuracy - i live in the PHX, AZ area, so no trees, tall buildings or clouds most of the year. In Mappoint, since I use that the most, I will keep the "trip" and the trail shows me ~20' off at the extreme. I was just really hoping that the data could be updated faster...

It appears that this 3sec delay is pretty much across the board at least for PC based setups? Do you know if it is a standard or if the processing that the GPS unit needs to do for filtering takes that long? Is it BT/USB overhead? I do understand that it is probably a lot of small things just adding up and for 99.5% of the use there is no real reason to work around this issue. I will have to read more on some of the hobby UAV sites like Diydrones and see how they deal w/ the delay as that could get interesting, but then again, if you are 3-5 mistakes high, I guess even there it would be a non-issue.

Thanks for taking the time answer this and also the information you posted in the other thread - I learned a lot and for that I feel I am coming out much better than the day before I registered here.

Have a good day/night,
bob

Bob, I think the reason some people like 5hz is because when used with a program that can actually use the higher refresh rate, the map movement will be nicely smooth (as opposed to the 1Hz jumps).

But again, some people may love it, and others may actually be annoyed by it.

Go check out mp3car.com forums, especially their GPS section. There you may find more info about 5Hz receivers, as there are more hobbyists there who love to do things that look nice on the screen, even if it costs more money and adds very little practical advantage.

Thanks for the info, and I will check out the site, actually a friend of mine had built a carputer a few years back and got a lot of info from that site, but back to topic, my main issue is just real time update. If w/ the 5Hz units I am still 3sec behind, whether if is from the GPS overhead, transmission overhead or? I am still 3 sec behind.

3 seconds is 264 feet at 60 miles an hour! Your GPS is not that accurate anyway.

Terry

I can't believe it, I only ordered it yesterday at around 7am, and this afternoon it was delivered to me. I selected the least expensive shipping method (international shipping), and it was supposed to arrive within 6 to 10 business days! I got very lucky! I will be able to play with my new Qstarz BT-Q818X toy tomorrow. However, the testing in the long thread Ken linked above I think already answers well the above questions.

Ah, but it's so much more fun to run it through its paces yourself, just to see!!

We will be looking for a report, soonest.

...ken...

Could you explain this?

There are a number of variables that prevent the GPS signal as displayed on the map from being exactly where you are:
The information from the satellites in view must travel a fair distance through layers of the atmosphere which can slow or disrupt them.
Reflections from mountains and building can present the device with false information.
The GPS has to work with very small signals from each satellite.
The GPS has to use some method of translating those signals into a realistic position.
The program must take that information and translate it into an indicated position.
The map you use has inaccuracies
The map has a limited minimum resolution.
Most road navigation programs lock the pointer to the road. This is optional on some.

Taking all those factors into account, 264 feet when you are travelling 60 mph is nothing.

Recently GPS devices have become more sensitive and able to obtain lock much quicker. But sensitivity does not translate directly to accuracy. The information they receive and their ability to determine what is right has not improved as much. That is why Ken sees the 'jiggle' in the display, particularly when standing still. Just because you are able to obtain more information does not make that information any more correct.

Terry

nearly a football field off? there is no way it is that far off. even after pulling up logs from a recent wifi/wardrive and going up to 60MPH i am maybe off by ~20'. i am put on the correct side of the road even on small 2 lane roads w/ a median. if i am in the lane by the sidewalk, i may show up on the sidewalk or a bit over it, but never by much. the only area i am off is the actual motion, never much to the left or right if going straight, especially nothing like a football field off even at higher speeds. i don't think mappoint 2k9 has a stick to roads option but i will look, that is why i looked at a netstumbler log as it just take the lat/lon and doesn't know where i am in relation to a road, it is just logging coordinates. when converted into a kml file, i am directly where i have driven, even times when i have gone through a parking lot or through a drive through.

fwiw, when i drive through a parking lot w/ mappoint 2k9, it will show me driving in the parking lot and not kicking me back to the road, which may only be 20yds away

again, i am in the phx, az vicinity and there aren't many large buildings where i live, let alone ones that are more than 3 stories high, not much large vegetation - even a "full" tree out here is pretty sparse.

even when i sit in my condo w/ the gps on, it is very close to the exact place i am on the planet, not off by much at all

S&T does use lock on roads and, as far as I know, can tell from the direction of travel which side of the road you should be on.

Let us hope your apartment is standing still in relation to the earth.

Terry

that may be the case (i will look into it), but the log from netstumber does not know the roads, it is just logging the info received by the gps unit.

i meant in regards to the condo, i get about the same accuracy as sitting still in the condo as i do when driving, w/ the exception of the lag. it is not like in the condo i am g2g but when drivng i am a 3/4 football field off

if anybody can recommend me a logging/parser i will be more than happy to run a test to see if mappoint is click to road along w/ somehow the parser i used on the netstumbler log "clicked" it to road somehow.

again, i can go "off road" in mappoint and do not get put back on a road by the software.

Oh boy ... as usual the question of GPS "accuracy" has again opened a giant can of worms.

Re: "3 seconds is 264 ft at 60 mph..." -- That's in the direction of travel. At 60 mph you are travelling 88 ft per second. Thus, 3 x 88 = 264 ft delay of vehicle icon placement on the moving map display if the receiver has a lag of 3 seconds in order to make sure it's providing a stable location to the nav program.

Not 264 ft. left or right of direction of travel. 264 ft behind.

Depending on how tight the map is zoomed, Terry is absolutely right: it's nothing. At any zoom level that is useful when travelling at highway speeds, it's just not a big thing.

Re: Bob's check of "accuracy" from a data logger... -- see above for part of the answer to the issue of lateral (to the direction of travel) accuracy. Terry was only refering to lag-induced inaccuracy in the direction of travel.

Depending on the satellite configuration the receiver can see, it's very likely your lateral accuracy will be quite good, especially on a long straight stretch or where your direction changes are small and gradual. If the lateral position is not changing much, it's almost as good as standing in one spot and letting the receiver "average" the signals ... it just keeps getting more accurate, within the limits of the receiver.

If the road placement is accurate on the map display, you should see the vehicle on it and possibly even in the correct lane. If there is no, or minimal, lateral position movement, there is every reason to believe you will have very accurate lane position placement if the map data is good. The track file from your data logger will confirm this easily.

When following roads, the only vector that is changing significantly is in the direction of travel. So we're back to verifying the lag-induced positional inaccuracy. And that's not going to be possible for you to verify with your data logger because you are missing one critical piece of data. The data logger will have each data point time-stamped. But you have no way of knowing when you were actually at those data points to less than one second (if it's me, I'll be lucky to remember what day it was I took the drive and, maybe, whether it was am or pm!). So you don't know if they are right on or if the nav software would have received them ~3 seconds afterwards, thus causing the moving map display to be, say, 264 ft. "slow" if you were travelling 60 mph.

Naturally, the lag-induced display inaccuracy gets smaller as the speed slows down. At a brisk walking pace of, say, 5 mph the positional inaccuracy on the moving map display will be 21.9999999999999 ft. 3 seconds x 7.3333333333333333... ft per second) That's getting very near the limits of consumer-grade GPS accuracy even if you were standing still.

Re: Snap to Roads... -- This setting has very specific limits. Once you stray more than a specific distance from the nearest road the nav software will cease to try snapping you back to the nearest road. That's why you can go driving off into areas where there are no roads shown on the map display and see your actual position (and track, if you have breadcrumbs/track display turned on). Even if you have snap to roads turned on.

Re: Terry's list of stuff that affects GPS accuracy... -- It's all true. And it's all stuff that the receiver is trying to figure out. That's why there's a bit of a lag between the time of receiving the relevant satellite signals and the time the receiver sends the location data to the nav software. It takes a measurable amount of compute time for the receiver to take all that stuff into consideration and decide what location data to send to the nav software.

You will appreciate that you can't get a very big computer into that little receiver, especially when you want to keep the power draw to a minimum.

Remember, we're not saying that either the receiver or the nav software are inaccurate (within their design limits) or that either one of them are doing anything wrong or bad or have bugs. It is what it is. It takes the receiver a finite and measurable amount of time to do the necessary calculations and give them to the nav software. The nav software will then display the location at exactly the coordinates it was given.

Bob,

If you are interested in a better understanding of the issues affecting GPS "accuracy" here are a couple of suggestions. First, check out my own treatment of the more general question of GPS "accuracy" here.

For a much more detailed treatment of positional accuracy (read my post first to see why I emphasize that word here) check David Wilson's page. If you want to do some random research on your own, Google "GPS DOP" (DOP = Dilution of Precision) and "GPS HDOP" (Horizontal Dilution of Precision). HDOP is the one we earthbound folk are most concerned with.

...ken...

thanks ken for the explanation that terry was talking about the lag induced inaccuracy. i didn't read it as that, i just read it as inaccuracy overall and that was not what i was seeing.

i have read a bit about dop and the utility that i have that works w/ my unit (a holux bt unit) shows dop between .9 and 1.1 in the condo, but again this is stationary atm.

I apologize that I was not clear enough about how the 3 second error that Ken observed translates into linear distance. Unfortunately, what is clear to me does not always translate into what I write.

What I am trying to say is the combination of today's consumer GPS devices and the available mapping data create an excellent navigation experience. But don't expect them to give you pin point accuracy. Increasing the samples available from the GPS will not improve this accuracy either.

terry

So, if you have a 6 meter accurate device (typical of consumer-grade GPS receivers) that's about 6 meters or 20 ft (1 DOP x 6 meters).

Many newer GPS devices claim 3 meters "accuracy" 95% of the time.

Most consumer GPS units do not display DOP (and most manufacturers don't say much about it) but they factor it into the accuracy estimate that they display. Every manufacturer calculates their accuracy estimate differently so it's not easy to make a comparison.

If you see an accuracy estimate (it's technically called the Estimated Position Error or EPE) that says, say, 20 ft. it means there is a pretty good chance that the location coordinates the receiver is giving are somewhere in a circle of 20 ft radius around where you are actually standing.

To look at it another way, if the GPS says you are 100 ft from a specific waypoint and the "accuracy" (EPE) is 20 ft, that means there's a pretty good chance you are between 80 ft to 120 ft from that waypoint.

Terry is correct when he says consumer GPSs won't produce survey accuracy. Just ask anyone involved in the sport of geocaching. Most geocaches have descriptive text hints that are supposed to help you find the cache visually once you are within the GPS accuracy limits. Given the accuracy limits and how they can be adversly affected by things like tall buildings, tree cover and weather conditions, good text hints are crucial in whether you will find the cache or not. Some cache placers do a better job than others in this regard. (Some really need a good slap with a 2x4. )

...ken...

This is how Garmin Mobile PC represents the error (when using a Garmin GPS) in the GPS information screen and on a 2D map view. At the scale presented, the circle represents the accuracy (EPE) of the signal at that moment.

This was done in the house so the accuracy is a little low.

Terry

Attached Images

GPS Accuracy.jpg (110.5 KB)

Map Accuracy.jpg (101.8 KB)

That estimated accuracy is just that ... estimated. A single frequency receiver can, at best, calculate it from satellite error fields in the NAV message and then apply DOP from satellite geometry. The receiver has 'no idea' about the current signal transmission delay through the atmosphere.

A 5 HZ rate has the potential to indicate position more accurately because there is one fifth the latency in data delivery to the computer. With higher data rates, that requires an implementation of a high quality predictive filter within the receiver to maintain positional accuracy at high velocity.

--- CHAS

[Editorial Rant]
I wish someone could persuade the manufacturers to not use the word "accuracy" because the value they are quoting has little to do with accuracy. It is properly called the "Estimated Position Error",with heavy emphasis on the "Estimated".

As Chas said, each manufacturer does some sort of proprietary VooDoo with the various xDOP values passed from the receiver, calculations that are designed to guess roughly how close they might be to the indicated coordinates.

Most people view this as an indication of how good the current positional indication is. That's backwards. We should train ourselves to view it as how bad the current positional indication might be. That would cause our expectations about the accuracy of these devices to be much more realistic.

That's not a criticism of the devices. They are incredibly useful. Even more so when our expectations of them are realistic.
[/Rant]

...ken...

I read an article years ago that testing suggested 2 Hz was the best rate to overcome the latency involved in matching the GPS output to the software input. I didn't know if this still applied though. I wonder if manufacturers such as Garmin can match the timing of their GPS update to the corresponding Garmin software input.

Terry

again, not trying to cause any stress, but i was looking over @ mp3car and some gps info overlay. the reason i am bringing this up is because there is literally no lag when the vehicle starts moving to when the gps overlay show a difference in speed - not a 2-3sec delay.

i don't know if this is because of a strictly hardware setup or something else. fwiw, it is running a 5Hz unit.

video 1:
http://www.blackboxcamera.com/pic-osd/clips/5HzTest.wmv

video 2:
http://www.blackboxcamera.com/pic-osd/clips/5HzDrive.wmv

again, watch until the car stops and then starts moving again - there is no 2-3sec delay. unfortunately i don't know the accuracy but somehow they have got around the delay we see w/ pc setups (maybe this is the problem)

Rather than trying to determine what does or doesn't happen vicariously, why don't you purchase a GPS that can do better than 1 Hz and test it. As you say, you can be a navigator, so are in a perfect position to do first hand testing. See for yourself what different refresh rates do using software that does (or doesn't) respond appropriately.

I have the equioment and software and would love to help. Unfortunately, my wife doesn't drive and last time I tried something similar, I got a speeding ticket in a school zone. The policeman was very understanding and interested in the tablet and BT GPS. I probably could have talked him out of the ticket but I was too embarassed. Needless to say, I will leave that testing to others who have a driver.

You can then report as to what really happens and let us know the most accurate setup possible for your use.

Terry

Actually, if you watch carefully in both of those videos there is a delay on both starting and stopping. When the vehicle is using a normal stop procedure it's between two and three seconds.

In the couple of instances where there appears to be no delay when stopping, you'll see that the car is creeping near the end, so it's very nearly stopped for all practical purposes for at least three or four seconds before it actually ceases motion.

There are a couple of instances where there appears to be no delay when starting but even there it's a good one second plus from the time you perceive motion and the time the speedo starts to change.

That's the sort of delay I was refering to in my testing. I drive differently than that, so it's more noticable. That is, I normally start and stop more quickly than the driver in the video.

The bottom line is that it takes a measurable amount of time when you are starting or stopping for the display software to determine that the location has not changed or has started to change and to adjust the speedometer display accordingly.

I think the small improvement in the videos over what I've seen in my testing (and it's a really tiny improvement) is more likely due to the update latency of the drawing software. In the video, there is very little drawing to do so there's almost no latency. In a laptop nav program it not only has to draw the speedometer, it has to draw the whole map.

...ken...

After taking another drive w/ the wife driving and really paying attention i do see what you are saying about the delay in the vidoes - you have good eyes

I had the advantage of already doing a fair bit of observation when I did the original testing so I had a good idea what to look for. I also was a biker for thirty years. You don't survive for that long on a bike without being able to catch small movements in your peripheral vision.

Glad you can see what I was refering to. It was not my intention to knock the product in the video. It's really quite neat. It's just not a quantum improvement or anything.

...ken...