Apps for Cycling

Is anyone aware of any free/libre app (be it in the f-droid repo or in gplay) that supports connection to a bluetooth bike speedo and/or cadence sensor?

Optimally with map and bike-routing, track recording etc. to turn the smartphone in a full featured tour computer?

I thought of buying a bluetooth speed and cadence sensor, but I don’t see whether there is a “standard” kind of protocol they are “speaking” or whether the used protocols are hard or easy to reverse-engineer.

1 Like

Hi ramack,

I have been searching for this as well but I am not aware of such an bicycle app. Might have overlooked something - glad if someone gives a good pointer!

Map and bike routing could be done with OsmAnd (on fdroid too).
OsmAnd is pretty flexible (you probably know, just stating: the data it operates on is free/libre, can be used offline, its routing cost functions can be changed, the underlying routing engine can be changed (e.g. to BRouter “Let’s get serious about bike routing”) and it has an API other apps can connect to)

Maybe also RunnerUp is an application to watch. I haven’t used it myself but it seems to have lots of things in place.
There might be two drawbacks though: a) it’s for runners;) b) it’s been excluded from fdroid builds because it uses ANT+ libraries (not compatible with free/libre and RunnerUp currently cannot be compiled without).

Eventually look for speed and cadence sensors which support both ANT+ and bluetooth. This helps if you ever plan to see your data both on the smartphone and a dedicated bicycle computer.

Once you have your ride data colllected you might be interested in the excellent GoldenCheetah (PC software, GPL v3, Linux, Mac OS X, Windows) for post ride analysis.

Thanks for this long answer. I am well aware of osmand and I use it for hiking and cycling and for sure car navigation. But some features are missing. E.g. nice track organization tour comparism (last time your have been here 5 min. earlier, etc.) and the support for speed and cadence sensors.

oruxmaps - no FOSS app (!) but provides the features you are looking for, ad-free, usage of offline vector maps (e.g. openandromaps based on OSM, for free as well), offline routing (e.g. BRouter), organizing/editing/sharing tracks, routes, waypoints…, supports ANT+ and BT devices.
Free version was removed from gplay because of violating the payment rules, apk download on the developer’s page. There’s no difference between this free apk and the paid version, which is still available in gplay.

oruxmaps could be interesting - if it just would be free :slight_smile: it also doesn’t seem to be too hard to implement a free app, as the interface to devices like speed and cadence sensors (but also heart rate, etc.) via Bluetooth LE (LowEngery, Smart,…) seem to be standardized.

Anyone with some free time available?

Hallo, as stated before, there are a few challenges for such a fitness app / implementation, some of them have been mentioned by previous posters:

  • Bluetooth: (Some of) The Bluetooth specifications are standardized, heartrate and cadence should generally work, but many hardware manufacturers of fitness trackers, GPS watches or electronic shifting systems rely on proprietary formats (Not FOSS)
  • ANT+: Ant+ relies on proprietary libraries, which are not published as open source (Not FOSS) (See: Source code of ANT+ Plugins Service · Issue #1 · ant-wireless/ANT-Android-SDKs · GitHub), which led to the F-Droid removal of RunnerUp
  • Maps: With OpenStreetMap an excellent provider of maps is available
  • Routing: While several routing providers offer free start packages, these offers are generally very limited. In general these services require an API key and valid / profitable business model.
    Examples: Google (recurring $200 credit), Mapbox (50,000 monthly active users, 50,000 geocode requests / mo, 50,000 directions requests / mo, 50,000 Matrix elements / mo); Here (250K transactions per month, 5K SDK monthly Active Users, 250 Managed Assets per month); MapCat (100,000 Visualization sessions*/mo, 3,000 Search requests/mo, 3,000 Directions requests/mo), Graphhopper (Credits 500 per day, Max. locations / request 5, Max. vehicles / req. 1 vehicles)
  • Weather: While several weather providers offer free start packages, these offers are generally very limited. In general these services require an API key and valid / profitable business model.
  • Data Politics / Privacy: Many commercial / proprietary apps provide centralized services, vital / health and fitness data is often sent to other countries / beyond legal and social control; Decentralized networks to share, sync and process health and fitness data are currently still in developments - at the moment users basically lose control over their data when they press the start button of their app.
  • Data and Formats: Many commercial / proprietary apps do not allow users to download / extract / process their original data, at best these providers provide aggregated, lower quality sync functionality via dedicated interfaces. Users would eventually be interested in the original data, and might prefer open / inclusive data formats.
  • Health: The integration of vital and fitness data into healthcare is just starting, different requirements, standards, and regulation efforts do not always promote such proposals.
  • Open Source Effort: The effort required remaining uptodate / compliant with several platforms (Strava, Endomondo, Map My Track, Runtastic etc.), many devices (Pebble, mi, Garmin, Fitbit, Withings) and different Apis is quite significant, especially when these providers not always support (Open Source) development efforts.
    One of the best examples for such a continuous effort is GoldenCheetah (https://www.goldencheetah.org/) - desktop software (Win / Mac, Linux) initiated by Mark Liversedge.
  • Algorithms: With more and more sensors, wearables, and other digital devices the sport sciences have seen dramatic changes in the last years, which leads to rather fluid, moving field of expertise, especially for analytics, performance analysis, recovery estimates etc. Even apparently simple assumptions, for instance for the MHR (HRmax, Maximum Heart Rate, crucial for heart rate training zones for instance) , can be described by at least a handful / different algorithms, partially reflecting the diversity of the human race / gender / age / body. The same applies to power, cadence and calorie consumption.
    Examples: Inbar et al.: HRmax = 205.8 − 0.685 × age, where age is the age of the person in years
    Karvonen / Haskell, William and Samuel Fox.: HRmax = 220 − age, where age is the age of the person in years
    Londeree and Moeschberge: HRmax = 206.3 − 0.711 × age, where age is the age of the person in years
    Wohlfart and Farazdaghi: HRmax = 203.7 / (1 + exp(0.033 × (age − 104.3))) (for men)
    Wohlfart and Farazdaghi: HRmax = 190.2 / (1 + exp(0.0453 × (age − 107.5))) (for women)
    Nikolaidis 2014: HRmax = 223 - 1.44 × age
    Nes et al. 2012: HRmax = 211 - 0.64 x age
  • Trademarks: Some companies have registered trademarks for terms used in many popular devices, even though the underlying algorithms / formulas have been in the public domain since inception. Projects unable to secure approval from the trademark holders thus face limitations when using these de-facto “standard” terms. GoldenCheetah and other platforms have to develop, introduce and standardize alternative terms and algorithms.
    Example: Coggan, Andrew R. “More to the point: all of the algorithms have been in the public domain since day 1, and nobody has to pay me (or anyone else) a dime to use them.” in: SlowTwitch. Garmin has acquired MetriGear. Triathlon Forum. September 21, 2010.
    Coggan, Andrew R. “Peaksware LLC has laid claim to the trademark of the various terms (as is their legal, if not necessarily defensible, right, being the successor of the first entity to use them in commerce).” in: SlowTwitch. Garmin has acquired MetriGear. Triathlon Forum. September 21, 2010

Disclaimer: My apologies for the long response. We are currently working on such a framework, and face the issues stated above. Our research framework integrates health and fitness, Bluetooth / Ant+ / NFC, Google and Open Streetmap, decentralized storage vs. GoogleDrive/DropBox/OneDrive and NextCloud, Weather. etc.
Because of the Api / library concerns stated above, it is doubtful, that such an understanding of free (freedom of choice) would ensure inclusion in F-Droid.
(Unfortunately).

2 Likes

Adding a few more lines for @ramack @critdroid @frief

  • Elevation: Elevation services, necessary for power analysis, effort calculation and routing options, are based on large datasets, which either require large files / storage consumption on the device, an online internet connection to a centralized service, and or corresponding apis of proprietary services.

  • API Fees: Some providers / platforms rely on licensing / usage fees. In general these services require an API key and valid / profitable business model. (https://developer.garmin.com/garmin-connect-api/overview/)

  • Material Design. The new iteration of Material Design also needs significant efforts to remain uptodate, basically recoding parts of the UI.

  • NDK: The Android Native Development Kit, allowing the integration of code libraries in native code, using languages such as C and C++, is yet another challenge (See: Reproducible Builds), builds with the NDK are considered much more sensitive at F-Droid.
    (Example: Hyperledger. GitHub - hyperledger-archives/iroha-android: Android library for Iroha, a Distributed Ledger Technology (blockchain) platform.)

I hope these thoughts prove useful.

Disclaimer: We are currently working on such a framework, and face the issues stated above. Our research framework integrates health and fitness, Bluetooth / Ant+ / NFC, Google Maps and Open Streetmap, decentralized storage vs. GoogleDrive/DropBox/OneDrive and NextCloud, Weather. etc.

Sounds interesting. Will your APP be free and available in F-droid? Do you already have something that is published?

@ramack: App Availability: We are still working on the prototype, a link to the most current beta release is available in my F-Droid profile. The prototype is not available via Google Play, but beta testers are currently invited / included via HockeyApp.
(Please note that in the prototype we still include several bug tracking / analytics solutions which we might deactivate / delete in final release versions. We are currently providing a new beta release every week.)

Code Availability: Unfortunately we have not yet published / shared any code. We are preparing a shift to open the framework for the development community, potentially FOSS, we are cooperating with other partners, and if there are already interested developers / researchers, then we will figure out a way to integrate them.

Framework: As it is still developed as a research project, the app prototype is free, primarily intended for research and academe, with a strong focus on data security, privacy, analysis, science, and data portability. A release to a wider public will to be defined in the near future - this includes Google Play, Amazon and F-Droid.

Priority: Our priority is a secure, scale-able framework, bridging fitness, sport and health, guaranteeing users to exercise control over their data at all times, with a device and manufacturer agnostic philosophy, a feature set comparable with leading commercial solutions, the capability to import and export all data whenever desired, and the implementation of a federated, distributed / decentralized and encrypted network / vital data brokerage.

Free: As explained in my previous lines, the need to include third party data sources (maps, elevation, routing, weather, wind), NDKs (Hyperledger), APIs with API keys, integration fees or NDAs (Strava, Garmin etc.), or proprietary libraries (Ant+) might make an inclusion in F-Droid difficult (See: RunnerUp)

While I understand and respect the considerations of F-Droid, for us user needs and requirements are (at least) equally important. A dedicated F-Droid release, as provided by several other apps, would (currently) most likely miss crucial functionality and be less useful for the user.

(This is my current understanding, and I hope that this will change.)

Testing: Feel free to explore the (currently non FOSS, not Google Play, not F-Droid) release of the app via the link I made available in my F-Droid profile. If you have any suggestions, then please let me know; if I have missed something, if we can somehow provide a workable path towards F-Droid, then I would be delighted to consider this as well.

Outlook: We have just finished an integration of NextCloud, at the moment we are integrating navigation and routing, and we will implement performance analysis, recovery, and weather, integrate (even) more devices and platforms, and create a federated, distributed / decentralized and encrypted network / vital data brokerage.

Thanks for the longish reply - even though it is not really relevant in this thread, because it is about a free (libre) open source app for cycling.

You mention a lot of topics that are completely irrelevant for a “usual f-droid user” because you discuss mainly about non-free services and libraries. In case you consider them so important that a free, f-droid-compatible version of your app and/or framework variant would miss “crucial functionality” the focus you put is probably not inline with the f-droid community. A user who cares about freedom and full control over his/her devices will not buy such that are only accessible via proprietary protocols and libraries.

How could you focus on security, while including closed libraries where even you as developers have no control over what they do with the data? - This is like trusting skype or whatsapp that the communication is really secure, just because they write “this chat is now end-to-end protected”…

@ramack Thank you for your honest feedback. If this is alright for you, then I would prefer to keep the discussion generic / FOSS centric and not app specific.

In your original request you were interested in Bluetooth speed and cadence sensors - as I wrote, most speed and cadence sensors implement the standardized Bluetooth speed and cadence profile. Heartrate (HRM) is another standardized profile that is generally available for “normal” Bluetooth based chest belts. (FOSS ok)

There are however several devices, which only communicate via Ant+ and then the FOSS model might not work, because the libraries seem to remain proprietary. (As I have pointed out) Dedication to F-Droid would currently eliminate any support of ANT+ devices. (Feel free to have a look at the Ant+ device directory - and yes, you will there find many bike computers, bike power meters etc. which other cyclists apparently find relevant: https://www.thisisant.com/directory/ - another proposal would replace ANT+ software with a dedicated device bridging ANT+ and Bluetooth. Example: O’Synce Coachsmart) (FOSS ?)

If you are really interested in cycling, navigation, endurance sports, performance measurement and analytics, then you will eventually notice, that for instance elevation or weather can have quite a significant impact on your ride, which many cyclists - contrary to your opinion - would classify as relevant. For those requirements, other limitations can arise (third party data / Apis) , as I have clarified previously. (FOSS not ok)

If you wish to integrate data from additional sensors, wearables or fitness trackers, if you wish to integrate such data into specific fitness platforms or health care systems, then you will find, that most of these devices / platforms require dedicated Apis / Api keys, NDAs, NDKS, licensing fees etc. which might pose a challenge for F-Droid (as I understand it). (FOSS not ok)

Granted, your initial inquiry was about an app based solution, but you might find, as have many other athletes, cyclists, triathletes etc., that there are activities, where the app might prove useful for processing and analyzing the data, while dedicated devices are more appropriate (swim in triathlon, long bike tours vs. cellphone based tracking / battery constraints, etc.)

While in general the FOSS idea is absolutely admiring, honorable and convincing, and this is why we are looking for ways to participate - when users (at least currently) loose access to many available devices, miss third party data or functionality, then I am not always certain, if this improves the user experience, if this is in the interest of the user.

Sometimes the picture is unfortunately not always black and white and the development decisions can be more complicated, balancing different, partially opposing needs. In our case the decision was made, to include open / free solutions whenever possible (As I indicated previously) - allowing a user to make a “free”, conscious decision (free = freedom), between for instance Bluetooth and Ant+, between Google Maps or the several maps provided by Open Streetmap, or between Google Drive and NextCloud -

all of these choices are literally just one click apart. We simply aim to empower the user by providing these alternatives - forcing the user to accept one solution only is not unfortunately not compatible with our coding preferences I am afraid.

The next point also does not render your argument invalid, but Signal Protocol library used by WhatsApp is open-source and published under the GPLv3 license. (Signal Protocol - Wikipedia) Hyperledger is published under the Apache 2.0 license … etc. etc.

A cycling / fitness app providing similar features to those offered by commercial / proprietary solutions is quite complex, and thus includes a diversity of specifications, interfaces, and data sources, which are (unfortunately) not (yet) all available for free / as FOSS. I have provided a few of these challenges in a previous response - if you personally do not need all functions, the better.

Sidenote: Just to be clear: If FOSS alternatives would be available for these requirements, we would be delighted to implement them right away. I hope, that these alternatives will be created shortly.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.