Logo - eForce Prague Formula

Join us!

Are you a student of university based in Czech Republic? Are you interested in new technologies and motorsport? Do you want to learn stuff beyond school curriculum?

Then don't hesitate and visit us at our workshop or write to

Data acquisition

1.5.2016 | author Stanislav Tomášek


This article will describe methods and devices used by our team in getting useful data from our vehicles. Data collection, transmission and its analysis is a crucial task in development of new vehicles. Without any deeper insight provided by a relevant data, our vehicle development efforts cannot fully draw from designs and innovations implemented in previous generations of vehicles, thus forcing us to ‘work in the dark’.

First steps

Our first working datalogger was based in the third generation of our vehicle. It was a WiFi module in one of the units. This first attempt proved, that remote datalogging was a plausible, yet challenging field.

Because of it's minimalistic setting – WiFi module without dedicated microcontroller and correct peripheral connection, it lacked both throughput and processing power to effectively transport larger amounts of data.


In order to process captured data, an application was written in Java language. It’s main features are extensibility by user-made plugins, ability to visualise and extract relevant data.

Plugin system gives users freedom to extend datalogger functionality in many ways. For example - graph drawing, data output formatting, message statistics, online vehicle parameters tweaking, etc.

Application’s strongly abstracted architecture gives it ability to connect to different target dataloggers via different interfaces (WiFi, USB, SD card, …) without any change in the base application code.

Separate unit

The second datalogger device created for the fourth generation of vehicle was an extension board of a unit. It was directly linked onto the vehicle's CAN bus and with separate microcontroller, newer WiFi module and optional SD card emplacement, it could both store data and transmit them remotely.

Unit's core was STMicroelectronics' ARM-based microcontroller with an advanced peripherals and substantial processing power. We also selected Ack.me's WiFi module as a suitable replacement for the previous one.

Due to the problems with WiFi signal reception, remote transfer wasn't possible during races. We had to resort to capturing data onto SD card and retrieving them after the event.

A new approach

Improving on the previous dataloggers, this year will bring a device with an entirely different philosophy, drawing inspiration from abstracted architecture of the application.

From a physical standpoint, it will be a unit of it’s own - box, connector, quite indistinguishable from other units in our vehicles. Three separate, yet precisely interconnected boards will lay inside said box.

Why 3 you ask? This design choice will allow us unprecedented level of modularity, extensibility, yet ease of manufacture and further development. We’ll describe each board’s role in the device.

The middle board’s (or base board) main purpose is to house the connector, transform voltage for circuitry, protect rest of the device from power transients and invalid connection, also to route signals between the boards.

Bottom board is an interchangeable board facilitating conversion of arbitrary signals from vehicles into discrete data packets sent into top board and vice versa.

Top board (or processing board) is also interchangeable. It’s primary function is to process discrete data packets from the bottom board. Storing them into non-volatile location, RF communication, etc. It can be also used to send data into vehicle remotely in order to alter it’s parameters.

From above description you can clearly see that middle board will be fixed for all dataloggers, bottom board will be exchanged for each target, top board when in need of different data processing method.

Future development

While latest device still being in development, our team had already suggested some areas of improvement to further dataloggers.

  • Improvement to application’s GUI
  • Refinement of power supply design
  • Ability to upload firmware from repository
  • Database linking


Article had described our datalogging efforts with emphasis on their progressive development. It also presented our newest datalogger for this year’s vehicle and possible future for datalogger development in our team.