jmvdigital

Just an update… I’ve been talking with Garmin Support about my findings. They have confirmed that they can’t explain it yet and no one else has reported this yet. They are transferring me to work with their engineering team. Here’s a comparison showing multiple bike rides and what the Oregon 750 shows depending on whether you are viewing the Activity/FIT or the Track/GPX on the device…

I don't understand why you'd connect your garmin to provide the location for another app when your phone has a perfectly capable GPS chip inside. I doubt that the bluetooth connection draws any less power than the built-in GPS. Is it just for extra sensor data? You don’t connect your Garmin to your phone so that the phone can use the Garmin’s GPS. It doesn’t work that way. The Oregon 7xx lets you connect to your phone via Bluetooth to sync to their Garmin Connect app, get the live weather radar, and allow the (also currently broken) Geocaching Live feature. So anytime (at least for me) that my Garmin has Bluetooth on and is connected to my phone, my phone shows my location as a couple hundred miles off the coast of Spain, even though I’m in Colorado. As soon as I turn off Bluetooth, my phone goes back to showing my proper location. It’s a bug.

Just wanted to follow up about the iPhone Bluetooth bug, where your phone will show your location as being thousands of miles off if you have your Oregon 7xx on and connected via Bluetooth. I went round and round with Garmin support on it and they conceded that they are "looking into it" and recommend not connecting the two via Bluetooth for now if you need to use any location-based app on your phone (e.g., Strava, Yelp, Google Maps, Maplets, etc).

In the example I just posted screenshots for, there are 9,833 points over a 14.8 mile track, with a total elapsed time of 2:43:51. By my math, that is 9,831 seconds. So it was recording at roughly once a second on average. My Oregon 750 is set to record on "auto - most often" so I realize there is some variability in there. Does that change your answer? And I absolutely get that the device does not necessarily record every measurement it takes while you’re active. That recorded frequency is controlled by whatever you set the device to. However, the core issue that I’ve been trying to get at is how the heck the device is showing 2 different elevations for the basic same set of RECORDED data. The FIT file and the GPX file only contain the recorded points at the frequency you set, correct? They don’t contain that native data with EVERY point the device calculated. So they only contain the data at the frequency you set, which is likely lower frequency than what the device is tracking during the activity. We all agree on that, correct? So I believe we can basically ignore the device’s native tracking, because that info is not saved in the FIT or GPX file once you stop and save your track/activity. I’m not talking about viewing the trip computer during an activity and comparing it to the saved GPX file later. I’m talking about comparing two sets of recorded data long after the activity is over. Both files contain the same number of points (9,833 in this example), so the frequency of those points is irrelevant (it’s not like the FIT file has twice as many points, so the elevation resolution is much higher). I’m NOT questioning whether the total elevation would be different for a track recorded once every 10 seconds to one recorded every 1 second. If you’d like, I can share the FIT and GPX file and you can see if you see any meaningful difference in the dataset that would account for a 328’ foot elevation difference. If you can’t, I believe I have found a bug.

Did you not even bother to read my detailed post above? I thought I explained what is going on very clearly. The right answer is: both numbers are correct. They just answer slightly different questions. Yes, except that’s not what’s happening. Did you not read that when I import both the FIT and GPX into Basecamp, both read almost the same? It’s only when reading the FIT file on the device is the elevation way off. If it’s as you say, that the GPS device does not have any filter and thus over-estimates what is basically the same raw data… then why does it not do this consistently with an Activity and a track record? And honestly, it seems a bit much for it to over-estimating by 328’ out of only 2,100’ total. PS: Is there some way to put your theory to an actual test? Is there a tool that will read a FIT and GPX file and apply NO filtering? Which I can then compare to Basecamp? I couldn’t find any info that Basecamp does any default filtering of track data. If it does, it’s consistent between the GPX and FIT files.

FWIW, I have another example. This time I noticed that there is a difference in what the total elevation the Oregon states when viewing a saved FIT/Activity file vs. a GPX track. This could be the root of the original discrepancy I noticed. On this particular ride, the 2096’ ascent number appears to be the correct one. I compared with a buddy who was also recording the ride, and I had recorded it on Strava on my phone (which I know does it’s own elevation corrections, but it was 1966’ total ascent). The 2424’ is not correct. Furthermore, I imported both the FIT and GPX files into Basecamp and they both show the same ascent at 2096’. Interestingly, the files do show a 3’ different in max elevation and total descent, and an 8-second difference in elapsed time. While those are teeny tiny difference, it does point to the fact that there is some slightly processing difference in how it creates an Activity/FIT file vs a GPX track. Also notice in the device screenshots that the mileage and max elevation numbers don’t match (and don’t match what Basecamp says). I also find it interesting that despite being the more robust file type, the FIT file screen on the Oregon shows far less data than viewing the GPX. FIT file screenshot: GPX file screenshot I guess the moral of the story is for now that there is some sort of calculation/display bug, and don’t rely on the device-displayed elevation numbers for an Activity file.

FWIW, after upgrading the Oregon 7xx to fw 2.60 and upgrading iOS to 9.3.4, I haven’t noticed this issue again. No idea bout iOS 10 Beta though.

I don’t think any of us are asking for absolute accuracy in elevation. I’m far more concerned with consistency and total elapsed elevation changes on a track.

Basecamp shows moving and stopped time. You can see it in the screenshot I posted. I've never used the auto-pause feature. Hmmm. It appears the Win and Mac Basecamp are different.

I see. You’re just talking about trimming the tracklog. I envisioned "filtering" to be some sort of data massage that smoothes the track, removes stops, etc. Red90, I may as well take this topic totally off the rails and get your input on auto-pause while we’re at it. I initially had it turned on, but found that even with the minimum 1.5 mph setting, it was pausing my track while I hike-a-biked steep sections or had to walk because I was beat. So I would end up with unrecorded gaps when viewing the tracklog on a map. So I turned it off, and quite frankly, don’t see the point of it. With auto-pause off, Garmin Connect and Strava both still seem to calculate moving time and elapsed time just fine. Basecamp only appears to show elapsed time anyway.

My suggestion is to record in auto-most and filter the data later. This means you don't lose information especially on location and can make intelligent judgements to filter for determining elevation gain. This is my newbie coming out, but I’m not sure what that filtering would look like, how to do it, or why it helps? Can you elaborate a little bit? I’m assuming the Garmin Connect and Strava both do their own proprietary filtering, right? FWIW, I usually leave the device on, without recording, while I’m getting the rest of my stuff ready. And then only start recording once ready to get moving. I have not noticed any initial elevation jumps in my track, but then again, your example is pretty slight, so I’m not sure if I would notice that or not. As for exact accuracy, I compared two recent tracks on the same trails and found the same high point was recorded within 25’ of each other which I think is pretty good considering both tracks had elevation gains of 5500’ and 26 miles recorded between them.

Look here: Setup > Tracks > Advanced Setup > Trip Recording > [When Tracking or Always] I’m not sure how that helps. If I’m recording a track, the trip computer is active with either setting.

Thread side topic: Red90, if you're saying a high interval track log (i.e.,1-sec interval) will lead to erroneously high elevation gains... do you have a recommended interval for the best accuracy? I primarily track my mountain bike rides, which can gain and lose altitude quickly, along with fast turns and switchbacks. I can lose 1,000'+ in under 10 minutes. On paper a 1-sec interval would seem like the most accurate to capture all the nuance and most accurate distance and elevation gain. As for auto-calibration, what is your recommendation? It seems like as long as the unit is on long enough prior to recording, that elevation accuracy should be good? How long does that calibration take? Is there a better "best practice" ... Say you arrive at a trailhead with an unknown exact altitude or pressure? Is it better to leave calibration off and know that while your exact elevation reading will likely be off, the relative elevation gain/loss will be more accurate?

True. But I don’t think this has to do with what I’m seeing. That would be more of an issue for the overall recorded accuracy of the elevation gain, not why a single FIT/GPX file shows a different total on the device than on the computer. That said, from what I’ve read about the auto-calibration is that it slowly progresses the barometric elevation toward the GPS elevation over up to a 30 minute period. I’m not sure of the best way to handle it for accuracy, unless like you say, you turn it on well before your trip start, but you’d have to be stationary at the trailhead for that to work. If you’re driving to your destination, your elevation will be changing the whole way and won’t really help the auto-calibration, will it?

This makes sense, but makes a big assumption that the device saves this 1-sec raw data somewhere (or at the very least, a summary of it), in addition to the smoothed FIT/GPX file that is exported when you save an activity. If it is saving that 1-sec raw data, it would then be reading from that, even when you go back and review a previous activity’s saved FIT file. Correct? Why is there a recording interval setting at all on these modern devices? The FIT/GPX files are still so tiny compared to mapping data files and the size of internal storage. The FIT file from this ride is only 63kb. If it was doing 1-sec recording that would still only be like 315kb. Is there any down side to just setting it to 1-sec intervals then? The data will be smoothed by Garmin Connect or Strava anyway.

I don’t know how to decouple the trip computer from the recorded track. I’m viewing the "activity" file on my Oregon, and viewing the same FIT file on Basecamp/Strava/GC… the trip computer shouldn’t have anything to do with any of it, should it? Oh but I do see what you’re saying about the GPSr sampling more locations than is recorded to the track! That makes total sense. But then why when viewing the saved track/activity does it still show the higher elevation? Wouldn’t it show the recorded track elevation? If it is showing the raw GPS samples versus the recorded track, then where does it store those totals, because I can’t figure it out. I suppose this brings me to a question about what to set my recording interval to to get the most accurate track. Losing 200’ of elevation gain is kind of a big deal for me. I currently have it set to "Auto - Most Often". Auto-pause is off. For this particular ride, total time was 2:53 hr, 16.2 miles, 1895 track points… which averages to a point every 5-6 seconds.

Sorry guys, I guess I should have been more explicit… This is NOT a matter of online elevation correction by the various sites. I am very well versed in what Garmin Connect and Strava do to "correct" elevation data. This is what led me to getting a Garmin with a barometric altimeter. Got tired of the inaccuracies of Strava’s elevation corrections. If I view that saved "activity" on the device today it still says total ascent is 3425’. But importing the same FIT file (straight from Oregon via USB) into Basecamp or Strava shows 3235’. Basecamp does absolutely no elevation smoothing or correction that I’m aware of. I’m trying to figure out why the device itself displays a different elevation total for the same file than any other software.

I found a curious mismatch in data yesterday and want to see if anyone else has noticed this… While recording a bike ride on my Oregon 750t, the total elevation gain (ascent) recorded and shown on the device screen was 3425’. However, after downloading the FIT (and GPX) files to Basecamp, Garmin Connect, and Strava… all say the track total ascent is 3235’. Not sure why there is a ~200’ difference between what the Oregon screen said and what the actual track data shows. I have seen reports from other Garmin devices that the FIT file elevation output depends on the altimeter calibration setting, and that even changing the calibration mode at the end of a recorded activity (before saving the track), can change the recorded elevation profile. My guess is that the device records the GPS elevation and barometric elevation simultaneously and then does the averaging or tossing of one of the data sets at the end right as you save the track/activity. Can anyone confirm? For example, I have my Oregon set to "continuous calibration", while in theory, the device display could be using only the barometric elevation to show calculated ascent, until the very end when the track/activity is saved and the GPS and baro data are averaged and exported, thus losing my 200’ of ascent.

Walts, there appears to be pretty good filtering capability.

I noticed this as well. The screen "dots" are there for a second and then disappear. The only screen I can see while caching is the map. I did find that if you tap the top dashboard, it brings up the cache details and logs screen.

Sherminator18, I noticed this same issue today as well! With Bluetooth on and the Oregon 750t connected to my phone, my iPhone put my GPS location somewhere in Africa. After turning off Bluetooth, my actual location was correct on my phone again. This is a massive issue if you’re using any location-based apps on your phone at the same time your GPS is on (e.g., Strava). EDIT: FWIW, I submitted these two bugs and a couple of requests to Garmin support. I’m sure that was pointless, but whatevs.

Yeah, I think we’re all on the same page now. Without using a USB cable and downloading a traditional GPX/PQ, you can only get "light" or header lists wirelessly onto the Oregon 7xx. It will load your PQ wirelessly, but not the full data set, only the list of geocache names. On a side note, I discovered what I think is a bug today. I was out on a mountain bike ride and recording my track… I noticed that my track had some "gaps" in it from the auto-pause feature. So I turned off auto-pause and kept riding. A couple miles later, I realized that it had stopped recording my track, even though it was still technically in "record" mode. My current position was linked to the last spot it tracked (when I changed the setting) by the dreaded straight line. The straight line connected to my current position wherever I moved, without recording. The only thing I could do was stop that track and start recording a new one. So I lost a bunch of data in the middle of my ride. Just FYI. Don’t change settings while recording!

I have my Geocaching account authorized properly to my Oregon 750t. I have a single PQ running successfully. However, I’m not seeing any way to get the PQ results onto the Oregon wirelessly. The "live" map query refresh is working where it will pull the closest 25 caches. I also found it important to note that if you do the "live" map query, it will only download the geocache names and basic info, but it does NOT download the geocache descriptions and other detailed info. It only does that on the fly as you click on an individual geocache. Are you finding that as well? This is important to note, because if you do a couple of live queries for areas where you’ll be camping (for example) and you don’t have cell service there… you’re screwed. I don’t see any way to force the Oregon to download all the geocache info up front like is done in a traditional PQ. I figured it out! I found the "Geocache List" menu item buried within the System>Geocaching>Geocaching Live>Geocache Lists menu (Confusingly, not in the Geocaches app in the "app drawer"). Interestingly, the sync failed using only the Bluetooth connection to my phone’s Garmin Connect app. But it did sync properly after turning on wifi. EDIT: So it appears that syncing the PQ straight to the Oregon 7xx does the same thing as the map-based live query… there does not appear to be any geocache descriptions/logs/hints, only the basic name/d/t. What gives? Am I doing something wrong? If I manually download the PQ GPX file, all of that info is in there properly. EDIT #2: After deleting all "live geocache" data (every geocache on my device), I confirmed there were no geocaches, then went back to the Geocache List and re-downloaded one of my PQs. Sadly, the list is indeed literally only a list. You must have internet access (through your phone) in order for the Oregon to display a geocache’s detailed info when out in the field. In my opinion, this makes the live geocaching functionality fairly crippled. If you’ll be in an area with no cell service, you’ll need to run and download a standard PQ with a GPX file to get all the info in there. Someone correct me if I’m wrong.

yogazoo… You mentioned earlier in this thread… I have my Geocaching account authorized properly to my Oregon 750t. I have a single PQ running successfully. However, I’m not seeing any way to get the PQ results onto the Oregon wirelessly. The "live" map query refresh is working where it will pull the closest 25 caches. I also found it important to note that if you do the "live" map query, it will only download the geocache names and basic info, but it does NOT download the geocache descriptions and other detailed info. It only does that on the fly as you click on an individual geocache. Are you finding that as well? This is important to note, because if you do a couple of live queries for areas where you’ll be camping (for example) and you don’t have cell service there… you’re screwed. I don’t see any way to force the Oregon to download all the geocache info up front like is done in a traditional PQ.