While bicycles appear to have standardized around a relatively common shape and size, parts for these bikes are another story entirely. It seems as though most reputable bike manufacturers are currently racing against each other to see who can include the most planned obsolescence and force their customers to upgrade even when their old bikes might otherwise be perfectly fine. Luckily, the magic of open source components could solve some of this issue, and this open-source bike computer is something you’ll never have to worry about being forced to upgrade.
The build is based around a Raspberry Pi Zero in order to keep it compact, and it uses a small 2.7 inch LCD screen to display some common information about the current bike ride, including location, speed, and power input from the pedals. It also includes some I2C sensors including pressure and temperature as well as an accelerometer. The system can also be configured to display a map of the current ride as well thanks to the GPS equipment housed inside. It keeps a log in a .fit file format as well so that all rides can be archived.
When compared against a commercial offering it seems to hold up pretty well, and we especially like that it’s not behind a walled garden like other products which could, at any point, decide to charge for map upgrades (or not offer them at all). It’s a little more work to set up, of course, but worth it in the end. It might also be a good idea to pair it with other open source bicycle components as well.
Thanks to [Richard] for the tip!
Why not use a phone?
Because this is Hackaday and not Consumeraday. Maybe the dev wants not to code in Java, but in Python. Maybe he wants to interface with his Garmin. I don’t see why you would want to use a Phone and drain the battery.
because this solution is completely offline – I still know places in my country, that can be reached by bike, but not technology :-D
not to mention some apps stop working as soon as they loose internet connection
If we’re being pedantic a bike is technology too, haha.
A while ago I was goofing around with old android phones and offline GPS maps. There’s a decent amount of stuff you can do with them, although the screens would be completely unreadable in sunlight. I wonder if you could take an old android-based ebook reader and just connect a GPS receiver and gigantic battery to it via the USB port.
OSMAnd can be used completely offline, but the downside to using a phone is battery life, boot up time, etc.
Phone suck their battery really fast, they tend to not play well under the sun far too long, and we don’t want lost a mean of communication when the battery drained
But we mostly did it to shave of weight, because every weight counts!
But you still carry the phone so a bike computer is actually added weight. And to prevent draining the battery an extra battery (i.e. power bank) would be enough, so these aren’t really arguments in favour. The sunlight, easier handling (I find touch screens hard to operate while riding), likely lower power consumption, etc. are.
Why create?
Personal answer – sometimes I forget to pull my phone out of the sleeve when I park and then run back to the bike to check it’s not been nicked.
Must be nice to live in a place where a bike computer won’t get nicked if you leave it on a parked bike.
Be nice if it was built into the handlebar.
Well, I suppose it’s better to lose this $100-$200 dollar device (depending on the sensors chosen) vs a $500-$1000 phone. But yeah, just don’t leave one’s property insecured.
Apple recommends against mounting phones to motorcycle handlebars to protect the camera’s Optical Image Stabilization system from vibrations (and to a lesser degree, electric scooters and e-bikes are included in their warning.) And some people don’t want to expose their thousand dollar phones to the hard shocks that are transmitted from trail bumps and potholes.
A dedicated bike computer doesn’t have those vulnerabilities.
This is a good motivation. I’ve had my Samsung S10 camera get ruined by mounting it on my motorcycle and heard countless people to which the same thing happened with different phones.
The amount of money and time you have to spend to get a phone to talk to the $800 of ANT+ instrumentation I have on my bike (power meter, heart rate, cadence, pulse, oxygen saturation) is significant and then you have even more proprietary software and hardware.
I used to think this too. Then I found that my mobile would quickly overheat and shut down the navigation app on sunny summer days, that I can’t see much the reflective screen anyway even before that happens, that the touch screen is cumbersome to operate while riding and the protective mount/case just makes all these worse. And the battery life is nowhere near the 18h promised by the above device. While high temperature will quickly degrade the battery of your phone.
On the other hand, for sure the bike computers just look like dumbed down smartphones (best case, worst case they are totally closed platforms with fixed functionality). Though I’ve never used one., maybe they are fine. But as others talk about the price: they aren’t exactly cheap either.
I was thinking maybe I could build one with an ePaper display for good visibility during the day. Though maybe a matte OLED/TFT would be better. If this can be built to tolerate direct sunlight during the summer and rain resistant, it might make a lot of sense. Though you probably want to be able to run android apps too. As, honestly, the mapping apps for phones look pretty good and I’m not sure if bike computers have better ones. And some of them will allow you to side load android apps anyway.
OSMAnd seems to be a pretty good one, actually better than all the others I have tried. Unfortunately the mobile apps for services that offer an acceptable online planning experience (e.g. komoot) are pretty bad.
Consider transflective displays, better readability in sunlight and can save power with the backlight off during the day.
Why not use a Sandia Labs Supercomputer with a laser uplink?
Cause its overkill to use a $1200 computing device (most people tend to think flagship) when doing this, or one that also depends on updates and planned obsolescence in the case of android and ios devices more generally. Those are the things this project explicitly set out to do away with.
If you enjoy building it why not but GARMIN has so many units as such good price points and supports the devices over long periods of time
What level of openness or closedness is the Cycle Analyst?
I’m wondering how much information is absolutely needed on-screen during a bike ride and how much is “nice to have”. The UI and feature set looks quite impressive and comprehensive. I love how it displays energy in kJ. I’m quite certain if the map display was not needed the device could be scaled down to a small microcontroller writing to an SD card or something similar
Also kinda curious to know how many people actually use ANT+ devices. Do they offer any advantages over BLE? Never seen any out in the wild but I hear most athletic sensors use it.
We usually monitor our speed, cadence, and power in kJ throughout the cycle. Mostly to target how our workout to be effective and efficient. We also use this data to make decisions on when should we rest and how much calories do we actually need to take throughout the workout.
Most athletic sensors use ANT+, because as far as I know ANT+ protocol can stream more data than BLE. However I might be wrong and biased, so take my opinion with grain of salt.
I never bothered to find out what the ANT[+] apps on my Samsung phone were about.
I’ve had bikes with too much information. Latest (e) bike just has time, distance, and battery state. That’s plenty.
Tire inflation status.
Unfortunately, most older hardware was only ANT+, most notably significantly expensive Powertap hubs, of which I’ve several.
You don’t need all that data. Keep your eyes on the road not on the screen. Hit one pothole and your day may be ruined.
The key difference between ANT and Bluetooth, was that ANT worked reliably.
ANT had a single source software stack, and it was the core business of ANT.
Bluetooth (beyond phone and earphones) was an afterthought of random big consumer companies, and worked just as reliably and interoperably as that sentence would lead you to expect.
There were various technical differences – the important one was that ANT lets multiple computers talk to the sensors i.e both your phone and your bike computer can read your heart rate and pedal power at the same time.
I think BLE now has this capability, but again, ANT+ works properly.
ANT is specifically designed for low latency small packet comms and saves battery power significantly better than BT (and slightly better than BTLE). BT also requires much more software overhead and paid royalties. TCFKAR mentions Samsung; I used a Galaxy View tablet (that I’m typing on now) to control my trainer while reading heart rate, cadence, and power from both bike and trainer for years. BT typically does not support as many channels due to the overhead (for example on the Apple TV that I use now).
Good for them! This looks like a cool mini project.
You may want to check out Jazda open bike computer project based on smartwatch hardware: https://www.jazda.org/
That’s a nicely made bike computer. I might actually make this, and modify it so I can use it as a computer on my motorcycle. I don’t need most of the sensors either.
Same thought here, i like the rain overlay ;)
I worked on my own power meter. I had ANT and BLE support. ANT is much easier for the devices. It’s just a constant stream of the data. Nordic makes a nice Cortex M0 based chip that can do both. But when I buy my HRM, Cadence Sensor, Speed Sensor, Power Meter, most of the time they cheapest models only have ANT+. I have to pay a premium to get BLE.
the mapping functions do call out for a larger computer but i still am here to say what i say every time…the pi zero isn’t suitable for mobile applications. you’ll be charging your battery as often as if it was a light (instead of every 12-24 years like for the $15 cycle computer i use), and you’ll be waiting for it to boot up too. and it’s hard not to imagine that the complexity of linux won’t attract a host of problems as well that will ultimately burn you out as a user.
anyways, the perfect chip for this game might be the rp2040. just sayin
more to the point, i have a hack to recommend. i thought about making something like this 20 years ago, and then i found out the mainstream cycle computers are so cheap and i lost interest in it. but then i noticed they’re all garbage that die in the rain right away…and for no reason, they have awful physical connectors built into them because they expect you to pull them off of the bike every time you get off of it, for “theft prevention” (for a $15 toy, what?). and i’ve had a couple that just fly off the handlebars, sometimes even when i wasn’t touching them. so here’s the hack: after you replace the battery, hot melt glue that sucker together. the contacts will now last for as long as the battery will, and the thing won’t go flying off in the road.
whoops! 12-24 months, not years :)
Your definition of bike commuter doesn’t match what this hackaday is about… The industry norm for anything more than a glorified odometer/speedometer (the $15 planetbike things you describe) is a GPS+friends tracking platform with a 17 hour all summer daylight battery life with nice display, backlit at night, and logging once a second – including data from a dozen sensors, many ANT+ and BLE based.
A Wahoo Elemnt for example runs Linux (Android) under the hood and is not dissimilar to what was built here in spirit. The Pi Zero isn’t designed as low power itself (it’s a hungry media processing chip), but plenty of mmu enabled chipsets are. The original wahoo was built on an old smartphone platform under the hood.
It is all irrelevant to the consumer what is under the hood on any of the commercial units.
This must be great fun to build :-)
I have always wanted to build a bike based video game controller to use for racing games while on the trainer.
I haven’t purchased a new bike computer for about twenty years and was really surprised they all now are GPS computers and do not require the installation of magnets and hall sensors anymore. I was pretty impressed with the features of my el-cheapo one I ended up buying, but wish it was more customizable and didn’t require a proprietary app to use some of the features. Fortunately at least I confirmed you don’t need the app for it to work before sending it right back.
This build looks rad. Awesome work.
phones have screens that only use their own light (either transmissive LCDs or OLED), which for typical bike uses means they need to outshine the sun. That alone makes phones ill-suited. They’ll still work for casual cyclists or in a pinch, but overall rather meh.
Bike computers and most sport watches use reflective LCDs, so they get brighter with the environment and only need to provide their own light when it’s dark around.
Just an FYI, ANT makes a usb dongle that could potentially be connected to the PI Zero to access existing ANT bike peripherals.
If you look at the code and/or the hardware setup document in the repo you’ll see the author already supports ANT+ via a dongle (and a wide range of devices, e.g. HR, power, etc). What isn’t currently supported are BLE devices.
Sounds like amazing.
It’s a pretty useless project unless you live in Japan. Otherwise all of the screens are unobtainable. You will spend more trying to get a screen that works with the dumb Pi zero 2 (doesn’t have a DSI connector) and all the kludging you have to do to get it to work. Again, unless you happen to live in Japan.
For anyone else that wants to buy a bike computer that also doesn’t track and sell you like the ones you can buy: Arduino Portenta H8. It sucks more power, but it at least has the needed screen connections so you don’t have to have that massive pouch thing. You can actually attach it in a way that doesn’t create a sail.
There, saved you hours of time and money trying to get the major components for this thing that don’t exist (the pi and screen).
I’d not seen the Arduino Portenta H8 so thanks for the call out, I’ll have a look. You still have the problem of selecting a suitable screen and making the whole thing waterproof. You could use a standard RPi TFT screen (and run the above code, as this is supported “out of the box”, though I note getting hold of a RPi is still rather tricky), but it will impact battery life and being able to see it outdoors is not ideal (having made something similar during lockdown). You will also need the pouch or some industrial engineering skills to make an encloseure that is suitably waterproof/resistant (certainly if you live in the UK!).
After much messing around trying to find suitable screens and working out how to waterproof a device, I finally elected to find an existing headunit on which I could replace the stock “firmware” with my own. The TwoNav devices run vanilla Linux (as do Giant/Stages Dash fwiw), have big batteries and although don’t have fully transflective screens (like the linked project and the Garmin Edge devices) they are low power and sunlight readable (Blanview).
I’m in the process of porting/wholesale modifying the code linked above to run on these devices (a TwoNav Cross fwiw). I will post the whole lot + installation instructions to github once I’ve got it working to my satisfaction (recent sunny weather has slowed progress ;)) – I’ve been prototyping on the PC (the wonders of cross-platform Python code) and amongst many other changes am currently re-implementing the way the code handles data/metrics so that there is less hard-coding, the ability to support plugins to add arbitrary new metric processing and more importantly can replay data from a log file (e.g. .fit/.tcx) to let me test in the comfort of my home, rather than while out riding.