Discussion
upsidedownmark said:
Network data / signal doesn't come into it - I'm talking about the difference between the time the GPS hardware determines a fix, and the time that fix gets delivered to the strava app within the phone. On an iPhone, that fix only gets timestamped when it gets to the app.
The fixes are then uploaded to strava which calculates the segments etc by looking at where you were and when; if the when is off then you're looking at some decent skew in the results: for example if the fix is 1/2 a sec late at 30mph, it's some 7m late. If it was a consistent 1/2 sec lag, that wouldn't matter, but when the lag varies then you get spikes. This is why stuff like harry's laptimer works far better with external GPS sources that communicate via their own API and provide fixes that are timestamped at the source (thus it doesn't matter how long the delivery takes)
Bear in mind that the iphone is far from a real-time env as far as apps are concerned: it is task switching / running apps at a pretty low priority. For general computing use I'd agree, for iphones, not so much
WRT GPS accuracy, you have a point, but: GPS error is pretty systematic. Therefore the accuracy of the fix might not be that great, but the consistency is much better. Consistent inaccuracy won't hurt, inconsistent accuracy will. GPS will generally be 'off' by a steady amount in any given location. At a simple level this is how DGPS/augmentation systems work - there is a GPS receiver at an accurately known location that compares it's calculated pos to the known pos and transmits a correction factor.
Also neatly demonstrated by my logging my commute on my iphone: I'm damn sure I didn't hit 100kph on a fixie - no such glitch on the garmin
Interesting stuff! Thanks The fixes are then uploaded to strava which calculates the segments etc by looking at where you were and when; if the when is off then you're looking at some decent skew in the results: for example if the fix is 1/2 a sec late at 30mph, it's some 7m late. If it was a consistent 1/2 sec lag, that wouldn't matter, but when the lag varies then you get spikes. This is why stuff like harry's laptimer works far better with external GPS sources that communicate via their own API and provide fixes that are timestamped at the source (thus it doesn't matter how long the delivery takes)
Bear in mind that the iphone is far from a real-time env as far as apps are concerned: it is task switching / running apps at a pretty low priority. For general computing use I'd agree, for iphones, not so much
WRT GPS accuracy, you have a point, but: GPS error is pretty systematic. Therefore the accuracy of the fix might not be that great, but the consistency is much better. Consistent inaccuracy won't hurt, inconsistent accuracy will. GPS will generally be 'off' by a steady amount in any given location. At a simple level this is how DGPS/augmentation systems work - there is a GPS receiver at an accurately known location that compares it's calculated pos to the known pos and transmits a correction factor.
Also neatly demonstrated by my logging my commute on my iphone: I'm damn sure I didn't hit 100kph on a fixie - no such glitch on the garmin
upsidedownmark said:
Network data / signal doesn't come into it - I'm talking about the difference between the time the GPS hardware determines a fix, and the time that fix gets delivered to the strava app within the phone. On an iPhone, that fix only gets timestamped when it gets to the app.
The fixes are then uploaded to strava which calculates the segments etc by looking at where you were and when; if the when is off then you're looking at some decent skew in the results: for example if the fix is 1/2 a sec late at 30mph, it's some 7m late. If it was a consistent 1/2 sec lag, that wouldn't matter, but when the lag varies then you get spikes. This is why stuff like harry's laptimer works far better with external GPS sources that communicate via their own API and provide fixes that are timestamped at the source (thus it doesn't matter how long the delivery takes)
Bear in mind that the iphone is far from a real-time env as far as apps are concerned: it is task switching / running apps at a pretty low priority. For general computing use I'd agree, for iphones, not so much
WRT GPS accuracy, you have a point, but: GPS error is pretty systematic. Therefore the accuracy of the fix might not be that great, but the consistency is much better. Consistent inaccuracy won't hurt, inconsistent accuracy will. GPS will generally be 'off' by a steady amount in any given location. At a simple level this is how DGPS/augmentation systems work - there is a GPS receiver at an accurately known location that compares it's calculated pos to the known pos and transmits a correction factor.
Also neatly demonstrated by my logging my commute on my iphone: I'm damn sure I didn't hit 100kph on a fixie - no such glitch on the garmin
Okay, but are you sure that's the case? The locations API signals the app as soon as the location changes and executes (for example) the didUpdateLocations() method in the apps code whereby it can be timestamped etc. You are saying that there is half a second of latency between the location fix updating and the call back executing? The fixes are then uploaded to strava which calculates the segments etc by looking at where you were and when; if the when is off then you're looking at some decent skew in the results: for example if the fix is 1/2 a sec late at 30mph, it's some 7m late. If it was a consistent 1/2 sec lag, that wouldn't matter, but when the lag varies then you get spikes. This is why stuff like harry's laptimer works far better with external GPS sources that communicate via their own API and provide fixes that are timestamped at the source (thus it doesn't matter how long the delivery takes)
Bear in mind that the iphone is far from a real-time env as far as apps are concerned: it is task switching / running apps at a pretty low priority. For general computing use I'd agree, for iphones, not so much
WRT GPS accuracy, you have a point, but: GPS error is pretty systematic. Therefore the accuracy of the fix might not be that great, but the consistency is much better. Consistent inaccuracy won't hurt, inconsistent accuracy will. GPS will generally be 'off' by a steady amount in any given location. At a simple level this is how DGPS/augmentation systems work - there is a GPS receiver at an accurately known location that compares it's calculated pos to the known pos and transmits a correction factor.
Also neatly demonstrated by my logging my commute on my iphone: I'm damn sure I didn't hit 100kph on a fixie - no such glitch on the garmin
With your fixie example, I think if you download your GPX data from the website, and look at in something like Adze, you will probably see that the location simply jumps due to intermittently poor fix in the data. The Garmin most likely has a lot stronger fix with a lower noise/error rate, due to better hardware design/packaging constraints.
Erm.. yes...
That's not a hard figure, obviously. Nor am I suggesting that's always the case; however I believe it's a realistic order of magnitude estimate for what *can* happen. I'm sure most people have had the phone 'glitch' - not respond for a while before responding to user input. It's that kinda use case. I have no doubt if I look at the gpx data I'll see a jump - what causes that jump is kinda hard to prove. I believe timing is the more significant factor, but undoubtedly signal issues are some part of it too - we have no way of answering how much to each.
WRT the chip, it's a qualcomm in a 4S apparently - no reason it should be less accurate than any other; some of the earlier models shared the wifi antenna, so perhaps weren't so good..
http://www.anandtech.com/show/4971/apple-iphone-4s...
I don't know how familiar you are with how multiprocessing (apologies if this is patronising) - with the caveat that I don't know how the iOS scheduler works / prioritises, here's a best-guess representation of how the process goes:
1) GPS Chip does it's stuff and determines a fix: Pulls up an interrupt to signal the OS that it has some data.
2) Interrupt handler pulls the data off the chip and puts it in a memory location somewhere
<iOS goes off and does other stuff that's higher priority, picks its nose etc>
3) the location services process gets scheduled, does some stuff
<iOS goes off and does other stuff that's higher priority, picks its nose etc>
4) We loop around scheduling 3 a bunch of times until it's done all its interpolation, smoothing, etc., and kicked the strava callback to tell it there's data
<iOS goes off and does other stuff that's higher priority, picks its nose etc>
5) Strava gets a shot at the processor, and deals with the data, timestamping it (again this could be quite an involved process that gets sidelined a few times.
Without knowing how iOS sets up the priorities, I'm going to make a wild-assed guess that apps run pretty far down the queue. Anything hardware related gets priority, as do OS processes, and so on - it's not that far fetched to me that stuff like moving around cell towers and the like could deprive the running apps of meaningful processor time to create a lag in that sort of order of magnitude. For my money, that's far more likely than the GPS position jittering that significantly.
That's not a hard figure, obviously. Nor am I suggesting that's always the case; however I believe it's a realistic order of magnitude estimate for what *can* happen. I'm sure most people have had the phone 'glitch' - not respond for a while before responding to user input. It's that kinda use case. I have no doubt if I look at the gpx data I'll see a jump - what causes that jump is kinda hard to prove. I believe timing is the more significant factor, but undoubtedly signal issues are some part of it too - we have no way of answering how much to each.
WRT the chip, it's a qualcomm in a 4S apparently - no reason it should be less accurate than any other; some of the earlier models shared the wifi antenna, so perhaps weren't so good..
http://www.anandtech.com/show/4971/apple-iphone-4s...
I don't know how familiar you are with how multiprocessing (apologies if this is patronising) - with the caveat that I don't know how the iOS scheduler works / prioritises, here's a best-guess representation of how the process goes:
1) GPS Chip does it's stuff and determines a fix: Pulls up an interrupt to signal the OS that it has some data.
2) Interrupt handler pulls the data off the chip and puts it in a memory location somewhere
<iOS goes off and does other stuff that's higher priority, picks its nose etc>
3) the location services process gets scheduled, does some stuff
<iOS goes off and does other stuff that's higher priority, picks its nose etc>
4) We loop around scheduling 3 a bunch of times until it's done all its interpolation, smoothing, etc., and kicked the strava callback to tell it there's data
<iOS goes off and does other stuff that's higher priority, picks its nose etc>
5) Strava gets a shot at the processor, and deals with the data, timestamping it (again this could be quite an involved process that gets sidelined a few times.
Without knowing how iOS sets up the priorities, I'm going to make a wild-assed guess that apps run pretty far down the queue. Anything hardware related gets priority, as do OS processes, and so on - it's not that far fetched to me that stuff like moving around cell towers and the like could deprive the running apps of meaningful processor time to create a lag in that sort of order of magnitude. For my money, that's far more likely than the GPS position jittering that significantly.
upsidedownmark said:
Erm.. yes...
That's not a hard figure, obviously. Nor am I suggesting that's always the case; however I believe it's a realistic order of magnitude estimate for what *can* happen. I'm sure most people have had the phone 'glitch' - not respond for a while before responding to user input. It's that kinda use case. I have no doubt if I look at the gpx data I'll see a jump - what causes that jump is kinda hard to prove. I believe timing is the more significant factor, but undoubtedly signal issues are some part of it too - we have no way of answering how much to each.
WRT the chip, it's a qualcomm in a 4S apparently - no reason it should be less accurate than any other; some of the earlier models shared the wifi antenna, so perhaps weren't so good..
http://www.anandtech.com/show/4971/apple-iphone-4s...
I don't know how familiar you are with how multiprocessing (apologies if this is patronising) - with the caveat that I don't know how the iOS scheduler works / prioritises, here's a best-guess representation of how the process goes:
1) GPS Chip does it's stuff and determines a fix: Pulls up an interrupt to signal the OS that it has some data.
2) Interrupt handler pulls the data off the chip and puts it in a memory location somewhere
<iOS goes off and does other stuff that's higher priority, picks its nose etc>
3) the location services process gets scheduled, does some stuff
<iOS goes off and does other stuff that's higher priority, picks its nose etc>
4) We loop around scheduling 3 a bunch of times until it's done all its interpolation, smoothing, etc., and kicked the strava callback to tell it there's data
<iOS goes off and does other stuff that's higher priority, picks its nose etc>
5) Strava gets a shot at the processor, and deals with the data, timestamping it (again this could be quite an involved process that gets sidelined a few times.
Without knowing how iOS sets up the priorities, I'm going to make a wild-assed guess that apps run pretty far down the queue. Anything hardware related gets priority, as do OS processes, and so on - it's not that far fetched to me that stuff like moving around cell towers and the like could deprive the running apps of meaningful processor time to create a lag in that sort of order of magnitude. For my money, that's far more likely than the GPS position jittering that significantly.
Sorry but I just checked the location API docs, and the location data is timestamped. See hereThat's not a hard figure, obviously. Nor am I suggesting that's always the case; however I believe it's a realistic order of magnitude estimate for what *can* happen. I'm sure most people have had the phone 'glitch' - not respond for a while before responding to user input. It's that kinda use case. I have no doubt if I look at the gpx data I'll see a jump - what causes that jump is kinda hard to prove. I believe timing is the more significant factor, but undoubtedly signal issues are some part of it too - we have no way of answering how much to each.
WRT the chip, it's a qualcomm in a 4S apparently - no reason it should be less accurate than any other; some of the earlier models shared the wifi antenna, so perhaps weren't so good..
http://www.anandtech.com/show/4971/apple-iphone-4s...
I don't know how familiar you are with how multiprocessing (apologies if this is patronising) - with the caveat that I don't know how the iOS scheduler works / prioritises, here's a best-guess representation of how the process goes:
1) GPS Chip does it's stuff and determines a fix: Pulls up an interrupt to signal the OS that it has some data.
2) Interrupt handler pulls the data off the chip and puts it in a memory location somewhere
<iOS goes off and does other stuff that's higher priority, picks its nose etc>
3) the location services process gets scheduled, does some stuff
<iOS goes off and does other stuff that's higher priority, picks its nose etc>
4) We loop around scheduling 3 a bunch of times until it's done all its interpolation, smoothing, etc., and kicked the strava callback to tell it there's data
<iOS goes off and does other stuff that's higher priority, picks its nose etc>
5) Strava gets a shot at the processor, and deals with the data, timestamping it (again this could be quite an involved process that gets sidelined a few times.
Without knowing how iOS sets up the priorities, I'm going to make a wild-assed guess that apps run pretty far down the queue. Anything hardware related gets priority, as do OS processes, and so on - it's not that far fetched to me that stuff like moving around cell towers and the like could deprive the running apps of meaningful processor time to create a lag in that sort of order of magnitude. For my money, that's far more likely than the GPS position jittering that significantly.
I'm a realtime OS programmer by trade (well used to be, just do high performance financial crud now), hence the surprise at the half second latency
budgie smuggler said:
Sorry but I just checked the location API docs, and the location data is timestamped. See here
Well, that's.. erm.. embarrassing. Since iOS 2.0 as well.. guess it's been a while since I looked at the docs 
budgie smuggler said:
I'm a realtime OS programmer by trade (well used to be, just do high performance financial crud now), hence the surprise at the half second latency
Also an (ex) OS guy, sold out/gone commercial / dabbling with ios stuff - Big latencies in realtime systems, no. however IMHO the words 'realtime' and 'high performance' don't belong anywhere near an iOS device, especially from an app POV.Sorry, I just had to make a point that I hate people who mark uphill Strava segments as Hazardous!
If its a road with no junctions, traffic lights etc how the hell can it be hazardous. Its only 7% and the segment is only 0.2miles long!
This feature should have a voting system. Its stupid how one chap (whose probably pissed off that hes lost his KOM) can go and mark a fun competitive segment as hazardous and have all results taken down!
If its a road with no junctions, traffic lights etc how the hell can it be hazardous. Its only 7% and the segment is only 0.2miles long!
This feature should have a voting system. Its stupid how one chap (whose probably pissed off that hes lost his KOM) can go and mark a fun competitive segment as hazardous and have all results taken down!
Try Richmond Park.
There are so many segments it makes you sick, and as you say, despite spending time there, it can miss your times.
I did RP once a few weeks ago and came back with 50 trophies (most were repeat PR's).
Since then, looking at others I follow my activity has vanished. I know I did a 19 ish lap but I cannot find the segment, as there are too many.
There are so many segments it makes you sick, and as you say, despite spending time there, it can miss your times.
I did RP once a few weeks ago and came back with 50 trophies (most were repeat PR's).
Since then, looking at others I follow my activity has vanished. I know I did a 19 ish lap but I cannot find the segment, as there are too many.
I am starting to loathe Strava.
Just got an update saying I have lost one of my KOMs in Merton, I check on the site and I have lost it to a guy who rode on January the 15th, at an average speed of 10mph with a maximum speed of 81mph. Brilliant.
Not only that, but as it won't show you the full ride stats for others for more than a split second as it navigates to the segment page, you have to keep going forwards and backwards on the browser and memorise the data from the snapshot of the screen.
Just got an update saying I have lost one of my KOMs in Merton, I check on the site and I have lost it to a guy who rode on January the 15th, at an average speed of 10mph with a maximum speed of 81mph. Brilliant.
Not only that, but as it won't show you the full ride stats for others for more than a split second as it navigates to the segment page, you have to keep going forwards and backwards on the browser and memorise the data from the snapshot of the screen.
Gassing Station | Pedal Powered | Top of Page | What's New | My Stuff