# Calculate Distance off of Speed or GPS position?

Oh I hadn't considered pulseIn(), that a good idea (my poor wallet, lol) I've been looking around the forum for making a speedometer and I'm noticing a lot of people hit issues with max speeds. I'm not a pro, but I do get up there in speed from time to time.

So for testing accuracy I was going to literally get out my tape measurer and mark out 100' on a nearby hill and do laps up and down it. Then I was thinking I could go to a nearby track (alternatively, I would use a football field) and do some laps around the track. That should give me a good measurement for a hill and a flat track.

That has definitely been the least accurate one I've tested with so far. Now admittedly, maybe the problem is with me, their documentation is a little spartan on how you're supposed to use things, but while I've been duly impressed with the accuracy of the GPS reading, the odometer has not been wowing me. It's definitely designed to only be mostly accurate while in motion.

So I've been doing more testing and I realized some flaws in my basic logic for my 3rd approach when factoring in height. I had a fundamental misunderstanding of what my delta x and delta y values were. I thought they were the distance between my GPS co-ordinates represented in KM. They are not. So when I did a straight conversion of my height in meters to KM my calculations were off by several 1000M per calculation.

I found two ways to correctly factor in height, the first was a sledge hammer approach with an excel spreadsheet where by trial and error I found a magic number of 1 meter = 0.00000899322 units which I could then plug into my Sqrt(dXdX+dYdY+dH*dH)*111194.93 and get the right results in meters (where 111194.93 is degrees/meter) and crap.

Wow, so stick with me, as I wrote that last line I just figure out my magic number. My magic number that I found after 10 minutes of fiddling around in a spreadsheet is 1/111194.93 converting my height in meters to the same units as my GPS co-ordinates.

This realization makes my second method pointless as I only cared about it in reference to the first one being to smoke and mirrors for my taste. Could I rely on that magic number to work on larger distances or changes in height? I didn't know! So the second method was to just find the distance between two GPS points using the equirectangular approximation and then factoring height in with the standard Sqrt(equirectangular approximationequirectangular approximation+dHdH).

Sorry, long rambling post, but it all just clicked as I was typing. I'll do some testing and post the code I used in a follow up post. Obviously I still have to worry about bad GPS readings, but I'm using a simple LatFiltered = (LatFiltered * 0.9) + (newLatitude() * .1) filter to hopefully smooth out any erroneous readings.