Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apps WorkOutDoors: New workout features
- Thread starter cfc
- Start date
- Sort by reaction score
Apple's Health system only stores power for running activities, but WOD allows you to connect power sensors. This option controls whether you save that cycling power as Apple Health "running power" samples associated with the cycling workout.
This option previously defaulted to being enabled but I heard of a couple of crashes where the logs showed the crash had happened when saving a power sample for a cycling workout. So I changed it so that it defaults to being disabled, but kept the option for people who really want it (and in case it was a bug in watchOS).
I don't advise enabling it unless you have another app that pulls power data from Apple's health system regardless of the activity type.
That has been on my to-do list for years but is surprisingly rarely requested.
I am also not sure where I would show it, but I could probably think of somewhere.
The app should work with any e-bike that supports the standard Bluetooth "Cycling Speed & Cadence Profile" and/or the "Cycling Power Profile", which I assume are the CSCP and CPP options in your screenshot of the Yamaha.
However some bikes have their own protocols which the app does not support. The YEP1.0 in that screenshot is Yamaha's proprietary protocol. Unfortunately I do not have the time or money to buy bikes from each manufacturer and write and test code to connect to their protocols. Sorry about that.
I admit that the sensor functionality is not perfect, and I am pretty sure that I can improve it in the future. It was only introduced last Summer and, as with most features, I started relatively simple and planned to give it a year or so to see how it goes and what people want before I will revisit it and hopefully improve it.
There are several protocols that I want to add (Fitness Machine, Radar, Cycling Gears etc) and a few manufacturers / devices that people have reported issues with. Where feasible I have bought those devices and will try to determine what they are doing differently that the app doesn't handle correctly. I will also add new metrics where available, such as for the latest model of Stryd.
However this won't be for a while because my main focus at the moment is on the always on display, as well as improved navigation. And then probably interval schedule importing and custom activity types.
I just started my Strava export and found out that the Strava sports type is not selected correctly. If I do a WOD pilates its exported as training. If I do WOD yoga its also marked as training. Strava has this kind of sports types available. Can this export sports type to Strava be changed?
What type of file are you sending to Strava? The app stores yoga and pilates activity types in exported FIT files so they should work. However Strava only recognise a few activity type for GPX and TCX so maybe they don't recognise those two for FIT types.
FIT is usually the best format because it contains the most detail. It probably won't work for GPX or TCX either because, as I say, Strava only recognise a few activities for those file types.
As far as I know this is a Strava issue. WOD should be storing the FIT activity type and subtype that indicate yoga or pilates but it sounds like Strava is not reading the subtype. This is because the activity type for both yoga and pilates is the FIT "training" activity type but then there are FIT subtypes for yoga and pilates. Unfortunately there probably isn't anything the app can do about that so you will need to set it manually in Strava.
I'd pay a subscription to be able to download maps of whole regions offline and have them auto-update on a monthly basis.
I think a lot of people would pay for a subscription, but many more would be deterred from buying the app in the first place just by the existence of a subscription (even though it would only be for extra abilities like that).
I am not ruling it out for the future though. I hope that as the app gets more well known then prospective buyers would trust it more and understand that you don't need the subscription for most features, and that it is only required for the features like that with on-going costs.
Having said that the ability to store whole regions would require a lot of data transmission, especially if it auto-updates, so it is possible that particular feature may be prevented by practicality rather than by cost.
I think I have discovered what caused this problem. It happens if you use the action button to start a workout whilst you are looking at a previous workout in the Workout History on the watch app. When you try to display a menu during that new workout then the app still thinks you are looking at the previous workout and shows the menu for that instead.
It is fine if you just don't press Done on the summary screen of the previous workout. Instead you need to have gone into the Workout History and selected an old workout which remains displayed when you press the action button.
Sorry about that. I will probably release a bug fix version soon but in the meantime try not to start a workout with the action button whilst the app is showing a previous workout in the Workout History on the watch.
I recommend not using the always on altimeter at the moment because it seems unreliable. This is why the latest version of the app defaults to having the option disabled.
Some people have been experiencing sudden jumps where the always on altimeter jumps to a new level for a while and often jumps suddenly back sometime later. My guess is that watchOS is recalibrating for whatever reason.
Apple say they use WiFi somehow, so I am wondering if a WiFi router with an incorrect elevation is causing the problems. So the altitude jumps when in range, and returns back to normal when not in range. In the attached profile screenshot you can see that it jumps in similar places when going down the hill as coming up. This is just a guess though.
It does seem extremely rare, and generally the always on altimeter is very good, so you may want to try it. However the default is not to use it (in which case the app uses the barometer).
Note that ascent/descent estimates can vary a lot between systems because of the different algorithms involved. I don't like including subjective metrics in the app, but a measure of ascent is unfortunately essential.
Thanks for the speedy response as always. Much appreciate it
OW
I may do that in the future but I don't have any plans for it now. I will add the main functionality that doesn't have on-going costs (which will take a while!) and after that then I will think about how to implement the stuff that would cost extra. It won't be for a while so Apple may have changed/improved the payment options by then.
I know it's currently lower on the list, but I'd like to put in a vote for Icloud support in WOD because:
1) It would be great to analyze the WOD workout graphs (which are better than Strava and Health in my opinion) on my iPad instead of my tiny iphone.
2) Over the past year, I got a new iPhone and a new Apple Watch. Both times, restore capabilities didn't work as planned and I had to completely redo all of my Alerts, Intervals, etc.
1) It would be great to analyze the WOD workout graphs (which are better than Strava and Health in my opinion) on my iPad instead of my tiny iphone.
2) Over the past year, I got a new iPhone and a new Apple Watch. Both times, restore capabilities didn't work as planned and I had to completely redo all of my Alerts, Intervals, etc.
What's the nomenclature here?
For as long as I can remember, in sports watches, the altimeter was based on one of two options: GPS or barometer (unless the watch did not have a baro). Typically the barometer was more accurate and using it was preferred, both Suunto and Garmin in the mountains gave me results within an error range of no more than 0.5% (which was sometimes +/- 15m but 0.5% sounds great to me). And for example Suunto 9 had "fused-alti" which supported the baro with GPS data and it resulted in greater accuracy.
But... for AWU the results are absurdly accurate, to be honest I suspect Apple of some software tricks, because each reading is accurate to the meter, if the summit has a plate with info 2364m, AWU always shows 2364, neither 1m more nor less. Amazing but suspicious
So if we turn on the "altimeter" and don't use the barometer, what are we really using? What is then used to determine the altitude?
Apple don't reveal how the always on altimeter works, but they do mention using WiFi. So I don't know if that is because it has a database of router elevations, or if it uses the data connection to read elevations from a terrain database. They are always vague about details, which I guess is understandable because those details may change over time.What's the nomenclature here?
For as long as I can remember, in sports watches, the altimeter was based on one of two options: GPS or barometer (unless the watch did not have a baro). Typically the barometer was more accurate and using it was preferred, both Suunto and Garmin in the mountains gave me results within an error range of no more than 0.5% (which was sometimes +/- 15m but 0.5% sounds great to me). And for example Suunto 9 had "fused-alti" which supported the baro with GPS data and it resulted in greater accuracy.
But... for AWU the results are absurdly accurate, to be honest I suspect Apple of some software tricks, because each reading is accurate to the meter, if the summit has a plate with info 2364m, AWU always shows 2364, neither 1m more nor less. Amazing but suspicious
So if we turn on the "altimeter" and don't use the barometer, what are we really using? What is then used to determine the altitude?
If you do not use the always on altimeter then the app uses a combination of the barometer (for relative elevation) and GPS (for a base elevation). Barometers cannot give absolute elevation unless they are calibrated in some way.
So it records the base elevation from the GPS at the start of a workout. It also starts the barometer at that time, which then provides relative elevations vs that start location throughout the workout. The app then calculates the absolute elevation at each point by adding the relative elevation at that point (from the barometer) to the base elevation (from the GPS).
If you pause then the app recalibrates by using the base elevation from the GPS when you resume.
Note that it is a good idea to wait for a good GPS signal before starting a workout because the base elevation for the rest of the workout (or until you pause) will be take from the GPS at the start.
This is the method that the app used to calculate the altitude for the first 5 years, but I switched to using Apple's always on altimeter last Summer. However after a few strange issues (see that profile screenshot) I switched back to defaulting to the barometer/GPS approach last month, but with the always on altimeter still available as an option. This is because it may become more reliable, and because the reported issues were rare.
I hope that helps. Unfortunately it is quite complicated!
Yes thank you.
You described in detail what I mentioned earlier, that is how the baro system works initially supported by GPS (as a relative change in altitude from the base value given by GPS, based on the change in atmospheric pressure).
Surprisingly, it turns out that Apple has some mysterious "always-on altimeter"... I wonder what it is based on. This winter I was trekking trails where I didn't meet literally anyone all day long, not to mention any buildings. There was also no cellular coverage, so no WIFI, and yet the readings were, as I mentioned earlier, absurdly accurate.
The issue of recording altitude changes in activity tracking has interested me for years, so I must admit that I am very intrigued by how this mysterious Apple altimeter works.