WARNING: Geeky Stuff ahead!
Over the winter, I have been diligently working on a new part for the Talon. It’s probably fair to say that I’ve been spending way too much time working on it, but it’s starting to come together now, so I’ll tell you about it.
Last year, I spent a lot of time looking at professional data acquisition systems for the Talon, but ultimately made the decision to make my own drag race data acquisition box. Now, If you don’t know me, you might think I’m a little crazy to do something like that, since it’s not really normal for people to decide to do such things. But, if you know me, you know I’m crazy enough to actually just go and do something stupid like that :D
I literally looked at dozens of systems, and while most of them would be somewhat adaptable to what I want to do with them, many of them are kind of sub-par. Edelbrock has a system that logs has software for “Windows 95/98/NT” – it’s 2011 for crying out loud! There are a systems containing 5Hz GPS units – something completely useless for a nine second drag car. One professional “modular” system I found has a 12.2Hz sample rate (12.2 times per second) and they claim that they are adequate because they log twice as fast as your foot can move. All of these systems cost more than $500, but many of them aren’t even as adequate as the $65 in parts I used on my first datalogger I told you about earlier. There are some systems that are very capable and very cool – and very spendy. At the end of the day, all they do is sample data, save it somewhere, and let you look at it later – it’s the details that you really need to compare. I want a capable system, but I just don’t race enough to justify $2500 for a data logger. Would I take one if given to me? Hell yes I would. Can I justify buying one? Well, no, apparently I can’t.
And so began my original logger (pictured above.) It was a decent system, but much of it was through-hole construction and it was all designed to interface with my laptop, which was going to be in the car at all times. Throughout the past few years racing, I’ve had a harder and harder time keeping a laptop in the car. Between 1.3X 60’s, along with the ridiculous heat in-car, I just don’t like subjecting any laptop to those extreme circumstances any more. I actually had three or four situations where my laptop just locked up from heat – I don’t exactly blame it. If you’ve been inside a tin can in 95 degree heat at a track in the summer, you know what I mean :-)
Anyway, last year I started designing a new board and spent a lot of time trying to determine what I wanted to do. I am familiar with Atmel microcontrollers, but haven’t spent very much time on embedded applications so I wasn’t sure exactly what processor I wanted to use. I spent time evaluating some .NET micro controllers and didn’t like the lack of speed that the managed code offered, so I looked at using c code running on ARM processors. Thinking that would be quite a learning curve, I decided to stick with Atmel processors, but use their big bad awesome new ATXMEGA processor. So, that’s what my new logger is based on.
The main processor on the logger is an Atmel ATXMega192A3 running at 32MHz using an external sixteen channel 12-bit Ti ADS7953 ADC to acquire analog data. On the Analog side, I’ve setup four 0-12V channels, with the other twelve channels being 0-5V analog channels. I can measure a ton of stuff with this – Battery voltage, fuel pump voltage, accelerometer data, suspension sensor data, data from TPS sensors, AIT sensors, CTS sensors, and a bunch of other stuff if I’m so inclined…
I also have a bunch of digital signals – six input that measure on or off on a 12V level. This allows me to measure other things I don’t need the analog signals for, like my Line lock or my trans brake. Additionally, I also have four tachometer inputs so that I can measure Engine RPM, driveshaft RPM or whatever else I want to measure. These are controlled by a second ATXMega processor, which is probably complete overkill for the application, but still less expensive than analog options available for measuring this sort of thing.
Aside from the Analog and Digital acquisition options, I also have another add-on to the board that allows me to log six Thermocouple channels, along with CAN information from the Haltech. Of course, I will have to write software for the datalogger to do that, so I will probably have to do some hacking to make that work, but that’s down the road a little bit anyway.
All of this will be accessible through a microSD card that is integrated into the datalogger – this means I won’t have to have my laptop in the car in order to capture all this data – it will go straight into a format that my laptop can read. I will be able to pop the card out of the datalogger, put it in my laptop and open up the file immediately. So, the end result is that I should have a bunch of data from each pass that I will be able to look at and tweak the car to meet my needs.
My first logger would log at 150 samples per second. Even with more channels, the new logger should be able to log more than 200Hz without a problem. This will help me a lot. I’m just waiting on the prototype boards to come back from the fab house. Once that happens, I will start soldering it all up, and then write code for it.
Dude. That’s hard core.
Here I am all excited about finally going speed density with DSMap/Jackal and you’re freaking *designing* your own logger.
Not bad Sir.
I wanna check this thing out one of these days. hopefully before norwalk. :)