Hi all,

I've been keeping a keen eye on all Empeg-related GPS projects (especially Rex's EmpGPS-project (http://www.ioctlsoft.com/empeg/empgps.html)), even though I've been fiddling around with Windows-based GPS stuff more.

Lately, I've been quite much toying with different acceleration/speed calculation programs. So I bumped into Åke Wallebom's OakGPS / OakCalc (http://www.ake.nu/oakgps/) and started doing some tests (as I'm a bit of a car freak). The way this program works is that OakGPS simply saves the normal NMEA-data that is received through the serial-port from the GPS itself onto the machine's hard disk. Then you can use OakCalc to calculate (with GPS latency correction etc.) acceleration data from the .txt -file that OakGPS saves. It also has a -realtime function to give results of user selected parameters _while driving!_.

What it can produce is results like these (the following are from my test run on my Golf V6 4motion):

Speed: 0-50 km/h in 2.73 seconds at 26.07 meters.
Speed: 0-80 km/h in 5.11 seconds at 71.94 meters.
Speed: 0-100 km/h in 7.22 seconds at 127.87 meters.
Distance: 0-201 m : 9.58 @ 117.51 km/h.
Speed: 0-120 km/h in 9.95 seconds at 213.66 meters.
Distance: 0-401 m : 14.85 @ 147.87 km/h.

For the record, 0-100km/h is the 0-60mph time and 0-401m is the quarter mile time.

So, what I'm thinking here is that it would be great to have this kind of functionality on the Empeg. While Åke's programs are (were) in Windows-format, I contacted him about this, wether he was interested in helping me (and I trust there are many others who are interested!) out with this. He sent me a great response and already HAS converted the OakCalc -program for Linux!

My vision about it's functionality here would be that it could be launched from either the EmpGPS (as an addition) or then Hijack - and it would display similar figures (user selectable) as above, while driving (ie. utilizing the -realtime -option). The original thought was that it would be launched as a second user-selectable screen for EmpGPS (ie. press knob or something to get OakGPS/OakCalc launched).

I have CC'ed Rex with the e-mail conversation between me and Åke, I hope we get this thing running. I am willing to produce some code to implement these things and Åke has shown me green light of using his code in this, if it will be produced as a 'binary' to the end-users . I of course have no problem if Rex gets his interests up in this little project and wants to work it out with Åke himself.

What do you think?

Amarth

This sounds fun!

Greg

This reminds me of an product I used many years ago, I think it was called a Vericom VC-200. Basically a performance computer for your car that would calculate 0-60 time, 1/4 mile time/speed, braking distances, etc. It was based on an accelerometer of some sort.

I would think that GPS might have too much latency (even with corrections) and inaccuracies. Maybe a slightly better approach would be to use an accelerometer interfaced to the Empeg... The sensors are not very expensive, and produce an analog output. Maybe a simple voltage to frequency converter going to the microphone input? I don't know enough about programming (especially in Linux) to try it myself. The only downside to the accelerometer is you have run on level ground, otherwise going up or down hill will create false readings.

Now that I think about it, another approach could be just hooking up the speedometer signal to the microphone input (possibly with a simple level converter). This would be extremely accurate real-time speed/distance data (unless the car loses traction). A simple calibration factor for each unique vehicle would have to calculated/measured, but that's pretty easy...

Damn, if I only knew more about Linux programming...

Cheers,
Phil

yeah they have the GTECH thing which is an accelerometer. Its aka GhettoTech due to high inaccuracy. Im pretty sure GPS is alot more exact

I can think of many things you could do with this... generate graphs both on-screen on the empeg and in html format that can be viewed in the car via hijack's khttpd. But I'm left wondering how accurate something plugged in via serial can be.

I don't know much about GPS data, but some of the samples that people have posted appear to be on the order of 100 bytes. At a baud rate of 9600, that only allows for 96 updates per second. If it clogged the serial port by transmitting bits in a continuous stream without any gaps at all, you'd only be able to get resolution to the 1/100th of a second. That would be good enough, but the question is: does the GPS really send 100 updates per second?

Either way, it'd still be good for a trip computer... total distance, total time stopped, average speed and with a little bit of data (geographic borders) states (or countries) visited, when there and for how long; distance to destination, estimated time remaining. When you get gas, if you tell it how much you get, it could tell you average MPG for the last tank and plot that versus average MPH for that tank.

If you want 0-60 and 1/4 mile stats then a great way to do this is through ODB-II interface to the engine management!

You loose accuracy if you start to spin wheels, but as long as you have traction then the data is fast and accurate!

I've done this on Windows platform but havent got around to porting to empeg yer!

I believe NMEA position data is broadcast once per second, but that may be configurable depending upon the receiver. I'm guessing that OakCalc does some sort of interpolation. The most accurate measurement is almost always directly off the electrical speedometer signal. It is directly proportional to distance, except in the case of wheelspin. There are some very accurate acceleromters out there, and it would be the most universal way of calculating performance as it does not rely on having an electrical speedo signal, OBD-II, or a GPS receiver.

Cheers,
Phil

Isn't wheel spin common (if not pronounced) when you're testing launch times?

I'd say a good accelerometer is the most precise (after actual light gates, of course), something off the speedo might be acceptable, but I really doubt the GPS is accurate enough for more than just fun. It's really not designed for high-speed, high-precision positioning. I imagine that there would be a lot of interpolation in the receiver itself a lot of the time.

Alex

(Un)fortunately, my Explorer does not have a wheelspin problem.

With the use of WAAS gps receivers in North America, you can get better than Differential GPS accuracy at a pretty good clip, within a couple of feet from what I understand.

Greg