Sběr dat


This article discusses the methods and equipment used by our team to obtain useful data from formulas. Data collection, transmission and analysis is a critical point in the development of new monoposts. Without much knowledge of "what's really going on under the hood" in vehicle operation, we can't capitalize on our designs and innovations implemented in previous generations of our monoposts. The device that can overcome these challenges is generally called a "data logger".

First steps

Our first functional datalogger was placed in the third generation of the formula (FSE.03). This was the first attempt at wirelessly obtaining data from the vehicle in our team. This practical experiment proved that data transfer from / to the "on the fly" formula is possible.

Due to its minimalist concept, as a WiFi module without a dedicated microcontroller and an adequate connection to the existing data infrastructure of the vehicle, this datalogger could not be used to transmit larger volumes of data.

Client application

The Java application was created to efficiently process the acquired data. Its main strengths are: extensibility with user-created plugins, ability to process and plot relevant data.

The plug-in system gives users the freedom to extend the functionality of the application in many ways. For example - graphing, data formatting, statistics of received messages, tuning parameters while the vehicle is running…

The heavily abstracted architecture of the application gives it the ability to connect to various target data loggers through various interfaces (WiFi, USB, SD card, ...) without the need for any change in the main program code.

Independent unit

The second datalogger was created directly for the fourth generation of our formula (FSE.04x) as an extension module of the "ECU Front" unit. This unit was directly connected to the CAN bus and had its own microcontroller, a newer WiFi module and an SD card slot. This gave her the ability to both send data to a remotely connected device and store data internally.

The core of the unit was the STMicroelectronics ARM microcontroller with advanced peripherals and high computing power. With the new unit, we also chose the new WiFi module from

Due to problems with the WiFi signal reception, we were unable to start data transfer during the race. We had to resort to writing data to the SD card and later retrieving it.

New approach

Datalogger for this year will bring equipment with a whole new philosophy. The main inspiration for the design was the strong abstraction used in the client application.

From a physical point of view, it will be a completely separate unit, totally unrecognizable from others in our vehicle. Three separate but precisely interconnected boards will drive this unit. This design allows us to see an unprecedented degree of modularity, expandability with fast production and further development. Now we describe the role of each board in this datalogger.

The role of the middle board (also the motherboard) is to hold the main connector, connect the adjacent boards, manage the power supply, and protect the device as a whole against transient phenomena and improper connection.

The bottom plate is interchangeable, handling the transfer of arbitrary signals from vehicles to discrete data packets that are sent (and received) to the top plate.

The top plate (or processor board) is also replaceable. Its primary function is to process discrete packets from the bottom plate. Storing these packets in non-volatile storage, data transfer, etc. This board can also be used to set vehicle parameters "in flight".

From this description, it can be clearly seen that the middle plate will be invariant for any datalogger, the bottom plate will be changed for each data collection target, the top plate will be changed when an alternate processing of the recorded data is required.

Further development of

Although the latest datalogger is still in development, our team has already designed several areas to improve the functionality of other dataloggers.

  • Application user interface
  • Power section
  • Ability to upload firmware from repository
  • Linking to a database


The article described our data collection experiments with an emphasis on the progressive development of our techniques and approach. He also introduced our latest datalogger for use in the latest vehicle and a possible future for datalogger development in our team.