TestLogger Collector

Datalogging device for designed RC car racing

Public Chat
Similar projects worth following
Working as a Data Engineer in professional motorsports gave me a thought that why the data isn't logged in RC cars, which has been my hobby for last 20 years.

We are also developing new dampers for RC cars with my friend and we discussed that we need data to do the development properly. So the outcome was a datalogging project for RC cars without any coding experience in embedded world or HW design experience. Let's see if we succeed with the project and get the data logged properly.


Target is to create a datalogging device for RC car racing and learn electronics at the same time. Main reason for this project to get started was the fact there is no datalogging device for RC cars. Hopefully some day this device is so good that it could be actually made as a commercial product.

Current prototype logs with 2ms and it can log transmitter signals (like steering, throttle), wheel speed with hall-effect sensors, temperature, battery voltage, damper movements, laptimes, GPS (not very good), 3-axis accelerometer, 3-axis gyro.


First prototypes were being built on top of Python board 1.1  and I just made shields on top of that board with necessary connectors etc. This combination is a little bit too big for RC car racing but it's good enough prototyping things. 

Second phase was to design a completely own board. I have already found out that I need to make different version for different types of cars. For example it's difficult to fit full scale device from 1/8th scale car to 1/12th scale car which has limited space and actually it doesn't need that many channels. Currently there is two versions called Base with limited amount of channels and Full with all possible channels.

To get laptimes I made a IR beacon with 555 IC and it sends IR signal with 38kHz and receiver is connected to the datalogging device. First version is working with normal AAA batteries, but the target is to create device which has internal LiPo-battery and it can be charged with USB cable.

HW is not only about the electronics and PCB. The system also needs brackets for sensors so the measurement quality can be ensured. For the moment these have been designed with tinkercad and 3D printed. My friend promised to help on this topic and I'll try to write a project update from this topic.


Firmware is based on ChibiOS and current version of the firmware is based on this project but it's heavily modified from that with trial and error method :) 

Completely new firmware is under work as now the requirements are known, so it makes sense to build something from scratch. Also my experience and knowledge with C is a bit better. Still a new firmware from scratch is a massive job.


Current FW logs the data in CSV format so it can be used for example in excel, but I have also created a tool to convert CSV file to Motec i2 format. Unfortunately that is not a long term solution as it's violating Motec license agreement and it's not possible to share with anyone. One of the tools I'm using at work is Motec i2 Pro and I really like to UI of that tool. Additionally it's very capable tool do the analysing. Check their website for more info

In the longterm I want to have a configuration tool with UI which does the data file conversion, calibration/configuration of the logging device and is connected to TestLogger to input the data.

  • What the data shows?

    Jussi Luopajärvi01/28/2019 at 14:19 0 comments

    It's been a while since last post and things have progressed a fair bit on HW side like Collector Full V2.2 and completely new IR beacon, but that's not the topic for today. Finally I'm posting about something else than HW development and it's about the collected data.

    I've been using the Full V2.1 with my 2WD buggy (It's Team Associated B6.1D, see and I've logged the channels as follows.

    • Steering
    • Throttle/Brake
    • RPM/speed from motor sensor port
    • Wheel speed from both rear axle outdrives
    • Battery voltage from two cells
    • G forces on three axis
    • Angular velocity with gyro
    • Damper movement on rear corners
    • Laptimes

    Of course this amount of channels gives you a massive possibilities to analyze both car and driver, but here few simple examples to start with where you need only steering, throttle, speed and vertical acceleration.

    Read more »

  • Remember the f*ing review

    Jussi Luopajärvi01/12/2019 at 07:22 0 comments

    I designed the V2 for Full version in a bit of rush and guess what, it was a massive failure. The boards were working nicely, but microSD slot was placed 180 degrees in a wrong direction (slot was facing against USB connector...), analog 3V3 was not connected to upper board due to an issue in schema plus few other minor issues. 


    One positive learning from this episode was the possibility to move SD card slot outside the device. Usually the logger needs to be installed on very tight place, so sometimes it's actually good to have an option that you can bring the SD card slot to more accessible location.

  • Firmware architecture depression?

    Jussi Luopajärvi01/01/2019 at 10:55 0 comments

    First of all Happy New Year everyone!

    Last couple of weeks I've been starting to do a spec for the firmware as the hardware starts to be good enough that I can live with the limitation. The firmware design just feels overwhelming task and even difficult to decide where to start. I've never done a spec for embedded SW and last time I've been doing UML charts was probably around 10 to 15 years ago. I already know quite technical challenges I need to resolve, but before I go that far I need to find a how present the firmware on paper. I bought this book to get some guidance

    Next step is to learn some good practices what to follow when doing design decisions which is also a challenge as my experience in programming is quite limited. Especially with C.

    Last big step is to actually actually resolve the technical challenges and writing the code. For example how to get each channel to log data on correct logging rate. How handle the buffer. In which format the data should be written because data is coming to buffer on different rates.

    Do you have any suggestions how to start designing FW architecture based on RTOS? If you have good articles to read and learn, please share. This is probably going to be a long project and just need to take the needed time to do it one step at a time and avoid doing shortcuts.

    Read more »

  • Failed full version

    Jussi Luopajärvi12/17/2018 at 21:35 0 comments

    A bit of brake from updating as I have had some work and holiday trips. After the first version made completely by myself which had fairly limited amount of inputs, I decided to go for the full version with my own design. 

    Base guideline for the design was same inputs as I had for PYB shield with much smaller area covered. Usually the height isn't a problem but area used is a big issue. I decided to to with 2 PCBs stacked and connected to together with three board-to-board connectors.

    The goals were achieved with a big but. It was almost half of the size compared to PYB shield version and it had the same connectors. Also the weight was surprisingly low as you can see from the picture below. It was almost 10 grams lighter than PYB shield version. The problem was related to connecting the two PCBs together and using the device on car which jumps and get's massive hits. The boards were not sticking together and then everything fails. 

    Read more »

  • First version without Python board

    Jussi Luopajärvi10/20/2018 at 15:50 0 comments

    A time for another update as I received the first PCBs for a basic logger version which is completely own design and doesn't need a python board as a base. My friend drives a 1/12th pan car which really small and there is no extra space available, so python board shield version is a no go. I thought that maybe that is a good place to design completely own version of the logger. My friend gave a space constraint for the device that it shouldn't be bigger than Sanwa rx-451 receiver. I got quite close to that requirement maybe small fine tuning gets me to that target. Currently the board size is 33x22mm, so it's no too bad. Functionality is pretty limited though..

    The board can log steering, throttle, laptrigger, speed/rpm from motor sensor port, g-forces and gyro values. This is good enough for me to verify the base design for the board and for 1/12th pan car that information already gives enough input to analyze and basic behaviour of the car.

    I don't have any data yet to look, but the reduced size makes the installation so much easier. Also the weight is over 10 grams lighter compared to the last Pyb shield and Python board combo. 

    Read more »

  • PYB shield V2

    Jussi Luopajärvi10/08/2018 at 13:48 3 comments

    In the previous post I mentioned about new prototype and it arrived as planned during last week. I called this as Python board shield V2. As a summary main changes were as follows.

    • Move from through hole components to surface mount components
    • Move from 0.1" header connectors to JST-SH connectors
    • Take RPM and temperature information from motor sensor port
    • Changed the shield from bottom side of PYboard to top side and solder it to PYboard.

    So basically everything was new. 

    Build went pretty smooth even it was one my first times soldering SMT components. My loyal Weller WTCP 51 with 0.4mm tip did the work nicely :) As a result I got a prototype which was 4 grams lighter and few milli meters lower. Pictures shows a bit more

    Read more »

  • Yet another shield for Python board

    Jussi Luopajärvi10/03/2018 at 11:46 0 comments

    This week I should receive a new shield PCB for the collector. I think this shield is already 5th or 6th version, so there has been quite many iterations. This one is a bigger change as this is the first version with surface mount components and sensor connectors are changed from 0,254" header pins to JST SH connectors. There is two reasons why I wanted to change the connectors. First one is surface mounting and smaller size. Second reason is probably the bigger one. With JST connector you can make sure that the connector is always plugged in the correct way.

    Hopefully this helps me to reduce the height and weight of the package. It's still not going to be what is my target but at least one step closer. Also hoping that I get to test this one during the next weekend. I will definitely post some pictures if that happens.

    The next step will be a version without Python board, so get everything on one board... 

View all 7 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates