Long abstract for Velo-city 2007 2007-04-21

Here is long version text of the abstract for Velo-city 2007 which I submitted last September about the project. This text will be included in the delegate pack given out during the conference.

The CycleRecorder Project

Project details as of the middle of April 2007.


The CycleRecorder Project [1] is an open source hardware and software project started by myself Robert Fitzsimons. The main goal of the project is to develop a modular and portable platform suitable for use with a bicycle, which can be used to record various aspects of a cyclists journey.

The basic system will consist of a number of electronic sensor modules which will be linked together to a central processing unit which will record the various inputs. The recorded information can then be played back and analysed at a later time using the open source application software.

The system can be used to monitor road surface conditions, cyclist movement through traffic, and how a cyclist reacts to changes in conditions or traffic. The system would be of interest to road traffic engineers and those interested in how road surface or traffic effects a cyclist.

The project is still in development and writeup a somewhat technical overview of the projects design and some of the issues or decision that have been made so far.

For more updated information about the project please visit the project website at http://cyclerecorder.org/ .

[1] The CycleRecorder Project

Similar projects.

I've collected some links to a few similar or related projects, products and studies which give examples of how a CycleRecorder system could be used or developed:

Smooth Ride

Bicycle overtaking studies

The MAXQ Microcontroller in Action: Designing a Bicycle Computer with the MAXQ2000

Bikini! The bicycle computer for your Palm Pilot!

Murata Boy

iBike Pro power meter

What is open source?

The term open source is used to describe the principles of a development model in which a product is designed and produced in a open manner, and released in a way which allows others to freely copy, modify and release those modifications.

Open source projects promote active collaboration between the developers and the users. This collaboration helps to form a strong and focused self supporting community around the core of the project.

Open source is generally linked with the creation of software [2] [3] but the same principles can equally be applied to the creation of hardware. Though the end product is almost never provided free of charge due to the costs of manufacturing the hardware, the design materials which allow for modifications to be made are available, sometimes with a time delay or non-commercial restrictions.

I have yet to decide on the exact licenses I will use on this project, but the GPLv3 [4] license is defiantly an option once it's release later this year.

[2] The Open Source Definition
[3] The Free Software Definition
[4] GNU General Public License Version 3

Hardware design.

Even though I've been working on this project for a while now, it is still at a very early stage of development. Almost all the hardware is still at the component selection or proof-of-concept stage.

The hardware is being designed to allow for a high level of modularity and flexibility. This modularity will allow the end user the possibility to pick and choose component modules depending on the actual requirements for their required project.


The main component in the system is the CPU computer, this coordinates all activities with the modules. The CPU is also responsible for time syncing and the recording of all the data generated by the modules to a suitable data storage device.

The CPU is not a standard computer, it's requirements include the need to be much smaller and lighter, use very little power and it must be able to withstand the relativity harsh operating environment of a bicycle. These requirements can be satisfied by a number of different embedded microprocessor architectures.

My current preferred microprocessor architecture for the CPU is the ARM9 [5], this architecture is able to provide a very powerful, cost effective and widely supported implementation platform for the project. The main benefits of the ARM9 architecture is it's multi vendor support and excellent support for the open source Linux operating system.

At this stage of the project I'm using a development board [6] to help with the prototyping of the CPU. I envision the need to develop a custom CPU board, which will overcome some of the current development board shortcomings including size, interface options and cost.

The Modules

The hardware design for the modules will be much more varied. This is due to the different requirements for the sensors and transducers, and the amount of data they will be expected to generate.

The general design for each module will be similar. A micro-controller will be used to interface directly with the sensors and collect data, the micro-controller will then condition the data into a standardise format and feed that data back to the CPU for storage.

For my module prototyping I'm using a small ARM7 [7] development board [8], this type of board allows for easy testing and integration of sample circuits without having to design and produce suitable printed circuit boards.


It is possible design and build modules which interface with many different types of sensors and transducers, some of these sensor can be used to measure or record:

  • Audio and video.
  • Location, altitude and direction.
  • Proximity to nearby objects.
  • Heart rate, breathing rate and force monitors.
  • Tilt, vibration, shock and speed sensors.
  • Environmental sensors, air quality, wind speed, air pressure, humidity.
  • Amount of braking, gear usage, steering, cadence.

The interface between the CPU and Modules

I'm interested in using a standardised interface cable between the CPU and various modules, this cable should be able to carrier the required signals, at a reasonably fast speed and provide power to the modules.

There are a number of existing cabling standards which are capable of carrying the required signals, such as a standard serial (RS-232) cable and Controller Area Network (CAN) automotive cabling. But I think the most suitable solution for this project is to use cabling which implements the standard Universal Serial Bus (USB) [9] protocol.

The USB protocol can operates at three different maximum speeds depending on the supported version of the protocol and configuration, and the ability to provide power to the module is included in the standard.

Another benefit of using the USB protocol is the possibility of being able to use existing USB devices with the CPU. The main drawback is the extra complexity of the software to support the USB protocol.

The interface between the CPU and host machine

Once a journey has been recorded and the cyclist has return to base, the journey needs to be download from the CPU for processing and archiving.

When the bicycle returns to base the CPU will be placed in a docked state and an Ethernet or USB cable can be used to connect and download to a networked data storage device or computer hard disk.

At the same time the batteries powering the system can been charged by using a suitable mains power adapter.

Possible extra features

It would be useful to have a small and basic user interface similar to a bicycle computer, this interface could display basic information and allow for basic control of the system.

Another option would be to add a GSM modem or wireless transmitter which would allow the system to be remotely monitored or controlled.

[5] ARM9 Processor Family
[6] Embest SBC2410-III
[7] ARM7 Processor Family
[8] Analog Devices ADuC7020 Minikit
[9] Universal Serial Bus

Software design.

The high level software design is fairly simple with three main modes of operation, these modes are recording, docked and playback.

In the recording mode the modules are activity collecting and processing sensor data and making it available as a data source to the CPU. The software running on the CPU uses an internal clock source to associate synchronising timestamps with the data source, this combined data is then recorder to a journey file on the data storage device.

In the docked mode the modules will be disabled, the software running on the CPU is then able to make suitable journey files available for download to the base computer. The host software running on the base computer will query the CPU for journey files and be able to download and delete them from the data storage device. The host software will also be able to configure or upgrade the software running on the CPU and modules.

The host software will enter the playback mode when no CPU is docked. It has a graphical user interface which can be easily used to find and playback the journey files. The playback displays all the different data sources synchronised together allowing the user to correlate and understand why abrupt changes have occurred.

The modules will run very low level software which is known as firmware. This firmware interacts with the hardware directly and is usually written in programming languages like C [10] and Assembler.

The CPU will run programs written in C on top of the Linux [11] operating system. The Linux operating system provides high level access to a computer resources allowing easier development of complex programmes. If low level hardware interaction is required by the CPU a suitable Linux kernel [12] device driver will be need to be written in C.

The host computer application will be written in the Java [13] programing language. Java allows very complex applications to be written which can incorporate graphical user interfaces, network interaction and many more features, in an extremely portable package.

[10] ISO C
[11] Linux
[12] Linux Kernel
[13] The Java Platform


Progress on the project has been slower then I hoped, but this is partly to do with my lack of experience in electronic hardware design. The other factor is that I'm the sole developer and user of the project, so if I get suck or distracted progress stops.

I have learnt many new concepts and greatly improved my understand of embedded software development and electronic design, through experimentation [14] and reading books [15]. I also believe that I'm still at the beginning of what it is possible for me to learn and achieve with this project.

Looking forward to the future I hope to be able to present a more visible result of the time spent on this project with some sample hardware and software at the Velo-city conference in Munich.

Another issue is to promote the project to try and attract more developers and potential users.

The final long term goal would be to develop this project to a point where hardware could be sold for use by others in there own research.

[14] CycleRecorder Blog
[15] CycleRecorder reading material

About the author.

My name is Robert Fitzsimons I'm from Dublin, Ireland. I am an avid commuting cyclist for about six years and an active member of the Dublin Cycling Campaign [16].

I first started using computers in the practical sense about 15 years ago in secondary school and I have been hooked ever since. In more recent years I have had a great interest in learning more about electronics and embedded development.

The CycleRecorder Project combines all of these interests in a way that benefits my involvement and understanding of all these interests.

I can be contact by email at robfitz at 273k dot net.

[16] Dublin Cycling Campaign