Welcome to the MP3Car.com forums.
You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. Registering will also remove advertisements. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so please, join our community today!
If you have any problems with the registration process or your account login, please contact contact us.
|
02-20-2005, 01:49 AM
|
#16
|
|
FLAC
Join Date: Jan 2004
Posts: 1,379
|
Quote: Originally Posted by 0l33l
Yeh, just like caller ID data
Quick question about parsing data: can you get a smooth update of a digital speedometer using GPS speed?
Sure, you just apply a kalman filter, I think, to average the rate of change out and apply it each second. Depending on how accurate you want the speed to be, though, it would always be a second or two behind reality. Might not be a problem unless you're on a motorcycle and you constantly wheelie right up to the speed limit.
|
|
|
02-20-2005, 01:55 AM
|
#17
|
|
My Village Called
Join Date: Jul 2004
Location: Berkeley, CA
Vehicle: 1995 Lexus SC300 1997 Mazda Miata
Posts: 10,763
|
Quote: Originally Posted by Chairboy
Sure, you just apply a kalman filter, I think, to average the rate of change out and apply it each second. Depending on how accurate you want the speed to be, though, it would always be a second or two behind reality. Might not be a problem unless you're on a motorcycle and you constantly wheelie right up to the speed limit.
Hmm... but that would still make the needle jump around. Say at one moment I'm going 30, and the next time it checks I'm going 40, it would tell me 35, but it would also have jummped 5mph.
|
|
|
02-20-2005, 02:09 AM
|
#18
|
|
FLAC
Join Date: Jan 2004
Posts: 1,379
|
Right, so you figure the rate of change and divide it into 10-20 increments and spend the time between each update moving the needle in the direction it was going.
At the update, you make the needle start moving at the speed needed to reach the speed you read in one second. The next second, you get a new speed and make the needle start moving to that, with the target of reaching it in exactly one second. You do this over and over again, and you have a pretty smooth indicator that's one second behind GPS. It would be pretty smooth, especially at slower accelerations.
|
|
|
02-20-2005, 02:10 AM
|
#19
|
|
Admin. Don't bug or I'll byte.
Join Date: Sep 2004
Location: Corning, NY
Vehicle: 2001 VW Beetle
Posts: 4,552
|
Web definition of Kalman filter:
"A computational algorithm that processes measurements to deduce an optimum estimate of the past, present, or future state of a linear system by using a time sequence of measurements of the system behavior, plus a statistical model that characterizes the system and measurement errors, plus initial condition information. "
I know jack about this but if the definition is right, it appears that the filter allows you to predict your speed based on the rate of change between GPS speed estimations.
So in your example, when the program read 30, it would know, based on observations of speed made before the 30 reading (say 22, 25, 28 were previous readings) what the rate of change on the speedo should be NO MATTER WHAT THE TIME DELAY.
So if your program did some processing and then came back 50 milliseconds later and was ready to update the speedo, but didn't have a GPS reading, it could predict what the speed OUGHT to be by using this filtering technique.
Because the definition says it is for a linear system and acceleration/deceleration can be non-linear, it probably would have a bit of lead and lag in it but it shouldn't jump around.
Chairboy - please correct me now!
|
|
|
02-20-2005, 02:37 AM
|
#20
|
|
My Village Called
Join Date: Jul 2004
Location: Berkeley, CA
Vehicle: 1995 Lexus SC300 1997 Mazda Miata
Posts: 10,763
|
Quote: Originally Posted by Chairboy
Right, so you figure the rate of change and divide it into 10-20 increments and spend the time between each update moving the needle in the direction it was going.
At the update, you make the needle start moving at the speed needed to reach the speed you read in one second. The next second, you get a new speed and make the needle start moving to that, with the target of reaching it in exactly one second. You do this over and over again, and you have a pretty smooth indicator that's one second behind GPS. It would be pretty smooth, especially at slower accelerations.
Quote: Originally Posted by Bugbyte
Web definition of Kalman filter:
"A computational algorithm that processes measurements to deduce an optimum estimate of the past, present, or future state of a linear system by using a time sequence of measurements of the system behavior, plus a statistical model that characterizes the system and measurement errors, plus initial condition information. "
I know jack about this but if the definition is right, it appears that the filter allows you to predict your speed based on the rate of change between GPS speed estimations.
So in your example, when the program read 30, it would know, based on observations of speed made before the 30 reading (say 22, 25, 28 were previous readings) what the rate of change on the speedo should be NO MATTER WHAT THE TIME DELAY.
So if your program did some processing and then came back 50 milliseconds later and was ready to update the speedo, but didn't have a GPS reading, it could predict what the speed OUGHT to be by using this filtering technique.
Because the definition says it is for a linear system and acceleration/deceleration can be non-linear, it probably would have a bit of lead and lag in it but it shouldn't jump around.
Chairboy - please correct me now!
Starting to make sense now
What is the speed update in NMEA anyways? Its like 1 second IIRC 
Last edited by 0l33l : 02-20-2005 at 02:40 AM.
|
|
|
02-23-2005, 05:14 PM
|
#21
|
|
Constant Bitrate
Join Date: Dec 2004
Location: Jersey/Virginia Tech
Vehicle: 1996/Ford/Explorer/Eddie Bauer
Posts: 201
|
FRODO!!!!!!!!!!!!!!!!!!!!!!!
Do you realize there's a critical flaw in your GRMC parsing???
The lat and long in the NMEA format is DDMM.MMMM and DDDMM.MMMM
Your code simply parses this as
DDMM.MMMM / 100
This is incorrect, because the first MM are decimal degrees, the next set after the "." are decimal minutes. It should be this formula
DD + (MM.MMMM / 60). for lattitude.
DDD+ (MM.MMMM / 60) for longitutde.
If you had a NMEA input Latitude of 2752.26564, your code would convert this to the latitude of 27.5226564. That is incorrect.
What you need to do, is grab the degrees first (first 2 for lat, first 3 for long)
which in this case would be 27, and then calculate the minutes seperately.
which means you take 52.26564, and devide it by 60, and then add it to the 27 degrees.
so instead of
27.5226564, you SHOULD get 27.871094
This may look small, but thats nearly 30 miles! and the exagerating was even greater with the longitude.
Just a heads up if anyone is using Frodo's sample code.
|
|
|
02-23-2005, 05:28 PM
|
#22
|
|
9 Fingered Administrator Lesbian
Join Date: Jan 2003
Location: Ruston, LA
Vehicle: 1998 Ranger/1991 Sunbird
Posts: 9,852
|
Bah, so sue me. It was a 5 minute example. I don't see FrodoGPS coming out any time soon. But I will fix it 
__________________
FrodoPlayer.com
TeaBaggins.com
[H]4 Life
My next generation Front End is right on schedule.
It will be done sometime in the next generation.
I'm a lesbian too.
I am for hire!
|
|
|
02-23-2005, 06:02 PM
|
#23
|
|
FLAC
Join Date: Mar 2004
Location: Florence Yall, BFKY
Vehicle: 98 Trans Am
Posts: 1,716
|
It should also be negative if S or E.
__________________
XPort 1.26 -GPS port splitter, logger, and USB device resume fix
|
|
|
02-23-2005, 10:03 PM
|
#24
|
|
Constant Bitrate
Join Date: Dec 2004
Location: Jersey/Virginia Tech
Vehicle: 1996/Ford/Explorer/Eddie Bauer
Posts: 201
|
Frodo: haha, no worries, just had my sailboat gps software sailing in mainland florida for a couple days!
Curiosity: Depends on what you need it for, i'm plugging it into MapObjects so i just handle that operation before i feed my tracking layer a x,y and before i transform it to my mercator projection.
|
|
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
|
|
|
| Thread Tools |
|
|
| Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 07:59 PM.
|
|