DIY bicycle computeer

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

This is a project of mine that may or may not meet your definition of completeness. If you think about something that works reliably, is documented and usable, then consider it complete. If it's something polished, finished and never worked on again, then this is not a complete project.

Regardless, here it is: an AVR-based bicycle computer, using AtMega8 and Nokia 5110 display module.

the project is open source, including software and hardware. It's quite easy to build - I have more experience in software than hardware. Regardless, I made a tutorial available on the project page, if anyone wants to make one.

Features:

    Current speed Maximum speed
    Average trip speed
    Crank rotation frequency
    Trip time
    Trip distance
    Speed vs distance and time plots
    Wheel circumference configuration
    Backlight

The real power of this device is the ease to add new features and sensors - the project wiki has a full documentation of the API needed to achieve this.
It should be quite easy to port to some other microcontrollers (Arduino) or to attach different screens to it.

This is how the device looks so far:

And on a bicycle:

If there's some real interest in the project, I'm planning to keep working on it. Obviously, it needs a better packaging, and I have a few features on my mind too (clock, SD card logging, compass/GPS sensor etc).

The project page: http://rhn.github.com/jazda/

There you can find the source, schematics and all the necessary guides to start hacking on it. To build it, you need the GCC toolchain, and it's been tested only on Linux.

If there's anyone else who wants to try it out, I will be more than happy to help. Also, patches/ideas welcome :)

EDIT: to the admins: adding a file to "projects" gives me

Failed to load module Freaks Files (at function: "saveFile")
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

Nice. Have a look at www.biobike.us
It uses both ANT and Bluetooth.
Consider adding an ANT+Sport module to your project. From there you can add pedal power meters (Quark or SRM), speed+distance, heart rate etc.
This product uses the AT91SAM7A3 which is now NRND. :cry:
Since I've been using an XMEGA :D on a new project I may switch when the time comes.

Andre

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pozdro,
LCD interfacing example proved to work on:
http://iteadstudio.com/store/index.php?main_page=product_info&cPath=19_21&products_id=260
carrying Atmega88 @3,3V running virgin settings. Built with AVRStudio 4.18/Winavr on w*ndows.
Might be an option for HW, indeed. Board can accept Atmega168. BTW display was also sourced from iTead. Methinks together with digital debouncing, coin cell/LiPO and some power management shall be quite usable.
Don't take this wrong: a great project!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Labas!

Thanks for trying it out. There is a bug somewhere that delays the last command until another is issued.

That board from itead looks really interesting, and it's very cheap too! Could be useful for further prototyping - attaching debounced buttons/other devices. For something usable, with a coin cell, I think a separate design would be required anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
a bug somewhere that delays the last command until another is issued

Could You, please, be more specific on that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When testing the whole system, the last line of output sent to the screen isn't displayed in some situations

send_raw_byte (line, true); // doesn't display anything yet
nop_screen(); // now the previous command is displayed

I observed it at the end of main loop, so I don't know where the actual bug is. Perhaps "pcd8544.*" is correct.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cool,

I have done a couple of Bike computer projects but never had the inclination to write them up. The second version had Ant, gps and data loging it was xmega based. I have had a good 18 months service and 10000+ miles out of it but it's about to be retired.

Version 3 is software only being an android app targeting SonyEricsons new Active smartphone. With Ant support and a presure sensor I should be able to do most of what the old version did although I will lose the integrated front and back flashing lights. The issue is liable to be battery life but I want know how bad it is till the phone turns up and I can get my code off the emulator onto somthing real.

Ifor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow, sounds like you put a lot of features there. Since you're moving away from microcontrollers, would you care to share the code for your previous versions?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

70+ source files with no formal documentation would take some working through. No problem releasing most of it but the Ant+ stuff I had to sign a fairly restrictive NDA for so I don't think I can realse that. I would also need to check the licencing on all the third party bits of code I used which I am not realy inclined to go and look at. I know you can get the Ant+ information more easily now but I am sure you sill have to agrea to some form of licence.

No problem answering any questions on specific areas.

For this 2nd version I set up what I thought was a good framework. My main loop had an event hendeling system where I could register handelers for specific events. Most of the events came from various interrupt handelers although they could be inserted into the queue from other event handeling code. I had a 1024 Hz timer interrupt that I could register timer code to run on. So I checked the wheel and crank inputs at this rate befor moving to Ant. Button handelers had debounce code running at a lower rate.

This framework seamed to work very well I was able to add features and hardware to the project in an ongoing way and keep the working code code stable.

Ifor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This sounds more serious than I thought it would. I'm not even close to approaching 70 files.
I was rather looking for some code to merge in if the project moves in any of those areas, but I uderstand the pain with auditing the code.

The framework itself sounds similar to what I came up with - there is a well-defined event handling system mostly based on interrupts.
There are some differences, though: event registration is mostly compile-time, all debouncing is hardware and there's no polling for input involved. Instead, buttons/sensors are attached straight to the interrupts.

I think hardware debouncing makes the code much simpler at the cost of slightly more complex hardware.

Did your project have many users?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It was just for me. Documenting it enough for someone else to be able to make it would be way too much work. The motivation was that I had a feature you could not buy which was that it intergrated with my home made lights giving me automatic constantly variable light levels mostly based on speed. Very good for getting more runtime out os a small battery when out Mountain biking.