Forum: General Topics
Forums / General Topics / TMJ Mobile Speed and Altitude graphs
| Subject: | TMJ Mobile Speed and Altitude graphs | |
ChrisM 12:59 Location: Phone Model: | Hi Stephen, I was spending an idle moment playing with a track I recorded on my way home from work the other day, looking at the speed and altitude graphs (screen 9). I was using the selected point->show point on map function to look at where I was on the track, as compared to peaks and troughs in the graphs. Based on the evidence of this single track, it would seem that although the speed graph is fairly accurate (speed dips at road junctions etc.) the altitude graph is quite a bit out. ie if I select a peak on the altitude graph and go to that point on the map, it is about 0.75 miles or a minute or so further along the track than the point that I know the actual peak of the hill to be... Any thoughts? I'll load the track into the website later, and see if I can give you any more information. Cheers, Chris. | |
ChrisM 14:57 Location: Phone Model: | Stephen, Hi, I uploaded the track onto the website and it seems to be the same. Not sure if you are able to view stuff that we have uploaded onto our account, (but I guess as the owner of the website, you probably can...). If you want to see what I mean, Have a look at my track 'HomeTest' in the UploadedTracks folder. The highest point of this route is Streatley (just after the route turns right off the A6, then turns onto 'Sundon Road). If you look at the altitide map though, the peak shows to be further on down the road, roughly at the turn for Upper Sundon... Now I'm pretty sure that this has worked fine when I've looked at track before, but they have always been walking tracks. Is it possible that the altitude figures are getting delayed somehow? A (say)60 second delay would be hardly noticible on a walking track, but can be a fairly considerable distance when driving. As I said previously though, it only seems to be the altitude graph. The speed graph seems to sync quite nicely with the road layout... Regards, Chris. | |
Stephen 15:37 Location: Phone Model: | Hi Chris, Yes, unfortunately this is a side-effect of having the 'Extra Altitude Smoothing' option enabled in Settings. I must admit that in testing this I was generally using recorded walking tracks to 'calibrate' it, so hadn't realised that the altitude delay would be so much more noticeable when using faster modes of transport. Not quite sure what to do about this. Maybe I should make it speed dependant, so that the faster you're travelling, the less smoothing is used. (And generally at faster speeds the spikiness is less noticeable anyway). What do you think? Cheers, Stephen | |
ChrisM 16:23 Location: Phone Model: | Hi Stephen, Yes, I'd say reduce the altitude smoothing with speed, or maybe if it's easier, just disable it at speeds over (say) 10mph. I'll try recording a track with smoothing turned it off on my way home tonight and see what difference it makes to the graphs, both in terms of 'spikeness' and synchronisation with the map/track... Cheers, Chris. | |
ChrisM 10:11 Location: Phone Model: | Hi Stephen, If you're interested, I've recorded two tracks whilst driving from work. One is with altitude smoothing turned on and one with it off. It makes slightly interesting viewing to see how much difference the smoothing makes. It seems to me that when moving at speed the algorithm is a little bit brutal... :) Automatically turning smoothing off above a certain speed, or reducing it as the speed increaces does seem to make sense I think. Actually, thinking about it, maybe you could make smoothing an option in the profiles rather than a generic one?? From my point of view, I'm happy to just switch smoothing on and off as required and if I ever forget to turn it on/off it's no big deal, so don't worry too much about it AFAIC, but I suppose altitude tracking might be more important to some... Cheers, Chris. | |
Stephen 16:52 Location: Phone Model: | I am interested!! If it was working correctly (without the time delay), then it *should* be able to be left on all the time (hence the global setting), but perhaps I will move it into the profile anyhow. I'm actually thinking about completely rewriting the filtering/smoothing code to make it a bit more intelligent. The problem at the moment is that the filtering/smoothing is performed right up to the last point received from the GPS, which means that the filtering only uses the points *before* the current one, whereas it would ideally look at the ones before and after. The only way I can think to do this is to stick the live data into a 'buffer', and then do the filtering a few seconds after the data has been received. Should make it a lot better, but I probably wont get around to this until the version after next... Cheers, Stephen | |
ChrisM 17:31 Location: Phone Model: | I assume as the administrator of this site, you are able to access any file on the site, if so, feel free to have a look at HomeTest and HomeTest2 in my Uploaded Tracks folder if you want to compare the difference. The journey in both cases is identical, and speeds and times should be pretty close as well, traffic conditions permitting. You can clearly see the difference between the smoothed and unsmoothed altitudes. The second one is with smoothing turned off, and the peaks and troughs of the altitude graph line up pretty well with the actual geography of the route, however, if you compare the location of the corresponding peaks and troughs in the smoothed track, the delay is fairly clear. If you're site/user security is tighter than I'm giving you credit for here, and you are NOT able to access users files, let me know, and I can email them to you. I like the idea of using past and future points to do the smoothing, though you'll have to take care to to make the delay worse I suppose...(?) Cheers, Chris. | |
(You must be logged in to post a reply to this thread)