"cyclingPowerSim" is a predecessor of the software.
The software "cyclingGPSToPowerSim" inherits all functions from, and no need to get "cyclingPowerSim".
However, about simulations functions are not explained on this page. It's recommended to read the tutorial page of "cyclingPowerSim" and try some simulations on the software "cyclingGPSToPowerSim".

Those simulations would inform how about power you have. You could notice how power you have delivered due to maximum speed and average speed of daily cyclings.
Such a prehension might be helpful to check the accuracy of GPS data.

First of all, profile settings should be done. It's described briefly in the following section and be described in depth in the following chapter. Profile properties are necessary to be set in advance for both of the simulations and analysis of GPS data.
the tutorial of simulations at here.



At boot, the profile data would be read automatically. It has following nine sections with some items.

* Wind speed and temperature in 'Course' are unrelated to the analysis GPS data.

Case of first boot after installation, default data values would be read which is in a file named "default.pro". This file is located in a folder named "profile" under the installation folder.

Please exchange these profile values as user's own values, and save it as a file. It could be named and could be located by user's choice.
In case you have multiple bicycles or multiple wheels sets, with season's clothes, you might like to make profiles as all combinations.

Due to load a profile which's already saved, since then, the profile would be always loaded at the boot of the software.

Those are manipulated by pulldown menu of "Profile".



Ver.0.20.00 and later, Condition Settings are separated from Profile Settings.


Wind speed and temperature in 'Course' are unrelated to the analysis GPS data.

Those are manipulated by pulldown menu of "Profile".



The FIT file format was formulated by Dynastream Innovations Inc. It's formed for recording various sports data and also fitted to record GPS data. It has flexibility, be able to define various factors and to record them, smaller file size rather than GPX or KLM cause a binary file, without dependence on platform due to bridge the difference of endianness.
FIT : Flexible & Interoperable Data Transfer Protocol

As mentioned at the outset, if a GPS logger in hand doesn't support the FIT file format it's recommended to convert by any converter. It's very high functionality and multi functions.

The software expresses a summary after loading a fit file.
-- file type, sport type (workout code), count of record messages, existing of remarkable factors(fields), stats(start and end time, start and end geo-coordinate, timer time(moving time), total distance, average speed, maximum speed) and possibility of analysis and prediction.
Whether analysis is possible or not, that depends on the data fields. Stats also depends on them.

Selects a menu named "Load Activity Fit File" which loads a FIT file.
In case of analysis is possible, menus of analysis would be enable. Those're pulldown menus under 'GPS'.

About FIT file in depth as follows:



Due to set a threshold of speed, records data under the speed could be excluded. That's common setting for common GPS loggers. Records data during a break or waiting for a traffic light could be excluded. In case of zero setting, all records data would be covered for analysis and prediction.
That could be set at a dialog "GPS data" in a "Preference" (left picture).

At the same tab, due to check "detect braking", it's able to detect braking at each record, and be able to express braking force(kgf) and temperature(Celsius) of brake materials, friction heat(Jule), radiate heat(Jule) both of front and rear brakes. That's enabled only in case of predict power. And, in order to get correct prediction values, it might be required the GPS logger to be very high accuracy.

Smoothing and outlier rejection are very important.
It's possible to analyse and predict due to recording data without those though, as mentioned at the outset, that's not a realistic way in the current.
As a trial, please execute "Express Source Data" without checking "smoothing GPS data, outlier rejection". Unreal inclination values might be listed.

Usually, the accuracy of the altitude is not high. Even if a high-end chip is on board and the geo-coodinates could be recorded exactly, the inclination values would be often result in unreal. As for the inclination, a little error of the altitude would be refected to large error.
As for the acceleration value, the same thing could happen.

i.e. "smoothing and outlier rejection" must be checked, unless especially high accuracy GPS logger.

Smoothing is done by the median method. It's famouse as a noise rejection method for graphics data. It excludes noises and smooths difference between pixels laying side-by-side. As for this method, it's important how to decide the range of smoothing. Both of too wide range and too narrow range might have made the data to be different from real vehicular swept path.
The criterion is distance as recording interval. The range should be wider in case of the distance interval is shorter, the range should be narrower in case of the distance interval is longer. If the distance interval is too long, the smoothing is never done. In an indirect way, the recording interval of time effects same as the distance.

As for outlier rejection, it's done due to set unreal values of inclination and acceleration.
It might be possible to set unreal value of the inclination by memories of cycling. About acceleration, it's standardized by human ability, and could be defined by the memories.
Unreal value of the acceleration should be set as a case of flat course. In case at slopes, the software would correct the value and determine whether it's an outlier or not.
Those are not necessary if the GPS data were very high accuracy though...

Smoothing and outlier rejection are enforced separately. In an extreme case, velues zero of the inclination might be continued even though the altitude values are shifting. Because the shifting values of the altitude are not based on the fact especially in cases of too few tracking satelites at beginning of record or effected by the multipass under cluster of high-rise buildings.
If such data occurs frequently, it might be better to get a higher accuracy GPS logger.



Cadence would be predicted by the equipment and speed, usual cadence as human ability. i.e. its prediction value is a kind of ideal value.

Power would be predicted by lots of factors -- almost properties set as the profile (human body and wear, positioning, various equipment specifics, course conditions) and settings for analysis (wind speed, wind direction, average temperature), GPS records data (speed, acceleration, inclination).
As for wind speed and wind direction, it's ideal to be logged as records data though, there is no such a logger, and those should be set as average values at the runnig. Temperature should be set as same as that. Air density which is a base for aerodynamics would be calculated by temperature and altitude.
Normally, it might be okay to set wind speed zero in guessing. It might be set average wind speed and wind direction in case under high wind especially.
In case of train cycling, it could be set at the profile though, practically, that setting could be used for only team time-trial.

Executes by a pulldown menu named "Analyse And Predict" under "GPS".

At first, a summary would be expressed. Next, records data analysed and predicted would be expressed.
As a summary, stats are expressed which are not only speed and distance but also cadence and power. As records data, cadence and power are expressed as each records. In case of checking "detect braking" in the Preference, braking force and temperature, friction heat, radiate heat would be expressed.
In case checking "smoothing GPS data, outlier rejection", those stats are not based on original GPS data but are assumed as actual cycling.

Data expressed in a window could be saved as a text file, due to a pulldown menu "Save As" under "lower Screen" under "File".



Data analysed and predicted could be saved as a FIT file.

Selects format of a FIT file. Normally, 'modern' might be selected. If anyone is using the Golden Cheetag ver.2.x, 'legacy' should be selected for it. In case of no check, it inherits from a source file.

And, 'sport type (workout code)' could be exchanged. In case of no check, it inherits from a source file.

And the FIT file with cadence and power data(fields) could be analysed by the Golden Cheetah

Concretely fields of cadence and power would be added to a file based on the source FIT file. The FIT file format has no field about brake and braking force and temperature of brake materials would not be saved.
Records under the threshold speed would be excluded.
For messages of Session and Lap, definitions would be added and stats of cadence and power would be added.
The endianness(data architecture) is comformed to the source file. And crc would be updated. That's finish.

Executes a pulldown menu "Create A FIT File Analysed" under "GPS".




Executes "Load A FIT File" and "Analyse And Predict", "Create A FIT File Analysed" at one stroke, which fuctions are already explained above.

It makes less time and toil.
For an example, in case of creating a FIT file with power fields data for analysis by the Golden Cheetah, it might be fast and snappy to use this function.

As a default setting no checking of "express fields data", this function will not express record fields data but summary data only which is different to the case of an individual function. Cause it takes so much time.
Due to execute "Express Source Data" after the one stroke record fields data could be expressed though, which are not source data but results of analysis and braking fields data could not be expressed even if checking "detect braking".

Executes a pulldown menu "At One Stroke" under "GPS".



It's possible to exclude records with slow speed though, it's better to turn off a logger among a break and to combine files after recording all paths. Because that has advantages for battery runtime and recording capacity.

Source files to be combined are the activity file type only. i.e. The type is the FIT file with the record messages. It's not matter whether they're original logging files or analysed files.
As results of combine, all record messages are merged and stats in session and lap messages are rewitten.

Selects format of a FIT file. Normally, 'modern' might be selected. If anyone is using the Golden Cheetag ver.2.x, 'legacy' should be selected for it. In case of no check, it inherits from a source file.
And, 'sport type (workout code)' could be specified. In case of no check those types inherit from source files even if mixed different types.

Executes a pulldown menu "Combine FIT Files" under "GPS".



Format of a FIT file could be exchanged. If anyone is using the Golden Cheetag ver.2.x, 'legacy' should be selected for it. And, 'sport type (workout code)' could be specified. In case of no check those types inherit from source files even if mixed different types.
These functions are same as functions in "Save A FIT File" and "Combine FIT Files" in themselves.

Executes a pulldown menu "Convert A FIT File" under "GPS".

And, it's possible to convert the speed unit to 'mps' from 'kph' though, it's not necessary normally. Because the speed unit is unified and defined as 'mps' in the FIT SDK, and hardwares should record the values based on 'mps'.
However, there are rarely? hardwares which are adopting 'kph' for recording. This is a function which converts such data.
If the data has various speed fields, e.g. vertical speed, except horizontal speed, and those are mixed speed units as 'mps' and 'kph', the convertor regards all fields as values based on 'kph' and converts all fields to 'mps'.



Adds selectively messages of Session and Lap, Activity. It's impossible to add messages already existing in a source file.

A FIT file has various messages. As for an activity type file, messages of File_Id and Record are essential. It's not matter as a FIT file that other messages are not existing.
However, that would not keep records of what kind of workout, elapsed time and moving time, total distance, average and maximum stats of speed, power, heart rate, cadence and so on. It's depending on a software or a hardware whether such various values could be refigured by the record messages or not.
For an example, Golden Cheetah never determine a proper workout code.

Especially, important messages are session and activity. Those has recording of various stats and total moving time, number of sessions, sport type and so on. At this point, a lap message is same as though, it might be rare that a lap message would be refered.

In principle, added each type messages are one definition message and one data message. There are two exception cases. One is a case of adding lap message to a source file with multiple session messages, in which case, multiple lap messages would be added an equal number of the session messages. Another is a case of a definition of record is added in a middle in a source file, in which case, definition and data messages of session and lap would be added each time regardless of alteration of the record definition.
In case of adding messages to a source file with multiple sessions, if the sport type is specified, the sport type would be rewritten in all session messages. For inheritance specifications of a source file, please never check 'specify sport type'.

Executes a pulldown menu "Add Messages" under "GPS".



Divides a FIT file.
For an example, it's necessary to divide a FIT file which has multiple different types of the sport type (workout code) for analysis and prediction.

A condition of a FIT file which could be divided is one of following cases.


Destination filenames would be added numerals automatically to end of a filename which was set.

Executes a pulldown menu "Divide A FIT File" under "GPS".



It's just a trial function which is not needed in guessing though.
Actually, it's added for creating files for testing a function "Add Messages".

Executes a pulldown menu "Exclude Messages" under "GPS".

Sets up following items.


Input human height and weight.

Selects a riding position. In case of selecting "torso angle" it would be alternative to input torso angle.
Other positions selected the value of torso angle will be changed automatically. Those are mean values as torso angle of each position selected.

Usual Cadence, it's maybe different aspect vary from person to person though, it's the cadence under constant velocity moving. As a case of roadrace it's the cadence under the peloton without diplomacy.

Cadence Powered Maximum, it's the cadence which could make the rider's maximum power. It's the cadence in case a person makes maximum velocity for one. As a case of roadrace it's the cadence under the goal sprint.

Cadence Shift Up, it's the adjacent cadence for shift-up.

Cadence Shift Down, it's the adjacent cadence for shift-down.




Sets up following items.


Selects wear and helmet. Those are concerned aerodynamics, especially wear.

Input bike weight. In case of checking "except wheel weight" it's the weight except front and rear wheels with tyres.

Shell Type, it's the shape of frame which could be selected normal or aero. In case of aero type aerodynamics ratio could be input. Aerodynamics effect of frame is not so large though.




Sets up following items.


Shifting Time Loss, it's the time taked for shifting at once. For an example, it's 0.35 seconds by Campagnolo Record, it's 0.45 seconds by Shimano Duraace, both as 2010 years models.
This time would make no power among the time shifting on simulations of acceleration and deceleration.
Manufactures have developed it to be seamless and it would become to some power for shifting in guessing, in which case it may be shorter time.

Inputs length of a crank.

Inputs number of chainring, and input toothes of each chainrings.

Inputs number of sprockets, and inputs toothes of each sprocket.

Count of gears are front 3 x rear 15 as maximum, front 1 x rear 1 as minimum (i.e. pisto).




Sets up following items both of front wheel and rear wheel.


Input size of wheel by inches.

Input weight of wheels except tyres and tubes.

Regist is the air resistance, and velocity is its condition which makes the resist.
Due to "predict", it could be presumed due to rim height and number of spokes, model year under 50 km/h.
This prediction is inductive statistics analysed dozens of existing wheels, and is the result model consisted with three significant factors. The reason of significant model year which is refrected evolution of aerodynamics in '00s.




Sets up following items both of front tyre and rear tyre.


Input the size of a tyre, which is width of a tyre. It's expressed by 'C' normally though which seems to be a bit different by manufactures.

Inputs the weight of a tyre added a tube.

Inputs the rolling coefficient.
It's distributed around 0.003 ~ 0.005 in high-end class. This value is not under dirt road but normal paved road in case of BPN 75. There is a tendency a slic tyre has a small coefficient.
Tyres for cyclocross and MTB specialized for dirt road have very large rolling coefficient though, there is few change between dirt and paved road

Inputs the friction coefficient.
It's distributed around 0.70 ~ 0.90 in high-end class. This value is not under dirt road but normal paved road in case of BPN 75. There is a tendency a slic tyre has a large coefficient.

The rolling coefficient and friction coefficient is related as trade-off normally. There are users who use high friction tyre for front and low rolling coefficient for rear tyre aren't there? As a matter of fact it depends on the brand.




Sets up following items both of front brake and rear brake.


Selects a rim brake or a disc brake at first.

Selects its material carbon or alminum alloy, stainless. Carbon or Alminum would be selected for a rim brake, alminum alloy ore stainless would be selected for a disc brake.
There is rarely a carbon disc brake, carbon composit coated seramics? which is unconsidered.

Inputs weight of a rim or a rotor.

Inputs height for a rim and diameter for a rotor.




Sets up power losses of following three equipment. Those are around 3 ~ 5 percentage as standard value under default conditions.


Shell loss, it's influenced due to bending of a frame, and please input loss percentage under crank torque 50.0Nm. Its ratio would be changed by the torque.
In case of a high rigidity frame it could be around 1.5 ~ 2.0%. That's not meaning lower fatigue but just a machanical loss.

Mission Loss, it's a loss of a driveline. It might be around 3.0% for high-end class, 5.0% for low-end class components.

Wheel Loss, it's influenced due to bending of a rear wheel, and please input loss percentage under crank torque 20.0Nm. Its ratio would be changed by the torque.
It would be differnt as wheel type. One of reference marks is the number of spokes of sprockets side.



First, set the position and maximum power of the motor.
Next, set the type of assist, end speed (speed range), and assist ratio for up to three ranges.
Normally, two ranges will be sufficient. If you don't need any ranges, set them to "none".

Select the type from "constant" and "linear".
For "constant", the output of the motor is determined by a constant magnification relative to the human power, and for "linear", the magnification varies linearly. With "linear", the magnification changes linearly according to the speed, from the end magnification of the previous range to the set magnification at the end speed of the range in question.

The speed to be specified is the terminal speed (kph, km/h) of the respective range.

The ratio is motor power divided by manpower. For example, if the ratio is 2.0, you can expect three times the power of human power and motor combined. Of course, it is impossible for the motor to exceed its maximum power.

For example, if we follow the EU regulations for electrically power assisted bicycles
The maximum power of the motor is 250W, and the first range is constant, up to 25km/h, at a ratio of under 2.0 times. After the second range is none. The ratio depends on the mode and brand, etc.

Sets up following four course environments.


Inputs wind speed. plus numeral for head wind, minor numeral for tail wind.

Inputs air density. There are two ways to input altitude and temperature or input hectopascal.

Sets up condition of road surface.
BPN is a unit value named "British Pendulum Number" which evaluates friction of road surface.
Selects dry or damp, wet condition.




Sets up aerodynamics ratio under pleton or train.


There are two ways to input directly a ratio value or to get the ratio due to input number of pleton and following distance.

In case of alone, please input '1.0' as the ratio.

Selects to join the rotation or not in case of make the software to calculate the ratio. Case of entry rotation, it calculates mean of the ratio.

There are various types of the FIT file -- device, settings, sport, activity, workout, course, schedules, weight, totals, goals, blood_pressure, monitoring, segment, exd_configuration, mfg_range and so on, about twenty kinds of types.
Any types could be read as long as a FIT file.

A FIT file typed activity only is possible to be analysed.
A FIT file typed activity only has record messages. A FIT file with GPS records data is the activity type only.



A summary of a FIT file would be expressed after it's loaded.
-- file id type and sport type(of each session), count of record messages, count of definitions and data messages, existing remarkable record data(fields), stats of session and lap messages, recording time-interval, timer-time and so on.

It's possible to make a judgement whether cadence and power could be predicted or not.



It's possible to analyse and predict cadence and power only in case of speed and acceleration, inclination are recorded or be able to be calculated by GPS data. If the heading could be calculated it would be possible to simulate effection of wind speed and direction.
Typically, it's enough that timestamp and geo-coordinates(latitude and longitude), altitude are recorded. In most cases, as records of GPS data, speed and distance are calculated and recorded.

As a special case, for an example a FIT file recorded by a cycling computer producted by Garmin inc., there is an activity type FIT file without GPS data. By that records data(speed and distance) it's possible to calculate speed and acceleration only. In that case time shifting is assumed by speed and distance, and acceleration could be calculated by those. However it's impossible to calculate inclination.
As for those data, it's possible to analyse and predict limited as a flat course.



As for a right picture, records data are expressed due to "Express Source Data".
-- sector, timestamp, heading, altitude, inclination, speed, distance are expressed. This sample executed by checking "smoothing GPS data, outlier rejection".

'Sector' is number given for records data recorded continuously. In cases of under threshold speed and during a break or waiting for a traffic light, records data during those are excluded and the sector number would be updated (incrimented).

* timestamp is absolutely UTC (Universal Time Coordinated).

* heading is a direction of cycling. True north is zero and degree is added in a clockwise way.

Due to set a threshold speed, records data under it could be excluded. That's also a usual setting for common GPS loggers. By that, records data during a break or waiting for a traffic light would be excluded. If zero is set for the threshold speed, all records data would be targets for analysis and prediction.

In the same tab, there is a check box of "detect braking" which enables predict and express braking force and temperature of brake materials, friction heat, radiate heat both of front and rear brakes. These are predicted and be expressed only in case of power prediction.

Setting due to "GPS data" in the "Preference".

In a same tab, there is a selection of the unit of speed though, that's no need to exchange normally. Because the unit is defined 'mps' as the FIT file format.
However, rarely?, there are hardwares which records speed by the unit 'kph'. In that case, please exchange the selection.
The function was removed which selected a speed unit. Instead of that, a fuction was added which converted fields of speed in a fit file to be based on 'mps' from 'kph'.



Sector number is given to records data which recorded continuously. It would be updated(incrimented) in cases of under threshold speed and during a break or waiting for a traffic light.
In other words, when over the time interval is found the sector number would be updated. It depends on a hardware though, the sector number would be updated when the record is sliped even if continuous cycling.

Sector number is for expression of records data used only in the software. There is no effection to a FIT file for exporting.
.


Smoothing is mentioned at the outset and introduction.
It's a function which assumes actual vehicular swept path, due to remove oscillations by GPS accuracy errors.

Targets data for smoothing are all GPS data except timestamp.
A GPS logger with a high-end chip has high accuracy and there might not be large error of geo-coordinates and speed, distance though, it's better to remove the oscillations even if sensitive errors. Because those sensitive errors have possibilities to reflect acceleration calculated as larger errors.
And, at beginning of recording and re-tracking satelites, under cluster of high-rise buildings, it has possibilities that errors would be larger by too few tracking satelites and the multipass.

Smoothing is done by the median method. It's famouse as a noise rejection method for graphics data. It excludes noises and smooths difference between pixels laying side-by-side. As for this method, it's important how to decide the range of smoothing. Both of too wide range and too narrow range might have made the data to be different from real vehicular swept path.
The criterion is distance as recording interval. The range should be wider in case of the distance interval is shorter, the range should be narrower in case of the distance interval is longer. If the distance interval is too long, the smoothing is never done. In an indirect way, the recording interval of time effects same as the distance.
As a rough guide, smoothing would be done in case of the distance interval of recording is within around twenty meters. The range of smoothing could be determinate distance due to increase target count of recordings if so shorter distance interval.
In case of 20 kph, smoothing would be done until 5 seconds time interval and smoothing would not be done in case of over 5 seconds interval.

Smoothing is a indispensable function currently, although it's no need if there were ultrahigh accuracy GPS loggers whithin several centimeters.
.


Outlier rejection is mentioned at the outset and introduction.
It's a function which assumes actual inclination and acceleration, due to outlier rejection by GPS accuracy errors.

Targets data for outlier rejection are inclination and acceleration.

The altitude as GPS recording data has been vagabond. There is a map which performs corrections about altitude data. It's worth thinking about usage. It's true, there might be many GPS loggers enough to be used because it's not necessary to be exact altitude but to be exact altitude change for actual inclination.
It hinges on the chip though, the accuracy of error could be several meters in case of changing number of tracking satelites or the multipass under cluster of high-rise buildings. Its data could have volatilities in narrow streets even if among low-rise houses.

Acceleration data itself is not to worry though, its errors could have an effect to power prediction. And it's better to exclude even if sensitive errors.

Unreal Values of inclination and acceleration could be set as unexpected aberrant values. Due to exclude values over them and smoothing by the median method, assumed as actual vehicular swept path could be took.
As defaults, inclination is set to 25 %, acceleration is set to 1.5 mpss.

No need to be nervous about the values. If for instance, an error value 24 % inclination is recorded, it's not probable to continue such errors recording around the time. And the value 24 % could be excluded by the median method. If the value 24 % is a real inclination, it's probable to continue nearly equal values recording around the time. And they could not be excluded.
As for acceleration, it's same as inclination. It's okay to set them as "out-of-the-ordinary".

As an outlier of acceleration, it's assumed a flat course (in case of zero inclination). If the inclination is changed the outlier of acceleration should be changed. And, In case at slopes, the software would correct the value and determine whether it's an outlier or not.
Acceleration 1.5 mpss as the default under zero inclination is need around 500 watts under 10 kph and around 800 watts under 20 kph, around 1200 watts under 30 kph (in conditions as default.profile). That's not impossible though, it's set as default which is not considered to be common.
Please exchange the value due to individual regular cycling.
.


It's a matter of common sense that a high accuracy GPS logger is better.
It's a matter of common sense too it's better that mounting position of a logger is high and no masking to the sky. But it might be impossible to mount it on the head, and that might be put aside.

It's important how to deal the logger at beginning to record. Although it hinges on the chip and does not effect to average values that recording data values have volatilities, that should be avoided cause outlier values as stats of maximum speed and maximum power would be recorded.
Cause is too few tracking satelites at the beginning.
If a logger could be checked conditions of tracking, it's better to start cycling after the condition would be good state. If a logger could not be checked it might be better to wait for starting a few minutes at the open patch.
It's caution needed especially for a logger which could start to record as soon as switch-on. That's considered to be high performance or convenience though, that's not fact.

The best thing to do is start after the altitude value has hardened, if the logger is able to indicate the value in real time. Because the altitude data might be shifting at beginning to record cause of few tracking satelites, it's better to start after a correct value could be indicated.

It's good to choose a logger with a high-end chip to buy.
It has high accuracy and be quick to re-track. Re-track is a capability to track satelites again after lost by a tunnel or under the elevating structure. And, recent high-end chips are insulated from the influence of the multipass.
Others, there are key-buy-factors, e,g, runtime of battery, recording capacity, various settings. If possible, it's recommended to buy a logger specified as over 12 hours runtime and over 24 hours recording capacity, setting one second recording interval.

Cadence would be predicted as a kind of ideal value.
It's predicted by chainrings and sprockets, wheel diameter, tyre diameter, usual cadence as a human ability, speed of GPS data.

Concretely, cadence is predicted as close to the usual cadence as gear teeth combinations can get under recording velocity. If power is zero cadence would be zero too.
Records with zero cadence are not intended for calculation of average value as a stats.



Power is predicted by lots of factors.
Almost properties set as the profile (human body and wear, positioning, various equipment specifics, course conditions) and settings for analysis (wind speed, wind direction, average temperature), and GPS records data (speed, acceleration, inclination).

As for wind speed and wind direction, it's ideal to be logged as records data though, there is no such a logger, and those should be set as average values at the runnig. Temperature should be set as same as that. Air density which is a base for aerodynamics would be calculated by temperature and altitude.
Normally, it might be okay to set wind speed zero in guessing. It might be set average wind speed and wind direction in case under high wind especially.

It's possible to detect braking and to predict temperature of brake materials by the GPS data though, it's required the GPS logger to be very high accuracy.

In case of train cycling, it could be set at the profile though, practically, that setting could be used for only team time-trial.

Power prediction is based on four regions -- pedaling, crank, hub, thrust(wheel), which could be selected. Power based on wheel is the thrust power. At the other regions, more power is developed due to equipment losses. Those power losses could be set at "equipment loss" in the profile.

As same as cadence, records with zero power are not intended for calculation of average value as a stats.



Due to execute analysis and prediction, a summary would be expressed at first, and records data analysed and predicted would be expressed.
As a summary, file name, the threshold speed, file id type, sport type (workout code), count of records, count of definition messages, count of data messages, existing remarkable fields and stats would be expressed.
As a record data, sector number, timestamp, heading, altitude, inclination, speed, distance, cadence, power would be expressed.

Those data are none other than the values which would be writen to a FIT file in case of saving.

And, in case of detecting braking, braking force(kgf) and temperature(Celsius) of brake materials, friction heat(Jule), radiate heat(Jule) both of front and rear brakes would be expressed. But those record data would not be saved cause the FIT file format has no field about brake.

In case of checking "smoothing GPS data, outlier rejection", those values and stats values are not values of an original source file but are assumed as actual values of cycling.

Data expressed on the window could be saved to a text file. That's executed by a pulldown menu "Save As" under "lower Screen" under "File".

When the data analysed and predicted are saved to a FIT file, it's based on a source FIT file. It's based as definitions and data layout as a file architecture of a source FIT file.
For an example, If there is no session nor lap messages in a source file, the architecture of an output file would be same architecture, and stats of remarkable fields are never written to an output file. Though almost activity files may be defined session and lap messeges.
Endianness(data architecture) is also based on a source file.

Selects format of a FIT file. Normally, 'modern' might be selected. If anyone is using the Golden Cheetag ver.2.x, 'legacy' should be selected for it. In case of no check, it inherits from a source file.

And, sport type could be specified and be exchanged. In case of no check those inherit from a source file. In case of mixed types in a file, for an example swimming and bike, running are existing in three session messages in a file, it might be better not to check for inheritance from the source file.
Sport type is a kind of sport and actuvity, training, workout. It's defined 'Workout Code' in the Golden Cheetah. It has nine types -- generic and running, cycling, transition, fitness, swimming, walking, sedentary, all. If the GPS logger has no function to set the type, without this setting as "cycling", there is little chance that the Golden Cheetah computes the data file as a cycling data.
If the software would be always used for cycling data only, it's also better to save the setting "cycling" as a default.

Records data with under threshold speed would be excluded.



Fields of cadence and power which are predicted are added.
Field values would be added to records data, and stats of them would be added to session and lap messages.

As for the braking, even if checking "detect braking" and its properties are predicted and be expressed, the values of the braking prediction would not be saved to the FIT file. Because such fields are not existing in the FIT file format.



Definitions of record and session, lap messages are rewitten on the occation of adding data.
And fields data of them are also rewitten except timestamp in case of checking "smoothing GPS data, outlier rejection".



Output FIT files could be imported and be analysed by the Golden Cheetah.
Training management would be possible due to analyse as exercise physiology. If there is no consciousness as a traning but just a fun-riding or health-conscious riding, it might be interesting to check physical capacity and physical condition, shifting of them and so on.

You might like to use the Golden Cheetah. At here, a rough process of usage described as follows, as just an image.

data collection

data import

analysis, estimation

Following pages are described in depth about the Golden Cheetah
-- UG_Main-Page_Users-Guide
-- This manual is for Golden Cheetah, version 3.0., Copyright (c) 2013 Mark Liversedge

Executes "Load A FIT File" and "Analyse And Predict", "Create A FIT File Analysed" at one stroke, which functions are already explained above.

It makes less time and toil.
For an example, in case of creating a FIT file with power fields data for analysis by the Golden Cheetah, it might be fast and snappy to use this function.

Executes a pulldown menu "At One Stroke" under "GPS".



Record fields data could be selected whether to be expressed or not due to checking "express fields data". As the default setting, this function will not express record fields data but summary data only which is different to the case of an individual function. Cause it takes few time.

Record fields data could be expressed due to execute "Express Source Data" after the one stroke though, which are not source data but results of analysis and braking fields data could not be expressed in this case even if checking "detect braking".

Source files to be combined are the activity type only. i.e. The type is the FIT file with the record messages. It's not matter whether it's a source file or a analysed file.
As results of combine, all record messages are merged and stats in session and lap messages are rewitten.

Selects format of a FIT file. Normally, 'modern' might be selected. If anyone is using the Golden Cheetag ver.2.x, 'legacy' should be selected for it. In case of no check, it inherits from a source file.
And, 'sport type (workout code)' could be specified and be exchanged. In case of no check those inherit from a source file even if mixed different types.

Executes a pulldown menu "Combine FIT Files" under "GPS".



It has a possiblity that a combined file could not be analysed in case of source files had mixed to be created by different hardwares, especially mixed by a GPS logger and a cycling computer.
GPSBabel mentioned above has the function to combine multiple files and it's a method to use them though, it's hard to say that a combined file could be analysed.
Because the FIT file format has too much flexibility and there are multiple methods to combine. For an example, even if the source files have different fields, it's possible to combine them in their entirety. That's a simple idea and be easy to be adopted. And as results, in extreme cases, it has a possibility that a field of timestamp disappears or remarkable fields speed and distance and so on could not be calculated by a same method in the middle of records, and it's hard to analyse the combined file.



The software would combine files by a method which focuses on analysis and prediction.
It does not delete recording fields even if they are not necessary for analysis but makes conditions for combine.
About remarkable fields -- timestamp, latitude, longitude, altitude, speed, distance, cadence, power, source files need to have same states of these fields as existing or not. Next, time intervals of source files must be same value. Those would be eliminated as possible.
Indeed, it may be no problem in case of the source files are created by a same hardware.

Format of a FIT file could be exchanged. If anyone is using the Golden Cheetag ver.2.x, 'legacy' should be selected for it. And, 'sport type (workout code)' could be exchanged. In case of no check those inherit from a source file even if mixed different types.
These functions are same as functions in "Save A FIT File" and "Combine FIT Files" in themselves.

Executes a pulldown menu "Convert A FIT File" under "GPS".

And, it's possible to convert the speed unit to 'mps' from 'kph' though, it's not necessary normally.



As for file format, it could be exchanged to legacy from modern and to modern from legacy. That's might be useful if using the Golden Cheetah ver.2.x although there is not such a demand.



Sport type is a kind of workouts and trainings which is defined 'Workout Code' in the Golden Cheetah. There are nine types -- generic, running, cycling, transition, fitness, swimming, walking, sedentary, all. If the GPS logger has no function to set the type, without this setting as "cycling", there is little chance that the Golden Cheetah computes the data file as a cycling data.
If the software would be always used for cycling data only, it's also better to save the setting "cycling" as a default.

The sport type is defined in the session messages. If it's specified by the function in case of mixed types by multiple session messages, all definitions would be rewrited to a type specified. And, in case of no session message, the type could not be specified.



It's possible to convert the speed unit to 'mps' from 'kph' though, it's not necessary normally. Because the speed unit is unified and defined as 'mps' in the FIT SDK, and hardwares should record the values based on 'mps'.

However, there are rarely? hardwares which are adopting 'kph' for recording. This is a function which converts such data.

If the data has various speed fields, e.g. vertical speed, except horizontal speed, and those are mixed speed units as 'mps' and 'kph', the convertor regards all fields as values based on 'kph' and converts all fields to 'mps'.

Adds selectively messages of Session and Lap, Activity. It's impossible to add messages already existing in a source file. At the same time, a file format and the sport type could be specified.

Executes a pulldown menu "Add Messages" under "GPS".

A FIT file has various messages. As for an activity type file, messages of File_Id and Record are essential. It's not matter as a FIT file that other messages are not existing.
However, that would not keep records of what kind of workout, elapsed time and moving time, total distance, average and maximum stats of speed, power, heart rate, cadence and so on. It's depending on a software or a hardware whether such various values could be refigured by the record messages or not.
For an example, Golden Cheetah never determine a proper workout code.

Especially, important messages are session and activity. Those has recording of various stats and total moving time, number of sessions, sport type and so on. At this point, a lap message is same as though, it might be rare that a lap message would be refered.



In principle, added each type messages are one definition message and one data message. There are two exception cases. One is a case of adding lap message to a source file with multiple session messages, in which case, multiple lap messages would be added an equal number of the session messages. Another is a case of a definition of record is added in a middle in a source file, in which case, definition and data messages of session and lap would be added each time regardless of alteration of the record definition.
In case of adding multiple session messages, the sport type would be same one spcified in all session messages.

In case of adding messages to a source file with multiple sessions, if the sport type is specified, the sport type would be rewritten in all session messages. For inheritance specifications of a source file, please never check 'specify sport type'.

Divides a FIT file.
For an example, it's necessary to divide a FIT file which has multiple different types of the sport type (workout code) for analysis and prediction.

A condition of a FIT file which could be divided is one of following cases.


Executes a pulldown menu "Divide A FIT File" under "GPS".



Destination filenames would be added numerals automatically to end of a filename which was set.

It's just a trial function which is not needed in guessing though.
Actually, it's added for creating files for testing a function "Add Messages".

Executes a pulldown menu "Exclude Messages" under "GPS".



Excludes selectively messages of Session and Lap, Activity. At the same time, a file format and the sport type could be specified.

GPS data of cycling is analysed and predicted due to be based on the profile in which equipment properties are registred used for the cycling.
It's not necessary to exchange equipment one by one due to create profiles of bicycles in hand in advance. That may be a standard usage.

Besides, if you might like to create profiles of equipment which you have an intention to buy as same as equipment in hand, due to analyse GPS data of cycling based on the profiles, it could be analysed and predicted difference between equipment in hand and equipment interested as increase and decrease of load(power).
For an example, even if exchanging only wheels, due to create another profile with them, it would be possible to estimate comparatively by same GPS data files. It might be interesting to compare a flat course and a rugged course and so on. That makes the wheels to be estimated how aptitude and advantage they have in numerical terms.
In that case, it's ideal not only to set specifications but also percentage of power loss. Recently, manufactures tend to announce detailed features, e.g. inertia capability and stiffness, aerodynamic load and so on. And results of wind tunnel evaluation and flexure test of famous high-end wheels are exposed by publishers.

A right picture is a mapping of 21 century's eightyseven high-end wheels by Maximum Likelihood Analysis due to significant variables (aero dynamics, rim depth, spoke count, stiffness, weight, model year).
As for aero dynamics, it has a very strong correlation with rim depth and has a strong correlation with spoke count, has a correlation with stiffness. And it has a weak correlation with model year though, weight has a stronger correlation with model year, which makes us to notice that weight saving has been the trend around the time even if aero dynamics has much attracted attention.
Stiffness has a correlation with aero dynamics though, that's not a general trend but just a reflection of wheels which are dedicated to TT or hill climbing.
In case of wheel registration, it's recommended to set specifications and equipment loss in consideration of such features of individual brands.



It may be quite rare that a GPS logger with a high-end chip conduces an aberrant value as power prediction. However, if an aberrant value makes an appearance at once per several hundred kilo-meters as an example, maximum value as stats would be also an aberrant value.
That possibility is brought by an outlier of altitude which is happened by an environment of cycling. As for geo-coodinates and speed, distance, acceleration, it's vanishingly improbable to be outliers in case of checking "smoothing GPS data, outlier rejection".

For an example, in case of 60 kph downslope, if the inclination is inaccurate a large power could be predicted even though a low power is required for that. Conversely, in case of upslope, a low power could be predicted even though a large power is required for.

It sometimes happen that an aberrant value of power is recorded by the power-meter, and the Golden Cheetah has a function to edit it. The software does not have such a function. Let it agenda for intending version.
For an example, it's easy to set a threshold power value though, that method is too adhoc, However it's hard to make an adjustment the altitude value which is a cause of the aberrant power value.

As one of ways of coping, it's a method to use a map which performs corrections about altitude data. Whether a FIT file could be used for the map directly or not, that's depending on the map.

If such an aberrant value happens frequently, it's recommended to replacement the GPS logger.



Look into the worth due to charts by the Golde Cheetah.

A right picture is analysis charts by the Golden Cheetah due to import the FIT files which had been analysed and predicted power and cadence by the software "cyclingGPSToPowerSim" over six months.

It was impossible to ride so much till July cause the rainy season, it was intense riding in August though, it was devoid of so much oppotunity for riding in September and October due to various reasons.
Results are low level fitness data as for using the Golden Cheetah though, cause it's just data of fun-riding, please forgive that...
I was in hopes to make CTL value to be over 100 though, I lost momentum at hand. Idleness had made it kinda difficult to keep up the value, and it was impossible to turn up without mind to it.
Of course, it's required to analyse and registre correct CP and FTP at regular interval. Otherwise, it's likely that the CTL could be over 100 with ease.

There is a high reliable chart 'Speed Trend' in "Power & Speed Trend". Because it's calculated by the geo-coordinates.
And 'Power Trend' is orthomorphic chart to 'Speed Trend' as time-series variation obviously.
And, that variation is resemblant to "CP Analysis", "Power Variance", CTL of "PMC". As same, it's resemblant to "Aerobic Power" and "Anaerobic Power" and so on, which are not in a right picture though.

It's determined that the FIT files analysed by the cyclingGPSToPowerSim are utility to "evaluation and management of training based on the exercise physiology" which is the purpose of the Golden Cheetah.
Actually, CTL (Chronic Training Load) and its variation have been real physical things as a physical fitness index. And, in a period of higher CTL, averages of speed and power were raised unconsciously.

Perhaps, if each field value of every records could be checked, outlier value might be detected about the altitude and its variance. Of course outlier values were rejected as inclination values. And, even if so, there is no problem for the purpose "evaluation and management of training based on the exercise physiology".

Of course it's expected to get a super high accurate GPS logger at reasonable cost, and so we could get accurate data which bears comparison with data of the power-meter.



ver.0.16.00 above, it"s possible to detect braking, due to the GPS data, braking force and temperature of materials, friction heat, radiate heat both of front and rear brakes in each record could be predicted and be expressed. Those are predicted and expressed only in case of checking "detect braking" and power predicted.

Each prediction value might not be exactly except due to very high accuracy GPS data though, stats of braking frequency and mean, maximum, total of prediction values are seemed to close on correct values even if due to common accuracy GPS data.

That might be of reference to usage of safty braking. In concretly, it would provide reference data how to ride a long downhill course. It's worth noting that the temperature of materials.
That might be of reference to risk control about how heat the materials, how change the temperature due to riding style, whether stop in middle is better or not, and so on, even if the values is not exact measuring values.
Causes both of fade phenomenon and vapor lock phenomenon are overheating.






Not saying to put on speed in the downhill. It's no wonder to ride at safty speed. As that result, we have a overheating problem that requires attention.
In some cases, due to evaluation of overheating risk, it's required to stop in middle and to let the brake materials cool.