Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Arduino Data Acquisition Module

Hi all,
I am looking at building myself a data acquisition module for use with race chrono using the following hardware:
Arduino (I have an Uno and a Mega, If I need the extra functionality I will go mega)
Adafruit ultimate GPS module
MPU6050
HC-05 Bluetooth module

I am looking sending across to race chrono :
GPS data
Engine RPM
Brake switch
Throttle Position
G force
and possible lean angle at a later date

Before I plough on, someone must have already done this before me, rather than reinvent the wheel can anyone point me in the direction of the code for a previously built logger?

Any help much appreciated, and when I am done I will happy to share my code and findings etc.

thanks

Ian

Comments

  • edited November 2018
    I would also be interested in a data logger like this. I have seen projects for G-force or RPM displays, so maybe you cold put them together.

    Many race cars, like vintage cars or cars without digital EFI, don't have OBD, so there is no RPM input for RaceChrono. Please keep us informed and build a lot of them if it works!
  • Depending on how much you spend on the Arduino project, you might first want to see what the RaceDAC can do. It can act as a direct interface from the engine or other sensor to RaceChrono. http://www.racedac.com/
  • @coxylaad - Could you just have a couple channels, like RPM and coolant temperature or just RPM? Would that simplify the module? I'm interested, but I have never used Arduino stuff.
  • As I have mentioned on other threads I am on V4 (?) of my 'track logger'. If you are going to do the blue tooth and the logging of data like RPM you will need more powerful than just a Arduino Uno, mini etc.

    V1 I started with a Arduino Mega doing just BT and GPS. Adding RPM I started to loose data. I am trying for a minimum of 25Hz GPS and 50Hz data

    V2 I moved to a Teensy 3.6 as it has on board SD card and still uses Arduino for programming so could use what I already knew. With this I added Accelerometer/Gyro, Brake on/off and throttle position sensor reading

    V3 I moved to a ESP 32 using FreeRTOS and moved from Arduino. This let me use the on-board BT module so less components. Thought I could move the GPS to WiFi so that I had more bandwidth for BT data since I was getting a bandwidth bottle neck pushing higher rates to the phone. This version I had code for 9 DOF sensor with lean angle calcs etc, TPS, RPM, Wheel speeds, brake on/off. Bunch of stuff. Though I only connected sensors for about 1/3 of it all. It worked pretty well.

    V4 I have moved to a Raspberry Pi as an experiment. Its this winter's project. I am going to expose the data to Race Chrono but also going to store it on the device in a Influx DB. Then run Grafana on it directly so that I can view graphs of the session from my tablet straight from the DB at the track. I have gyro/lean/accelerometer data at 100hz with 25hz GPS logged at the moment to the DB. Need to start to add additional sensors and see where things fall down. But I also upgraded my track bike so looking if I can get data straight from the ECU at a reasonable rate

    I may move back to a version of my ESP32 if my rPi testing doesn't go well. I have ot published any of my code or designs publicly, but might be willing to work collectively on something if we find the right common platform.

    TTYL, Jeff
  • @J_D_W would you recommend going to Raspberry Pi directly? I'm planning to build one too...
  • @aol I am in early days so I am still not sure if it's the right decision or not.

    If you want to use Arduino teensy 3.6 did me very well. I just didn't like having separate BT module but the built-in SD Card was good. Up to 25hz it did everything I wanted. If I wasn't also doing this to tinker in winter I would probably have stayed at this solution and designed a custom board to mount it all on vs the home made board I used.

    I like the RTOS aspect of ESP32 for controling whats going on in the solution the best so far. Though the ESP32 itself has limitations. For example it's ADC are pretty bad so I used an I2C based ADC for TPS and was going to add analog suspension sensors. I did all the code in 'C' using queues, tasks etc which I find much better vs Arduino.

    I feel my biggest limitation to logging lots of data is the BT. I started just wanting lap timing but then I started to lear from the extra data and want more sensors. For example I know why 2017 season ended in a crash, data shows I hit brakes though don't remember doing so in the corner.

    I am not getting rid of RaceChrono, I like it for the timing etc. But what I am currently playing with is sending GPS data over wifi as it's simple with GPSd on the Raspberry Pi. That gets me lap timing and quick look at speeds etc. Then I am currently thinking of putting data as fast as possible to Influx DB (currently around 100hz). Then once I get that data sorted I may add BT capabilities as well and see if I can still log some data in RC3 format to RaceChrono just for video overlay options. The data would only be at the same rate as the GPS which is enough for video. Also logging to a DB on Raspberry Pi lets me log more data than RC3 can handle, though I am technically not there yet. I think I had one field available with my ESP32 solution (though not all my sensors were in place on the last bike)

    logging at 100Hz the raw data seems to let me smooth out the noise and get closer to a real 50hz data set. Though I have only done 2 car trips of 20min each so far logging GPS & IMU data. I am currently working on an RPM/TPS/Gear emulator so that I can fake the inputs into the system while driving it around town in the car when I go somewhere.

    I guess I should find some time some night to try to setup a wiki or something somewhere to explain things a bit if there is interest in the community here.

    Jeff
  • aolaol
    edited November 2018
    @J_D_W if you're interested, next versions could provide better way to input DIY data than $RC3. Sounds like this is the bottleneck why you're browsing your data from your own databases. I'm not ready to discuss it publicly yet, but contact me through support form or email if you are interested.
  • Pardon me if I'm a bit late on this subject, but it came to me that an arduino rev counter would be nice. Has anyone developed one that works? My car doesn't have a digital tachometer signal, but it does have a 12V coil.
  • @DonC there are many ways...
    But if you have a 12V coil, you might reduce it to 5V and use it as an analog input for Arduino (https://forum.arduino.cc/index.php?topic=10219.0).
    Grab the tachometer-signal, measure the ignition, use an optical/magnetic measurement or whatever your car can give you out of its controlunit/diagnostic :)
  • Been away from my projects for a while due to work, life and being sick.

    I have done a full 360 on my logging device of choice. Back to using Arduino system with a Teensy 3.6 and a RN42 BT module. The ESP32 seemed to just be flakey and I couldn't ever know if it was my code or the ESP side of things. The Teensy boards a much better supported and seem to 'just work' once you get the details. By moving some things to DMA etc the CPU is not hit as hard as well. The BT bandwidth is still the bottleneck for more than 50Hz sensor logging but that sounds like it's being worked on for the next major release.

    @DonC, RPM is one of the things I am monitoring. I have not had it on the bike yet but from the test bench it seems to be able to handle up to 600Hz which is 18,000 RPM for wasted spark. The library I am using is https://github.com/PaulStoffregen/FreqMeasure on a Teensy MCU with a BT module currently using $RC3 output.

    Jeff
  • BTW feeding my Teensy running that FreqMeasure logic I covert from 12V or 5V signal to the 3.3V needed by the Teensy using one of these https://www.sparkfun.com/products/12009

    I know it works at 5V DC and I am 90% sure I tested it at 12V DC as well on the high side. And Also tested it passing through the signal for measurement

    Jeff
  • edited March 29
    TriB-
    Sorry, but the is only the ignition coil for a signal. I considered using a magnet, but it would not last long, and would fall off.
  • @DonC there are ways to capture that signal.

    First thought is what is firing your coil? Usually there is a 12V signal that triggers the coil to fire.

    Whats your car? Does it have EFI? Usually there is a crank position sensor for the ECU. It will have more than 1 pulse per rotation but there is a pattern which could be tracked to note the rotation speed.

    Then there are several circuits and howto items on the web to sense based on wrapping a wire around your spark plug lead.
    http://www.sportdevices.com/rpm_readings/index.htm
    http://forum.arduino.cc/index.php?topic=324145.0

    Are you just trying to get RPM into your RaceChrono data? You are probably looking at a bunch of work just to send RPM. Makes more sense to do the work if you have more things to log. Unless you already have a solution to reporting other data using $RC3 sentences?

    Jeff
  • @J_D_W I had try to build myself a data acquisition module with Arduino UNO, HC-06 Bluetooth, GPS with 10Hz refresh rate and MPU9250 module. Also in my case I found problem with fresh rate of data, but is normal because Arduino UNO isn't more fast. Now I have finish my project with a Arduino made by my self to reduce the dimension and GPS with Bluetooth connection to replace a GPS signal of my smartphone and used this in racechrono application. Anyway I want to restart my project with Teensy 3.6, I buied it and it's coming.
  • I have posted my current project on github. This version has not been tested on the motorcycle yet but might be useful for some as a starting point. I got my PCB this week and soldered it up which will make testing in the car and soon on the bike easier. I have had logging sessions using the proto-board version > an hour with test input of RPM etc so I have some faith that the current version kinda should work.

    I hope to update the wiki in the coming days with details on the current design (and how I got to this design). The code probably already needs a bit of a re-work as closer it is to track season the more I just add code without a thought for maintenance. And I never thought I would release it externally so readability and code consistency kinda sucks...

    https://github.com/j-e-f-f-williams/TrackDAQ

    Jeff
Sign In or Register to comment.