Forum: General Topics

Yes, yes. I know that's a silly addon. But there's at least a couple of free gps java software out there that show calories consumption.

One of them, 'WalkMe', is even specifically designed for it. The other, 'GPSWatch', allows setting target calories, and it then returns calories burnt, time elapsed, and remaining time and distance. Wonderful, isn't it?

What does it take?

You can take a look at this:

Total Calories Burned = Duration in Minutes x ((Metabolic Equivalent MET x 3.5 x weight in kg)/200).

But as MET depends on the speed, it needs to be added up during the walk. Slope should also be taken into account as a factor.

Want to give it a try?

Hi Diego,

Great minds think alike! I was going to post almost exactly the same thing. My wife is wanting to lose a few lbs, and I thought being able to see how many calories she was burning while she was walking the dog etc. would be a great incentive...

Stephen, Ihad a quick shufty round the internet, there doesn't seem to be that many places that give you a formula, but I did come across this:
http://workout.ifit.com/v2/FAQ.html#22

Think it's something to do with some electronic treadmill, but I guess the formula could apply to general walking/running...

(as for cycling, now there IS a challange!!)

Cheers,

Chris.

One more link, then I'll stop. At least for now...
(Really should be working anyway!!)

http://www.wv-hsta.org/cdc_chc/walking_mets_table.htm

Seems like MET is not something that can be easily calculated...

Chris.

I am checking the pages you submited. May thanks.

And sorry, I forgot to mention before that last table expresses kcal/hour, and also speed it's related to km/h, not second!

I think I like the way you are going with the calorie calculator. A way of selecting if you were walking/running or cycling in each section, and showing the calculation using the most appropriate MET value, or even just (as you said) showing a value for each of the above, and leaving it to the user to read the value the want.
As far as alititude/incline goes, if I were you, I'd be tempted to ignore it. Certainly with my GPS unit, the alititude is (relatively speaking) all over the place, and I think trying to take it into account would probably make the calculations less accurate than if you just leave it out.

CO2 usage is a tricky one, as the CO2 emissions vary hugely from one car to another, and there are so many other factors (eg a car driven at 40 mph in 5th gear is , I'd imagine, generating less Co2 than the same car being thrashed along at 40 in 3rd). Having said that, a very rough estimate might be fun, and even a bit thought provoking...

Interesting stuff. Will give it all some more thought when I'm less tired/drunk...
:-)

Chris.

Ops, also on biclycing... I would not consider it. How much energy you waste on a cycle depends on many factors. Cycle weight, gears you use, etc.

All GPS java programs focus on walking/running (and hopping!)

" it would be a pity not to use speed, since walking from 2 mph to 4 mph doubles the calories consumption, and it's a data you directly get from the MNEA. "

Dont forget that the speed is still very much taken into account since it is used to derive the MET figure. In your equation:
energy consumed = weight * met / speed * distance

(which for clarity should probably be written as: (weight * met * distance) / speed  )

Since distance/speed=time, this is equivalent to:
energy consumed = weight * met * time

I did a little experiment yesterday. I've added 3 items to the TRACK readout screen: Energy Walking, Running and Cycling (had to split it into two separate pages to fit it all in). It gets each figure by adding up the energy calculated for each track segment (ie the 'gap' between subsequent trackpoints). The MET is interpolated from a lookup table, which is defined separately for each activity. For example, for walking I've used the following table:


(Speed is stored internally in metres/sec hence its use in the table, in mph the figures are much rounder numbers - 0.0, 2.5, 3.0, 3.5, 4.0 & 4.5mph respectively).

So, lets say that two trackpoints are 40m apart with a 20sec gap, the average speed is therefore 2m/s making the interpolated MET about 6.2321. Energy consumed for a 75kg person would be:
75 x 6.2321 x 20/3600 = 2.6 kcal.
(the 3600 figure is needed to convert seconds into hours).

Does this sound about right?

I've also attempted to include gradient in this as well, though theres a lot of guesswork here, so any ideas would be welcome. Essentially I've got it to firstly work out the gradient of the segment and then to modify the MET depending on the activity, the amount of slope, and whether the slope is ascending or descending. The formula I've come up with is:
NewMET = (1 + c * gradient) * OriginalMet

The coefficient c is a constant chosen from the type of activity and the type of slope (ascent or descent). The coefficients that I've chosen are:


So lets say you're walking up a 1 in 10 gradient. The modified MET would be 1+0.5*0.1=1.05 times the original MET (ie 5% more calorie burn). Walking down the same hill would be 1+0.2*-0.1=0.98 (ie 2% less calorie burn). I figure that walking downhill isn't actually *that* much easier than walking on the flat, whereas for cycling I've assumed a much bigger effect. eg: Cycling down the same hill would be 1+4.0*-0.1=0.60 (40% less calories). If it was a really steep hill, say 1 in 5 then the calorie burn would work out at 80% less calories.

I'll make all these gradient calculations an option, but do you think they're on the right track? Diego, I agree that Cycling is perhaps a difficult one to accurately calculate, but the fact that there are published METs for cycling as well as walking and running suggests that I might as well include it, if only to give a rough comparison between separate bike rides - ie, it might not be a true calculation of exact calories, but could still help someone training to try and achieve a similar or increasing workout. I couldn't find any MET figures for hopping unfortunately ;-)

I was up in London yesterday, took a round-about walk to the pub. TMJ recorded 2.5 miles, average speed 3.5mph, duration 44 minutes, Calories used 247kcal. I left it a bit late leaving the pub and ended up running part of the way back to the station (figured it was a good experiment too!!). Recorded 2.5miles, avg spd 6.2mph, duration 24minutes, Calories used 321kcal. Do these figures sound about right?

Chris, as you say, the CO2 calculations would be very much ball-park figures, I've been trying to find some examples, with little success. The graph on this page is about the best I could find. It seems that CO2 emmisions are pretty much directly proportional to the amount of fuel burnt, so I was hoping to just be able to estimate the fuel consumption at different speeds (probably with an option to set the cars engine size, etc), but perhaps theres a bit too much guesswork in this!!

Cheers!
Stephen

Hi Chris,

I forgot to mention that the TMJ figures were calculated for an 'average' weight of 75kg.

Regarding the gradient, all of the energy calculations are performed on the stored track, rather than the live stream (ie, the Calories reading only increases each time a new trackpoint is added to the track). This is a lot more accurate than the gradient gauges, since these show the difference between subsequent points coming from the GPS, which are only a second apart and can be fairly 'noisy', whereas the stored track smooths this out somewhat.

How does your altitude graph look (screen 9) - is this also very noisy or does it give a better representation of the altitude profile (you'll need to set the x-axis to Distance and then zoom in a lot to get a 1:1 view of the track profile). It is this data in effect which is used for the Energy calculations. Do you think this is sufficient?

Cheers,
Stephen

Where to put all this energy calculations in the interface?

You may get weight, activity and energy comsuption target from menu point '7. Settings'.

A new screen under key 1 may reflect relevant energy statistics. I am not sure whether it could be good to allow users to change the 3 parameters, or just some of them, here directly instead of accessing the menu.

The profile plots under key 9 may add a new graph to reflect the energy evolution with time or distance. This graph would only be displayed whenever an energy calculations option has been selected in '7. Settings'.

Just ideas.

Stephen,

Regarding your question about my altitude graph earlier in this thread, I did a little test yesterday. Jogged and walked round a very short circular walk (only about 3/4 mile). The general trend of the graph is ok, but it seems to have a lot of (for example) ups and downs, where the ground was only sloping down. Also seems to have more varience than it should. Interestingly, there was a lot more variance when jogging than walking...
You said that you get a value from the GPS unit once/second or so, but only write a point to the track every 20s (or whatever has been set in the config). When you write the altitude, do you just write whatever the last value from the GPS was when it's time to write a trackpoint? If so, how would it work if you calculated an average of all the values between each trackpoint, then wrote that average to the track??

Altitude smoothing sounds like a good option!
To be honest, I think that'll be better. Not sure if the more spikey graph is truly more accurate anyway, as it picks up a lot of 'interference'. Unless you are travelling through countryside that is extremely steep, or if the track-points are a very long distance apart, the 'smoothed' version would probably be closer to the truth.

Probably is still best to have it as an option like you say though. I suppose if you were hill walking in the desert or something then the non-smoothed graph would definitely be more accurate...
:-))

Chris.

Ahh, that's an interesting point. I didn't really think about that. I suppose if I considered it at all, I was kind of thinking the aerial was omni-directional, if it isn't then maybe that's a part of the problem!
I usually have my GPS 'mouse' stuck in the back pocket of my jeans when I'm out and about. Which probably means the aerial is at 90% to the ground (and possibly facing towards me).
Maybe I'll see if it's possible to keep it with the aerial pointing upwards, and see if it makes a difference...

Hmm,

Just drawing two threads together a bit, it occurs to me that there are two values - HDOP and VDOP, which I understand to be some sort of measurement of the 'accuracy' of the GPS fix.
With respect to the problem discussed both here and elsewhere of getting rid of inaccurate trackpoints that are messing up distance travelled/average speed/calories consumed etc. would a filter to discard any points with HDOP/VDOP that were above a configurable threshold help to solve the problem??

Chris.

Hi Stephen,

I think I see the problem you have. You're right, there probably isn't a simple solution (not sure if there's even a difficult solution!).

Like any system, TMJ can only really be as good as the data it's given. If the GPS is feeding it rubbish, then there is only so much you can do to filter that out. It's the old acronymn GIGO (Garbage In, Garbage Out) to some extent - Don't get me wrong, I'm not critisising you or TMJ, it sounds like you have already given a lot of thought about ways of improving things, and there is only so much that can be done...

On the brighter side, good to hear that the altitute smoothing and the pause is improving things!

Keep up the good work!!

Cheers,

Chris.

Hi Diego,

I'm not sure why you're finding that TMJ resets the track all by itself. Have you perhaps got a low value set in Menu/Settings/Limit Track Size to ... Points? When the track becomes bigger than this value it is automatically cropped to conserve memory. Just set this to something really big to effectively disable it, or use a larger value for Settings/Min Time Betweeen Points or Settings/Min Time Betweeen Points so that the track doesn't get big so quickly.

If this isn't the issue then maybe there's a bug that hasn't shown itself before, or only on your handset for some reason - has anyone else noticed this problem?

The weight is entered in Menu/Settings/Users Weight.

Other than the disappearing track issue, what is it that you're not happy about with the calorie calculations?

Cheers,
Stephen

Hello.

After your recommendation, I set 9999 points as maximum track size and took the phone for a walk.

After 6.42 km at 6.0 km/h average speed, TMJ showed an energy consumption of 200 kCal walking for 1:04.32 hours.

Using the formula built into TMJ:

   MET * weight(kg) * time(hrs), = kCal;
   4.65 kCal/hr * 40 kg * 1.076 hrs = 200 kCal

Using speed dependant MET calculations, as you can get in websites, you get 201 kCal for an speed of 6.4 km/h, which seems pretty good approach.

But same time walking at half the speed should yield half the energy, unlike TMJ's calculations, that will keep showing 200 kCal.

Don't you think this is too simplistic?

Hi Diego,

No worries - I might not have explained it the best way in the manual but the " performing the associated activity at the calculated speed " bit was meant to imply that the MET *is* interpolated from a MET vs Speed table (as given in an earlier post). And don't forget that this interpolated MET is calculated separately for each tiny track segment, so I'd have thought that this would give a more accurate estimate than just using the tracks total time, average speed, etc (as the online calculators probably do).

Therefore " But same time walking at half the speed should yield half the energy, unlike TMJ's calculations, that will keep showing 200 kCal. " isn't the case since the MET used by TMJ will be less due to the lower speed (though not necessarily half, as by interpolating from 'actual' MET values I figure that it would actually be more accurate - ie not necessarily half the speed, half the calories, etc).

David, yes you're right - I had meant to include a Settings tickbox to enable/disable the use of altitude in the calorie calculation (it is currently always enabled) - I'll fix this for the next version.

Cheers,
Stephen

Yes, I second the idea.

At low speeds, position errors can exceed the distance between points and yield to absurd calculated speeds and headings.

I had originally decided not to add a 'speed-limiter' for track recording (to avoid a situation where a track is accidentally not recorded at all), but I guess if it is completely configurable then it can always be disabled if not wanted!

I'm thinking now of adding an 'Activity Profile' option, which would allow custom settings to be stored for different activities (probably just a small number, perhaps Walking, Running, Cycling, Driving, Sailing, Flying). Each profile would have independent settings for Max Track Speed, Min Time Between Points, Min Distance Between Points and Start New Section After ... Seconds. Would this be of use do you think?

Cheers,
Stephen

Just my 2p's worth...

Activity profile is a great idea. It will solve one of the problems I have with TMJ which is trying to find a balance between track settings that'll work both when walking and driving.

Chris.

Maybe there should be 1 or 2 'Custom' settings for uses that you might not have anticipated...

Chris.

" Shchenka, perhaps the profile would be a good place to have the 'Maximum Autopan Zoom Level' setting!? "
Yes, I believe so. This would also help saving the valuable context menu space.
Probably also the min time and distance between points (quite dense for geocaching mode) could be profile-dependent.

By the way, Garmin has introduced the concept of application modes in its recent receivers, too.