Logged Data

How GPSLogger will log your data?

The core idea since the initial version of the app is, that it does not have to be actively running with a visible screen while recording. You should be able to use your device for something else - or simply carrying the device in your pocket or bag/backpack while GPSLogger is logging the data.

Running as Android-Background Service

By default, an application have certain amount of screens (called GUI) and the code is running when the so called Activity is visible for the user. Even if GPSLogger have also such GUI part as mainly described here the main recording work will be done running in an Android-Background Service.

Starting a Background Service on Android requires that the code running will show the user always a (sticky) notification. Please note, that it was not my design decision to make this notification sticky!

This is a requirement for all 3’rd party apps running on Android (to make it possible for the user to realize that something is running in the background) - needless to say that Google makes an exception when it comes to apps/services they run themselves on your phone.

But since the sticky notification is required anyhow, you have the option to start/stop logging or terminate the app via the embedded notification actions.

info Information for Android 7 (or later)

The Android OS have different possibilities to extend the battery life of your device - one of these possibilities is to restrict the ability to allow apps to make use of the running-as-background-service capabilities. Of course such a restriction will be counterproductive when using GPSLogger. So the app is requesting you to disable the OS battery optimization for GPSLogger in multiple ways. For details see the FAQ: How to disable OS battery optimization

GPSLogger is designed to be battery friendly

Battery lives matters - that’s one of the core principles that drives me, during the development of the application. As developer, you have influence on the overall energy consumption of a device. So all parts of the applications have been designed in a way to make the code as energy efficient as possible (this means to use very simple structures and almost no frameworks).

Just as one example: GPSLogger don’t use an internal database while logging, instead the data will be directly written on your device. This makes the code a bit more complex, but on the other hand side this saves a lot of CPU-cycles (and with that plenty of energy will be saved).

The majority of the battery-usage of the app (while logging in the background) is caused by requesting & receiving the GPS-signal. So by adjusting the GPS-update interval in the application settings you have a direct influence on the overall battery-consumption of the application - adjust it to your use case!

Have also in mind that different sensors might use additional energy - my personal observation is, that using the build in magnetic sensor (aka compass) of my current Pixel3 phone have an almost insane negative impact on the overall battery life - while the intense usage of the barometer sensor seams to have almost no impact. So the total battery consumption really depends on your hardware and the settings (update frequency) you are using.

And without going too much into details here - since you might like to use different update-intervals for different use cases the app offers a Multi Preferences/Modes Feature allowing you to adjust quick & easily the settings.

Data is stored ‘as it is’ (raw)

GPSLogger is following a very simply (but strict) principle: always keep the original data! It’s almost the nature of GPS (and other sensor) data to be a bit flaky. It can be required for certain use-cases to apply some optimizations (like smoothing values over a certain time period). But you don’t have to be afraid, there are two very important things you should know:

1. All calculations/manipulations will happen after the raw source data have been captured and stored inside the GPL file. So all optimizations will always happen afterward - the original data will never be altered/modified!
   
   This ensures that when ever something will be messed up inside the application (e.g. cause of a bug) it can be always be fixed with update of the GPSLogger application!

2. All possible data post-processing can be disabled via the application setting (or needs to be enabled by the user at the first place). IMHO it’s essential that the user can decide if and when how the sensor data should be manipulated. GPSLogger is no BLACKBOXhelp_center nor it does any miracles - If you have a question - do not hesitate to ask!

Sensor data will be logged independent of each other

Even if it might not make a big difference for the user - but in case you are technically interested: GPSLogger stores the data/fields for each supported sensor as separate/different record-type. By following this approach, it’s quite easy to introduce new sensor types/data without invalidating any existing files.

When multiple sensors provide their measurement at the same time, the app creates multiple entries (obviously of a different type and with different data) and queue it in a synchronous writing process.

high_quality Recording with a resolution of one millisecond

Even if most (if not all) website processing location based information have a minimum resolution of one second GPSLogger stores and process all it’s data with a precision of one millisecond. This additional precision caused several issues (e.g. when you upload data to sites like Strava) - but at the end of the day these challenges are solved.

My assumption is, that the source of this one-second-limitation is, that a) most available GPS providers will not provide data more frequent and b) a lot of common sport activity tracking hardware (like sport watches or bike computers) have the same one-second-resolution (probably cause of hardware limitations).

This resolution is also present in some quite popular file formats, like Garmin’s FIT format or TCX (where the fields of the type dateTime has also only the resolution of one second).

I am convinced that this difference matters! (might be not such a big surprise, since I have implemented it)

In the past few years I have developed some sort of passion for riding with my road bike. While cycling, I’m typically pushing the pedals with a cadence greater than 60 revs per minute. With other words in one second I do more than a single rotation of the crank. When I additionally process data from a power-meter (pedals) then it’s IMHO essential to know in which fraction of a second a certain power value was provided - specially when reading power-meter data from left and right pedal individually (what I actually do).

So for me, it’s a bit difficult to understand, how almost the complete world is accepting this one-second-limitation - especially when reviewing/comparing different power-meters (based on data recorded with ‘BLACKBOX’ Garmin bike computers and exported FIT files) - IMHO it’s no big surprise that data from two sensors must be different in such a comparison. [I am sorry for this rant].

What values/data will be logged?

Internal device sensors

GPS & NMEA-Data

GPS/GLONASS/Galileo based location information

GPSLogger is processing location objects provided by the OS of your device. The app does not have much influence on the quality & frequency in which the OS is going to be able to provide such location objects (despite the app can request to receive the location in a lower frequency then the OS is able to provide the data).

Have said that - specially when you are indoors, the chances that your GPS signal is quite bad, is quite high (this also applies if you are outdoors but surrounded by high buildings or trees).

On your device there might be alternative location information providers available (e.g. WLAN-based), but GPSLogger is not using them by purpose!

The following information is stored everytime a new gps based location have become available to the app:

• Timestamp (in milliseconds) when the location was received on the device [Please note that the location object itself contains also a time information - this internal time information will be ignored!]
• Latitude
• Longitude
• Elevation in WGS84¹ (also known as Altitude or Height)
• Course (also known as Heading or Bearing)
• Speed (in m/s)
• Accuracy (of the location information)
• Number of Satellites used to generate the location
• GeoIdHeight (if available)²

When you make use of the indoor rowing/treadmill functionality of GPSLogger then the device GPS signal will be ignored (the GPS location provider will not be requested to send any data to the app) and instead simulated location objects based on the selected route and your current provided speed (no matter if you are rowing or running) will be created. In this case the stored location information is internally marked as simulated by using the value -10 as Number of Satellites. Obviously no accuracy or any additional NMEA-data will be available for this type of simulated activities.

NMEA Sentences

• Timestamp (in milliseconds)
• Collection of NMEA-Sentences as PLAIN-ASCII String (the device might provide multiple sentences with the identical timestamp)

More information about the format and the content of NMEA-Sentences can be found in wikipedia.

Magnetic Sensor (if available)

You caught me - I am a liar! Have I said, that all sensor data will be recorded independent of each other? I am sorry - for historic reasons this statement is not correct for the magnetic sensor data.

When a new GPS location information arrives, the original course value withing the gps location information will be overwritten with the newest (if not older than 1 sec) course value the magnetometer has provided. Shame on me!

Barometer Sensor (if available)

• Timestamp (in milliseconds)
• Current ambient air pressure (in hPa or mbar [as decimal])

Please read Using Barometer based Elevation - Theory of operation for further details why recording pressure information can massively improve your logged elevation profile.

VAM Data

When you record an activity where you have loaded a navigation path and the app could extract climb data (see Climb View for details) GPSLogger will store (while you are in such a detected climb section) multiple VAM data records in order to be able to show your velocità ascensionale media (translated in English to mean average ascent speed) performance after your activity.

• Timestamp (in milliseconds)
• Current VAM (ascent speed in m/s [as decimal])

BTLE Beacons (in range)

Details about the Build in UUID Beacon Scanner can be found in the corresponding section of this manual.

The scanner is logging the following value (per detected beacon):

• Timestamp (in milliseconds)
• Containing data package (as plain byte[])
• Beacon type & address (as String)
  • Type and address are seperated by a @ character from each other
  • Type can be either 0: FD6F or 1: FD64
• RSSI (as Number [Integer])
• NanoSeconds (as Number [long])
• Total Number of visible beacons - including the current one (at the time the beacon was detected for the first time)

sensors External Sensors

Details about the currently supported additional external sensors can be found in the corresponding section of this manual. This section here covers only the data fields that will be recorded per sensor.

Heart rate Data

• Timestamp (in milliseconds)
• Current heart rate (in beats per minute [as integer])

Cadence Data

• Timestamp (in milliseconds)
• Current cadence (in revolutions per minute [as integer])

Cycling Power-meter Data

• Timestamp (in milliseconds)
• Current power (in WATTs [as integer])
• Power-meter index (could be 0: center, 1:left, 2:right)
• Balance between L/R (when available)

Shifting information (Shimano Di2)

Initially the app stores in a path the configured number of front & rear gear teeth (so when you change this gear setup later, your recording will always include the information that was present when recording).

• Timestamp (in milliseconds)
• Front gear position (0-4)
• Rear gear position (0-14)
• Resulting gear ration (only cause of historic reasons - the data is actually obsolete)

GearShifting Data has one speciality that should be mentioned: The app will always record shifting events, even if they occur while the app is in the PAUSED-RECORDING mode (so they can’t be missed).

rowing FTMS Rower Data

• Timestamp (in milliseconds)
• too much (will be done when I even will have more time to do this)

rowing Concept2 Rower Data

• Timestamp (in milliseconds)
• way too much (will be done when I even will have way more time to do this)

How to access / export the data

The GPS file format

When I will be ever in the right mode, I am going to release details in GitHub. For earlier file versions there exist external reading code - but since the changes introduced with the V6 implementation nobody seamed to be interested in an updated version - so probably this will take some time (but the format is no secret!).

File Export

The JSON-Export is the closest format you can get from GPSLogger - this will include (almost) all fields and data. Why almost? The BTLE-Beacon information currently will not be written into the JSON file. Use the dedicated CSV-Export when you want to get your hands on the BTLE Beacon data (see the Build in UUID Beacon Scanner) for details.

---