|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
More Crazy data
I have a Garmin 910xt a triathlon type watch but I am a runner and cyclist. It supposed to have barometric altimeter in it right? Well the data is seriously in conflict. I notice all the time when I upload to Garmin connect then Strava the elevation gain is way less than RIde With The GPS. I don't use RWGP but it uploads since I have an account. My Ride with the GPS always shows much more elevation gain. Today I went 53 miles and on Garmin the gain was 1165 and Ride with the GPS it was 1630. That is fair amount of off and usually that is close to what will be. I normally don't track this stuff I live in the flatlands but the data is suspect for sure. More fake news from something.
Deacon Mark |
Ads |
#2
|
|||
|
|||
More Crazy data
On Monday, April 5, 2021 at 2:29:05 PM UTC-7, Mark cleary wrote:
I have a Garmin 910xt a triathlon type watch but I am a runner and cyclist. It supposed to have barometric altimeter in it right? Well the data is seriously in conflict. I notice all the time when I upload to Garmin connect then Strava the elevation gain is way less than RIde With The GPS. I don't use RWGP but it uploads since I have an account. My Ride with the GPS always shows much more elevation gain. Today I went 53 miles and on Garmin the gain was 1165 and Ride with the GPS it was 1630. That is fair amount of off and usually that is close to what will be. I normally don't track this stuff I live in the flatlands but the data is suspect for sure. More fake news from something. I don't have the watch but the barometric pressure altimeter is dead accurate. The problem I have with my 810 is that for some reason it gives me absolute ridiculous "max altitude" and "min altitude" of 35000 and 15,000 ft. But the change in altitude is correct. |
#3
|
|||
|
|||
More Crazy data
On 4/5/2021 2:29 PM, Mark cleary wrote:
I have a Garmin 910xt a triathlon type watch but I am a runner and cyclist. It supposed to have barometric altimeter in it right? Well the data is seriously in conflict. I notice all the time when I upload to Garmin connect then Strava the elevation gain is way less than RIde With The GPS. I don't use RWGP but it uploads since I have an account. My Ride with the GPS always shows much more elevation gain. Today I went 53 miles and on Garmin the gain was 1165 and Ride with the GPS it was 1630. That is fair amount of off and usually that is close to what will be. I normally don't track this stuff I live in the flatlands but the data is suspect for sure. More fake news from something. Deacon Mark Elevation gain is inherently a tricky subject, and I suspect even more so for a rider in a relatively flat area. Say rider August lives on a route over a mountain pass. The road has a steady uphill grade, which he rides to the summit and back to his house. Pretty much any reasonable elevation-gain calculation strategy will work well for August: Summit Elevation minus house elevation, or elevation differences every 10 seconds accumulated (and throw out negative differences that mean he's going downhill) or lots of variations on those themes. Contrast rider Bertrand who lives in an area that most cyclists would call "flat" though in fact the elevation varies by as much as 20 feet at different places in the county. In fact, the actual elevation is undulating in a very narrow range. Now the choice of elevation-gain calculation starts to matter. Suppose you add up the differences every 10 seconds (again throwing out negative differences). If Bertrand crests a ten-foot-tall hill right in the middle of one of those ten-second intervals, the net elevation difference over that ten seconds might end up positive and count, or negative and get thrown out, and in no case will the height of the "summit" be reflected accurately. It's reasonable to assume that Bertrand is going to miss a fair bit of elevation gain if those undulations are frequent. Now let's grant that the 10-second interval method is a bad method and a straw man. A one-second interval is probably much more realistic for modern GPS systems. That will still miss some elevation gain, but probably not that much. Oh, but wait - what if the undulations are quite small but high frequency. Suppose cyclist Conrad was on a route that went up a half inch in one foot of travel, then down a half inch the next foot, repeatedly, for 10 miles. Again a weird example, this is gonna feel like washboard, but how much elevation "gain" does Conrad experience? Half an inch every two feet for 52,800 feet or 1100 feet of elevation gain. Should we count that as elevation gain on what's an unnaturally flat course otherwise? (Highest point minus lowest point is a half inch!) As for RWGPS, it's not clear to me if RideWithGps is using your GPS elevation data or just your GPS coordinates and then their own internal elevation data for those locations. I would actually expect that if they use their own elevation data, they aren't accumulating elevation every second, but rather "netting out" elevation gain every ?100 feet? or so, or perhaps longer. So all sorts of elevation gain could be missed. As for a GPS device measuring altitude gain, remember that GPS altitude measurement is prone to significant measurement errors, and even though the best GPS devices have barometers that "smooth" out the data, GPS data is going to have tiny random, jiggly errors. Those errors in once-per-second measurements (a guess at frequency) can add up just like Conrad's weird elevation "gain." All that said, I would not expect RWGPS figures to be *higher* than the Garmin figures, but maybe I'm just mis-estimating the magnitude of each issue, for which my illustrative examples are intentionally extreme. Still, I suspect that these are some of the issues that are involved. Finally, there's an inherent problem in the original "question" of elevation gain. Route profiles are probably fractal if we look closely enough. Measure (accurately) many times per second or per foot, and we will accumulate lots of ?superfluous? elevation gain like Conrad. It will get worse as frequency of measurement goes up. [1] In this way, Conrad's example illustrates my central point - we have to decide /what counts/ as elevation gain. Our rough estimates can agree "well enough" for generous values of "enough," but they are never going to agree exactly unless we have a fixed measurement method. [1] Google "How long is the coastline of Britain" to find articles about fractals and Mandelbrot, etc. Mark Janeba |
#4
|
|||
|
|||
More Crazy data
On 4/6/2021 7:24 PM, Mark J. wrote:
On 4/5/2021 2:29 PM, Mark cleary wrote: I have a Garmin 910xt a triathlon type watch but I am a runner and cyclist. It supposed to have barometric altimeter in it right? Well the data is seriously in conflict. I notice all the time when I upload to Garmin connect then Strava the elevation gain is way less than RIde With The GPS. I don't use RWGP but it uploads since I have an account. My Ride with the GPS always shows much more elevation gain. Today I went 53 miles and on Garmin the gain was 1165 and Ride with the GPS it was 1630. That is fair amount of off and usually that is close to what will be. I normally don't track this stuff I live in the flatlands but the data is suspect for sure. More fake news from something. Deacon Mark Elevation gain is inherently a tricky subject, and I suspect even more so for a rider in a relatively flat area. Say rider August lives on a route over a mountain pass.Â* The road has a steady uphill grade, which he rides to the summit and back to his house. Pretty much any reasonable elevation-gain calculation strategy will work well for August: Summit Elevation minus house elevation, or elevation differences every 10 seconds accumulated (and throw out negative differences that mean he's going downhill) or lots of variations on those themes. Contrast rider Bertrand who lives in an area that most cyclists would call "flat" though in fact the elevation varies by as much as 20 feet at different places in the county.Â* In fact, the actual elevation is undulating in a very narrow range.Â* Now the choice of elevation-gain calculation starts to matter.Â* Suppose you add up the differences every 10 seconds (again throwing out negative differences).Â* If Bertrand crests a ten-foot-tall hill right in the middle of one of those ten-second intervals, the net elevation difference over that ten seconds might end up positive and count, or negative and get thrown out, and in no case will the height of the "summit" be reflected accurately.Â* It's reasonable to assume that Bertrand is going to miss a fair bit of elevation gain if those undulations are frequent. Now let's grant that the 10-second interval method is a bad method and a straw man.Â* A one-second interval is probably much more realistic for modern GPS systems.Â* That will still miss some elevation gain, but probably not that much. Oh, but wait - what if the undulations are quite small but high frequency.Â* Suppose cyclist Conrad was on a route that went up a half inch in one foot of travel, then down a half inch the next foot, repeatedly, for 10 miles.Â* Again a weird example, this is gonna feel like washboard, but how much elevation "gain" does Conrad experience? Half an inch every two feet for 52,800 feet or 1100 feet of elevation gain.Â* Should we count that as elevation gain on what's an unnaturally flat course otherwise? (Highest point minus lowest point is a half inch!) As for RWGPS, it's not clear to me if RideWithGps is using your GPS elevation data or just your GPS coordinates and then their own internal elevation data for those locations.Â* I would actually expect that if they use their own elevation data, they aren't accumulating elevation every second, but rather "netting out" elevation gain every ?100 feet? or so, or perhaps longer.Â* So all sorts of elevation gain could be missed. As for a GPS device measuring altitude gain, remember that GPS altitude measurement is prone to significant measurement errors, and even though the best GPS devices have barometers that "smooth" out the data, GPS data is going to have tiny random, jiggly errors.Â* Those errors in once-per-second measurements (a guess at frequency) can add up just like Conrad's weird elevation "gain." All that said, I would not expect RWGPS figures to be *higher* than the Garmin figures, but maybe I'm just mis-estimating the magnitude of each issue, for which my illustrative examples are intentionally extreme. Still, I suspect that these are some of the issues that are involved. Finally, there's an inherent problem in the original "question" of elevation gain.Â* Route profiles are probably fractal if we look closely enough.Â* Measure (accurately) many times per second or per foot, and we will accumulate lots of ?superfluous? elevation gain like Conrad.Â* It will get worse as frequency of measurement goes up. [1] In this way, Conrad's example illustrates my central point - we have to decide /what counts/ as elevation gain.Â* Our rough estimates can agree "well enough" for generous values of "enough," but they are never going to agree exactly unless we have a fixed measurement method. [1] Google "How long is the coastline of Britain" to find articles about fractals and Mandelbrot, etc. Mark Janeba Nicely done. About halfway through that, I decide to bring up fractals and coastlines. You beat me to it. -- - Frank Krygowski |
#5
|
|||
|
|||
More Crazy data
Am 07.04.2021 um 01:24 schrieb Mark J.:
As for a GPS device measuring altitude gain, remember that GPS altitude measurement is prone to significant measurement errors, and even though the best GPS devices have barometers that "smooth" out the data, GPS data is going to have tiny random, jiggly errors.Â* Those errors in once-per-second measurements (a guess at frequency) can add up just like Conrad's weird elevation "gain. GPS-based altitude gain in flat area is dominated by measurement errors. After one hour Stand-up padlling on a lake, my mobile phone tells me of an altitude gain around 20-40m. This is why Strava recommends to use a map-based elevation gain: take the x,y coordinates from GPS, align the route to road travel where meaninguful nd calculate elevation gain from the map altitude data. Even this map-based elevation gain gives a significant error on my way to work (but apparently the algorithm has been improved): In 2017, Strava estimates 52m altitude gain for my route home from work, including on non-existing hill of almost 20m altitude after 4.5km where there is nothing https://www.strava.com/activities/1025358538. In 2021, Strave estimates 20m altitude gain for the same route https://www.strava.com/activities/4949599170 The fake hill is gone, and the "sprinting dip" after 10km is measurable as downhill 3-4m at 4% grade followed by a 2% climb of 2m, just as my estimations by altitude comparisons with the parallel railroad track are (1-2m above track level to 2m below track level, to at track lavel). All the precision I've been looking for in the last years has finally arrived. |
#6
|
|||
|
|||
More Crazy data
On Tuesday, April 6, 2021 at 4:24:42 PM UTC-7, Mark J. wrote:
On 4/5/2021 2:29 PM, Mark cleary wrote: I have a Garmin 910xt a triathlon type watch but I am a runner and cyclist. It supposed to have barometric altimeter in it right? Well the data is seriously in conflict. I notice all the time when I upload to Garmin connect then Strava the elevation gain is way less than RIde With The GPS. I don't use RWGP but it uploads since I have an account. My Ride with the GPS always shows much more elevation gain. Today I went 53 miles and on Garmin the gain was 1165 and Ride with the GPS it was 1630. That is fair amount of off and usually that is close to what will be. I normally don't track this stuff I live in the flatlands but the data is suspect for sure. More fake news from something. Deacon Mark Elevation gain is inherently a tricky subject, and I suspect even more so for a rider in a relatively flat area. Say rider August lives on a route over a mountain pass. The road has a steady uphill grade, which he rides to the summit and back to his house. Pretty much any reasonable elevation-gain calculation strategy will work well for August: Summit Elevation minus house elevation, or elevation differences every 10 seconds accumulated (and throw out negative differences that mean he's going downhill) or lots of variations on those themes. Contrast rider Bertrand who lives in an area that most cyclists would call "flat" though in fact the elevation varies by as much as 20 feet at different places in the county. In fact, the actual elevation is undulating in a very narrow range. Now the choice of elevation-gain calculation starts to matter. Suppose you add up the differences every 10 seconds (again throwing out negative differences). If Bertrand crests a ten-foot-tall hill right in the middle of one of those ten-second intervals, the net elevation difference over that ten seconds might end up positive and count, or negative and get thrown out, and in no case will the height of the "summit" be reflected accurately. It's reasonable to assume that Bertrand is going to miss a fair bit of elevation gain if those undulations are frequent. Now let's grant that the 10-second interval method is a bad method and a straw man. A one-second interval is probably much more realistic for modern GPS systems. That will still miss some elevation gain, but probably not that much. Oh, but wait - what if the undulations are quite small but high frequency. Suppose cyclist Conrad was on a route that went up a half inch in one foot of travel, then down a half inch the next foot, repeatedly, for 10 miles. Again a weird example, this is gonna feel like washboard, but how much elevation "gain" does Conrad experience? Half an inch every two feet for 52,800 feet or 1100 feet of elevation gain. Should we count that as elevation gain on what's an unnaturally flat course otherwise? (Highest point minus lowest point is a half inch!) As for RWGPS, it's not clear to me if RideWithGps is using your GPS elevation data or just your GPS coordinates and then their own internal elevation data for those locations. I would actually expect that if they use their own elevation data, they aren't accumulating elevation every second, but rather "netting out" elevation gain every ?100 feet? or so, or perhaps longer. So all sorts of elevation gain could be missed. As for a GPS device measuring altitude gain, remember that GPS altitude measurement is prone to significant measurement errors, and even though the best GPS devices have barometers that "smooth" out the data, GPS data is going to have tiny random, jiggly errors. Those errors in once-per-second measurements (a guess at frequency) can add up just like Conrad's weird elevation "gain." All that said, I would not expect RWGPS figures to be *higher* than the Garmin figures, but maybe I'm just mis-estimating the magnitude of each issue, for which my illustrative examples are intentionally extreme. Still, I suspect that these are some of the issues that are involved. Finally, there's an inherent problem in the original "question" of elevation gain. Route profiles are probably fractal if we look closely enough. Measure (accurately) many times per second or per foot, and we will accumulate lots of ?superfluous? elevation gain like Conrad. It will get worse as frequency of measurement goes up. [1] In this way, Conrad's example illustrates my central point - we have to decide /what counts/ as elevation gain. Our rough estimates can agree "well enough" for generous values of "enough," but they are never going to agree exactly unless we have a fixed measurement method. [1] Google "How long is the coastline of Britain" to find articles about fractals and Mandelbrot, etc. Mark Janeba The one problem with barometric altimeters is there can be two sources of errors: 1. When a front moves through the barometric pressure changes and you can show errors. 2. As you point out the sampling rate is important for accuracy. Usually not for absolute altitude for which they are surprisingly accurate (Over the years I've had perhaps a dozen different barometric pressure altimeters and they are all in very close agreement.) but the sampling rate really does screw up the rate-of-climb or grade calculations. On all of my bike computer type altimeters they show 12% in several spots and all are in agreement. The Garmin usually shows 10% in these same spots and occasionally 11%. As for using maps to calculate altitude. What makes you think that these altitudes weren't measured with the standard aircraft barometric pressure altimeter? |
#7
|
|||
|
|||
More Crazy data
On Wednesday, April 7, 2021 at 2:26:12 AM UTC-7, Rolf Mantel wrote:
Am 07.04.2021 um 01:24 schrieb Mark J.: As for a GPS device measuring altitude gain, remember that GPS altitude measurement is prone to significant measurement errors, and even though the best GPS devices have barometers that "smooth" out the data, GPS data is going to have tiny random, jiggly errors. Those errors in once-per-second measurements (a guess at frequency) can add up just like Conrad's weird elevation "gain. GPS-based altitude gain in flat area is dominated by measurement errors. After one hour Stand-up padlling on a lake, my mobile phone tells me of an altitude gain around 20-40m. This is why Strava recommends to use a map-based elevation gain: take the x,y coordinates from GPS, align the route to road travel where meaninguful nd calculate elevation gain from the map altitude data. Even this map-based elevation gain gives a significant error on my way to work (but apparently the algorithm has been improved): In 2017, Strava estimates 52m altitude gain for my route home from work, including on non-existing hill of almost 20m altitude after 4.5km where there is nothing https://www.strava.com/activities/1025358538. In 2021, Strave estimates 20m altitude gain for the same route https://www.strava.com/activities/4949599170 The fake hill is gone, and the "sprinting dip" after 10km is measurable as downhill 3-4m at 4% grade followed by a 2% climb of 2m, just as my estimations by altitude comparisons with the parallel railroad track are (1-2m above track level to 2m below track level, to at track lavel). All the precision I've been looking for in the last years has finally arrived. On courses where the grade never exceeds 5% I never count that as climbing because while rolling waves can easily add up to your altitude errors it isn't as if you're working for it. |
#8
|
|||
|
|||
More Crazy data
Am 07.04.2021 um 16:35 schrieb Tom Kunich:
As for using maps to calculate altitude. What makes you think that these altitudes weren't measured with the standard aircraft barometric pressure altimeter? I don't care how the maps were created (my uncle is a retired geodesist, he would know if I'd ask him). My point was that GPS of mobile phone quality sucks for "altitude gain" calculations. Rolf |
#9
|
|||
|
|||
More Crazy data
On 4/7/2021 10:35 AM, Tom Kunich wrote:
The one problem with barometric altimeters is there can be two sources of errors: 1. When a front moves through the barometric pressure changes and you can show errors. 2. As you point out the sampling rate is important for accuracy. Usually not for absolute altitude for which they are surprisingly accurate (Over the years I've had perhaps a dozen different barometric pressure altimeters and they are all in very close agreement.) but the sampling rate really does screw up the rate-of-climb or grade calculations. I'm not much into riding data. But long ago, I was given a Nike watch (Lance Armstrong model) with a barometric altimeter and electronic compass. I had some fun with it, but it lost its mind after a few years. The altimeter began acting as if I were riding upward in a hot air balloon. Several attempts at disassembly yielded no fix. It now sits in my workshop hoping for a miracle. -- - Frank Krygowski |
#10
|
|||
|
|||
More Crazy data
On 4/7/2021 2:26 AM, Rolf Mantel wrote:
Am 07.04.2021 um 01:24 schrieb Mark J.: As for a GPS device measuring altitude gain, remember that GPS altitude measurement is prone to significant measurement errors, and even though the best GPS devices have barometers that "smooth" out the data, GPS data is going to have tiny random, jiggly errors.Â* Those errors in once-per-second measurements (a guess at frequency) can add up just like Conrad's weird elevation "gain. GPS-based altitude gain in flat area is dominated by measurement errors. After one hour Stand-up padlling on a lake, my mobile phone tells me of an altitude gain around 20-40m. I recall owning an Avocet 50 bicycle computer with a barometric pressure based altimeter. It was not great. The GPS apps that determine your XY position then look up the altitude are very accurate. I have one mobile app that displays 3 altitudes at once, GPS-based, map based, and barometric pressure based. They are way different. This is why Strava recommends to use a map-based elevation gain: take the x,y coordinates from GPS, align the route to road travel where meaninguful nd calculate elevation gain from the map altitude data. Even this map-based elevation gain gives a significant error on my way to work (but apparently the algorithm has been improved): Isn't there an app that uses location based altitude? It would use more mobile data to grab the elevation based on longitude and latitude but it would be very accurate. |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
LETTER - This cycling thing is a crazy idea. A crazy good one | Simon Mason[_6_] | UK | 9 | July 18th 20 05:17 PM |
Crazy day | Davey Crockett[_5_] | Racing | 5 | July 10th 12 01:40 PM |
Bicycle-induced psychotropic effects, or Hey, that crazy dude really is crazy | [email protected] | Racing | 7 | February 8th 06 03:17 PM |
Am I crazy like a fox, or just plain crazy? | Brian Walker | General | 9 | September 27th 05 05:54 AM |
Am I crazy?? | leela | Australia | 11 | July 2nd 04 11:41 AM |