MagiLog: Open Automotive Datalogging

Developing a full featured datalogger on the cheap

Similar projects worth following
In motorsports there is no such thing as too much data. With data, drivers can review their inputs to improve consistency and lap times. Unfortunately, for a quality motorsport oriented datalogger you are looking at spending thousands of dollars. I think I can do it cheaper.

I started researching how to make a high functionality automotive DAQ about 5 years ago but never got around to building it. What came from that was the idea for the MAGIc LOGger. I'm hoping to go over my old work, refresh some components, and get a working device out in 2018.

The MagiLog will have analog/digital I/O for interfacing with automotive sensors, built in GPS, IMU, Bluetooth and SDCard support. Not only will it interface directly with sensors, it will be able to read data from the ECU via CAN, OBD and serial. It will be based around a Spartan-3 FPGA for the I/O and the communications/logging will managed by the XMEGA A1U microcontroller.

Currently targeted features:

16 12Bit Analog In / 2 5V Analog out

12 Digital In / 6 Digital out (3@5V, 3@12V)


9 axis IMU

OBD compatibility

ECU serial compatibility
SD card support

Interaction and data streaming over USB and Bluetooth

Currently specced components can be found below, these will likely be changing to account for EOL/Updated/New parts.


Spice for digital sim

asc - 1.69 kB - 04/03/2018 at 21:56



Spice for Analog Sim

raw - 18.51 MB - 03/31/2018 at 16:25



Spice for Analog Sim

asc - 3.17 kB - 03/31/2018 at 16:25


  • 1 × Spartan 3AN Starter Kit Main I/O backbone
  • 1 × XMEGA A1U Xplained Pro Communication and high level tasks
  • 1 × Microchip RN42 Bluetooth Module
  • 1 × Microchip MPU9250 9 Axis IMU
  • 2 × TI ADC128S022 ADC's

View all 7 components

  • RN42 (Bluetooth)

    Nigel04/11/2018 at 07:18 0 comments

    Getting the RN42 up and running was surprisingly simple. Just hooked up a serial adapter and I was able to pair the device with my computer without trouble. From there we just open up two serial terminals to verify that the communication is working. There was one odd quirk with how the Bluetooth COM port worked. While the datasheet said to use the “outgoing” labelled COM port I was only able to get the device to communicate using the “incoming” port. Once everything was set up I was free to send as much gibberish between serial terminals as I wanted.

    There are some newer options from Microchip that have support to up to Bluetooth 4.2, but I'm not sure if I'll need that much throughput. I'll try to push the RN42 as far as I can and upgrade if I need to down the road.

    I’m almost finished with all the peripherals now. I just have the OBD/CAN system left but I need to wait on a few components to get in before I can get the test bench all set up. I’ll start filling in the details on what I’m going to do with the XMega and the FPGA while I wait. It looks like I’ll be getting down to coding by this time next week.

  • GPS Part 2 - Success!

    Nigel04/10/2018 at 06:43 0 comments

    I’m still not sure what the issue was but everything seems to be working now. I’m able to send configuration messages and have them change parameters. Now that the problem is behind me I can start digging into the workings of the module.

    For use in MagiLog there are a few settings that we’ll need to set. We need to set the update rate to 20Hz, align the messages to UTC seconds, and increase the baud rate. App note AN0003 covers the binary format used to communicate with the Venus modules.

    This is the overall structure of the message, it’s fairly straightforward and won’t be too difficult to work with. One thing to note is that each message needs a checksum number generated to be sent with the message. Since there’s only a small number of messages I’ll ever need to send it will be faster for me to just extract the messages with my Logic and export the values from the software.

    Once I had everything configured how I wanted I set up the antenna and let it sit for a few hours. Here are the results I got.

    As you can see the overall spread is sizeable. That said, the calculated accuracy is actually better than what is advertised, 1.77m vs 2.5m. This was in less than ideal conditions, so I’m impressed. By combining the GPS data with the accelerometer data, I think I can get that error down even more.

    The last feature that’s worth covering is the 1 pulse-per-second (1PPS) output. It’s accurate to around 20ns and will be stable throughout a wide temperature range. I’m looking into using it as a reference for the other trigger clocks to keep all the data aligned. From what I can tell it should work and will make a lot of timing issues much simpler.

  • Venus638 (GPS) Part 1

    Nigel04/08/2018 at 19:35 0 comments

    Another vital sensor for MagiLog is GPS. With GPS we'll be able to get references for position and velocity/heading. Additionally it offers two timing features that I might find useful. GPS logs have an accurate timestamp and most GPS modules have a 1PPS output that can be extremely accurate. The GPS module I had originally chosen was the Skytraq Venus638, as it offered the highest refresh rate I could reasonably find and it also had very good reviews. It has a 20Hz update rate and 2.5m accuracy. It communicates over UART and uses structured payloads for data transfer. It has since been replaced by the Venus838 which offers 50Hz update rates. I'll move to that sensor once I start building boards but for now the 638 will suffice. The 638 uses the NMEA 0183 standard and has a few different standard data formats. The main one we're interested in is the RMC message.

    Another message I'm thinking of using is the VTG message. The reason I'm considering it is that it gives us speed in km/h in addition to knots, that means we should be able to get a 1.85:1 improvement on ground speed resolution.

    During the dev phase another message that will be useful is the GSA message which will provide us the GPS DOP, with this data we can test different antennas and start to collect data on accuracy in various conditions.

    I first started trying to interface with the sensor using my Bus Pirate, and while I was able to get it to stream data to terminal, I was having difficulty writing to the device to change parameters. I then tried to interface to the GPS over a COM port using the manufacturer supplied application.

    Using this connection method everything was working fine. I needed to dig in a bit more to figure out what could be going on. To do this I used my Saleae (Original) Logic. Connecting it in parallel to the Bus Pirate and Pololu adapter I was able to compare the two to start trying to debug what's going on.

    Here's the log for the working Pololu communication:

    And here's the Bus Pirate message:

    As you can see, the timings are very similar (within a normal margin I'm pretty sure), and on the lower right hand side you can see that the first message sent, which was the change refresh rate command, was the same in each case. So right now I'm a little stumped, I'll keep probing around and post an update with more details and the solution to my woes once I've solved the riddle.

  • MPU-6050+Gyro (9-axis IMU)

    Nigel04/06/2018 at 21:33 0 comments

    One of the most important data types I'll be logging is inertial measurements of the car. As our logging rate will be higher than the GPS update rate we need to use IMU data not only for its own purposes but to interpolate between GPS updates. There are a few options for how to merge the two, but I'll likely go with a Kalman Filter.

    The IMU unit I originally specced was the MPU-6050, in particular the official eval board with an included AKM compass for 9 axis data. In retrospect I should have selected the MPU-6000 at the time as it has an  SPI interface that is both easier to use than I2C and does not require me to make an additional protocol hardware block for the FPGA. In the time since I purchased that board Invensense (Now owned by TDK) has come out with an upgraded version called the MPU-9250. The 9250 removes the need for an external compass and comes with an SPI interface. Sparkfun makes  a breakout board that's around a quarter the cost of the official dev board so I'll likely end up picking one of those up.

    In the meantime I'll use what I have to get familiar with the register system and the general I/O workflow of using this line of sensors.

    The tool I'll be using to interface with most peripherals during this initial dev phase will be the Bus Pirate, which you can think of as a kind of multitool for serial based communication. To hook up the eval board to the bus pirate we make the following connections: (You'll want to be careful that you use the right hookup guide for your Bus Pirate version. Use "v" to confirm)

    MPU VCC -> BP 5V

    MPU 2x Gnd -> BP Gnd

    MPU LDO_en -> BP 5V



    MPU FSYNC -> BP Gnd

    MPU Int_i -> BP Gnd

    BP 3.3V -> BP Vpu

    Before diving in completely I recommend you familiarize yourself with the communication protocol. It's explained in the MPU-60X0 datasheet.

    Once you have everything all connected fire up your preferred terminal program and connect to the bus pirate over a COM port. From here first enter m to open the protocol list and then 4 to select I2C. Once you finish up with the options turn on the power supplies and the pull up resistors to finish configuring the Bus Pirate for I2C. Run the I2C scanner macro "(1)" to make sure that we are picking up that the device is connected to the bus.

    From here check to see if we can read a static register like the "Who Am I" register. Once we have confirmed the connection we check the sleep status to see it has powered up in sleep mode, followed by confirming that data out registers are still empty.

    We then write to the power management register to turn off sleep and verify that our settings have taken. Once that's done we can read any of the data registers to get the most recent data from that set.

    I'll need to keep playing around with this and start to think of the easiest way in hardware to combine two 8-bit frames into one 16-bit number. Both SPI and I2C use 8 bit numbers so we'll need to read from two adjacent registers to get the entire number. I also need to figure out the specifics of the data fusion and where that actual computation will be taking place.

  • Janky, but functional

    Nigel04/04/2018 at 05:05 0 comments

    I finished up the analog and digital simulator perf boards this evening. Finally, everything seems to be working.

    Once again there's a few discrepancies from Spice to reality. At the slowest setting we aren't quite getting down to 30 Hz.

    On the fastest setting we're getting about a 50% higher frequency than expected but it looks like absolute garbage. Turning it down to ~6KHz gives us a workable waveform.

    There's another weird bug that I'm not sure about. I can only bring down the output voltage to ~6V. The signal gets very degraded (Duty cycle drops and a bunch of noise appears), and below that value the 555 fails to oscillate at all. I'm not sure what the root cause of this is as the amplitude adjustment shouldn't affect the input voltage into the threshold capacitor. If anyone knows what's going on please give me a hint on how to fix this.

    EDIT: Fixed! Turns out I wasn't paying enough attention and reversed a couple leads on the voltage divider. I now get the full range of 0-12V for Vmax.

  • Hello World

    Nigel04/03/2018 at 23:02 0 comments

    Over the last couple days I've started getting into and learning ASF for Atmel Studio. ASF is a software framework that kind of sits between something like Arduino and raw C. The documentation is pretty good so I'm making decent progress. I started coding on the XMega and got clocks, RTC and GPIO up  and running. Made a short program to cycle between two blinking speeds when a button is held down.

    Next up is to get familiar with how ASF handles interrupts and to figure out how to use the event controller to schedule tasks. If anyone knows some good resources other than the ASF docs please let me know!

  • Digital In

    Nigel04/03/2018 at 04:24 0 comments

    Originally I had planned on having 10 total digital inputs but after doing some more research I think a better configuration will be 12 total inputs with 2 dedicated to tachometer inputs; I'll explain what I mean later in this log. The reason for moving to 12 total is that it fits well with using 2 non-inverting hex buffers as the buffer for the digital in. This will let us accept 5-15V inputs without worrying about blowing anything. As the name suggests, each buffer has 6 inputs and outputs. Unfortunately I only have inverting hex buffers but luckily as our simulator will have a 50% duty cycle we can invert the signal coming in without worry. That said though, for the final MagiLog PCB I'll want to spec out proper non-inverting buffers.

    As I learned doing #Honda OBD1 Digital Tachometer some cars have really janky tach signals. Because of this I don't want to commit to trying to accommodate them all in a single circuit. To get around this, the tach inputs will have 3 total pins each. One is the expected data in pin, but we will also include a power and ground line. This lets us put a filter inline with the cable to convert non-square-wave signals to a square-wave we can read easily.

    For the simulator we want to be able to simulate a wide range of frequencies with an adjustable Vmax. To do this I've chosen to use a modified version of the 555 timer circuit used to simulate the analog sensor inputs. Note the additional pot and changed threshold capacitor value, and the addition of the recommended decoupling caps.

    Using this configuration we have full control over the voltage output and we have a usable frequency of around 30Hz-6kHz. Here are the spice outputs.



    Next steps for me will be to get the perf board circuit done and make sure it functions how we expect.

  • Analog In Part 4: Perf Board Problems

    Nigel03/31/2018 at 16:24 0 comments

    I'm almost done with the perf board prototype but I've run into a few issues along the way. I'll get to those after I go over the progress so far.

    It can't remember the last time I've done a perf board so I was a bit lost at the start. I ended up deciding to take a picture of a few different board sizes and then I used OneNote to annotate components, wires and bridges on top. Here's what I ended up with.

    To solder it I started with the ICs, then I did the passives, then the wires and finally the bridges. Going into things I thought that this approach would give me good access to do all the solders. I was wrong, oh so wrong. Towards the end of the board things got really dicey trying to get to all the pads. I think I ended up either forgetting to do a few of the solders or one of my bridges isn't connecting properly. When I powered the board up, my power supply showed 0 current draw but the outputs were all just noise around 0V. So I'm pretty sure there isn't a major short or else I'd expect there to be some current draw or a puff of magic smoke. I'll need to check it out with a multimeter to try to diagnose what's wrong.

    This is the last update for now on the Analog inputs. I'll keep working on fixing the board and for my next log I'll go over the digital inputs of MagiLog.

    Here's a picture of my first piece of hardware of HaD Prize 2018:

    EDIT: Figured out what I think the issue was on the high voltage output. The 555 I'm using is the LM555 which requires 4.5V to drive, this wasn't replicated by SPICE. What i need to do is swap it out for a lower voltage 555 like the LMC555.

  • Analog In Part 3

    Nigel03/31/2018 at 16:22 0 comments

      A couple of days ago I was asked the question of "Why not just get all your data over OBD?" and thinking about it I was able to think of a few reasons why I'm happy with my approach.

      1. Getting a functional prototype will be much easier. Once I have something up and running my progress will accelerate, so this is a good incentive to stick with the way things are.
      2. Direct sensing will give me  a lower latency and potentially higher bandwidth, this will come in handy once I start trying to get as fast of a refresh rate as possible.
      3. Not every car uses the same OBD standard, and many race cars do not have an OBD compatible ECU at all. Additionally, doing direct sensing will allow MagiLog to be used in non-automotive applications.

       All of that said, I'm not discounting OBD altogether, MagiLog will still be capable of it, but direct sensing will be heavily encouraged as the primary data source.  

      For the simulator side of the project, I'm aiming to create a modular system to allow me to mix and match  which functions I can test at once. One of the modules will contain the power management and from there supply all the other modules with 12V and 5V. I ended up sketching a rough idea of what I want it to look like:

      The side headers will allow me to daisy chain modules and all of the outputs will be towards the front of the boards.  

      As I mentioned last update, the first module I'm making is the analog input simulator. This module will have 2 outputs, a noise 12-14V output replicating a dirty automotive power rail and a 0-5V oscillating output to represent a sensor output. 

      Both circuits are based off of 555 timers. For the HV circuit we set VCC to +14.4V and set the 555's ground to the 12V rail, this will allow us to get that high speed oscillation between the voltages we are looking for. I selected the resistors to give me a roughly 66% duty cycle.

      For the 5V circuit we leave the discharge pin floating and then power the threshold capacitor with our output. This will give us an exactly 50% duty cycle with the ability to tune the frequency with a potentiometer. I popped a big smoothing
      capacitor on the output so that we get some values to read that aren't just 5V and 0V.

      Now that you've seen the circuits, let's go over the outputs starting with the simulated 14V output.

      This is pretty much what we want with a frequency of around 500Hz. That said, I'm thinking of increasing the frequency up to somewhere between 2-5KHz and throwing on a smoothing cap to narrow up the voltage range. Though… I should probably just get a scope measurement from someone's car to make sure this output isn't literal trash.

      Thankfully I'm more satisfied with the LV oscillator. Here's the graphs simulating inputs at the low and high frequency bounds.



      So finaaaally we to building some actual hardware. As is tradition, we start off with a breadboarded version to test out.

      Here's what it outputs. 


      It’s close, but if you look carefully you'll see the frequency is somewhere greater than 33MHZ (I'm pretty sure this was my scope telling me it's unhappy), after a few cap taps we were free of this issue and all was well. 

      Here's the 5V output on the slow setting:

      There's some difference in the waveform shapes, but the voltage range and frequency are nearly bang on. Hooray! 

      For the fast setting here's the result:

      Once again things look pretty good! Though one weird thing I noticed was at the fastest setting we were only getting around 7Hz, we'd expect to get up to ~30Hz. Not a huge deal and hopefully it goes away once  things are in a more robust PCB.  

      This is getting a bit long, so I'll split it up and finish up Analog in one more log.

  • Analog In Part 2

    Nigel03/26/2018 at 21:47 0 comments

    The actual hardware needed to create our input stage and the input simulator is fairly simple. We need to buffer/scale, read, and then extract the values coming from our sensor. Since it seems that we only need 1 ADC input with the ability to read 15V we can group 15 of the inputs into one type of circuit, and the
    "high" voltage line into another. As most of the sensors the MagiLog will interface with operate at 5V it makes sense for us to set Vref at 5V as well. This means on the 15V input we need to scale that voltage down to fit in a 5V range. We can do this with a simple op amp circuit. Additionally, we need to buffer
    our inputs. This will make our device much better at handling nonnominal input voltages. It also has the bonus of providing a high-impedance sink to whatever sensor we are trying to read. This prevents the ADC reading process from affecting the sensor output. To achieve this goal we will use two variations of
    the following circuit.

    In this circuit the gain of our output is equal to (1+R2/R1)*(R4/(R3+R4)). Depending on what we need to do we can modify values or remove components. We don't need any gain values larger than 1, so this means that we can make the op-amp portion just a voltage follower. To do this we open R1 and short R2, leaving us just with R3 and R4. In the 5V measurement circuit we short R3 and open R4 meaning we don't need any resistors to read 5V signals. For the HV signals we need to scale 15V to 5V and we accomplish this by making R3=2*R4. One thing to note is since I'll probably end up using the 5V rail to power the op-amps I'll need to make sure I use rail-to-rail op-amps. This means that they will be able to output all the way from V- to V+ (Gnd and 5V).  

    To do the actual reading of the sensor voltage we use an ADC. The one I originally specced out was a TI ADC128S022. It's a standard 5V, 12Bit ADC with 8 input channels. As a quick sanity check we can compare our sample rate to the specifications. With 8 inputs running at 100Hz that gives us a  total sample rate of only 800Hz, in other words we have roughly 100x headroom on sampling. This gives us a lot of flexibility to do things like oversample to increase our resolution from 12Bit to 14Bit. Once the data is obtained, it is clocked out with 4-wire SPI. I'll get into the details of this more once I start working on the HDL to interface with the ADC.  

    To simulate our car conditions I'll like 2 types of outputs. One output will be ~12V with some noise injected to simulate a dirty car power rail. I'm not too sure how I'm going to do this yet so I'll do a part 3 once I get more research in and an idea down on LTspice. The other output will be a oscillating circuit with a Vmax of 0V-5V and a Vmin of 0V. I'll need to find out what sort of time scales I should be simulating so I'll work on that and get it into part 3 as well.  

    BTW I found that ISO standard I mentioned in the previous log. It's ISO 7637-2.

View all 14 project logs

Enjoy this project?



Nelson Phillips wrote 04/04/2018 at 13:08 point

Hey, interesting project. See you might be using air pressure sensor for it. Been playing around with some for prototyping and have a project about then if you interested.

  Are you sure? yes | no

Nigel wrote 04/04/2018 at 21:36 point

Thanks for the like. Looking forward to see what you discover.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

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