Data Acquisition

[crazycalvin]

As Sonny S. said, this might make a good topic to share information on home built systems, and store bought systems.  People could share and display there systems here.  If we can get some hits, could we make it a "sticky"?  So lets see/read about your DA set ups.  Thanks, Calvin.

[FLTRI]

The following represents some of the systems tailored to the motorsports industry so they are more apt to fir the bill as far as ones needs to aquire performance data and displayinf it in a simplistic format for analysis.

This is one of the systems I sold and serviced for racing vehicles. It is rather inexpensive (as compared to the others), easy to learn and use. I also sold the rights for Dynojet to sell it for their Dynos. Not sure if they still offer it as I believe they offer an upgrade to their Dyno stack that includes D/A.
http://competitiondata.com/
=====================

Here are a few others I am familiar with and have worked with over the years:
http://www.piresearch.com/P6/Pro+2+Wheel+Motorsport.aspx (Top of the line and VERY PRICEY)

http://www.aimsports.com/ (Competitviely priced)

http://www.racepak.com/ (Competitively priced)

http://www.digatronusa.com/products-motorcycles.shtml (Competitively priced)
=====================
http://www.veypor.com/veypor.html (No familiar with)

http://www.advantagemotorsports.com/ (Not familiar with)

http://www.corsa-inst.com/packages/motorcycle.html (Not familiar with)

[ederdelyi]

Copied/moved from "Show Your Timing Tables":

>>Ed,
What D/A system do you use?
Bob<<

Bob,
It's a "Heinz 57". Total homebrew cobbeled together from bits and pieces.
Normal data channels:
G -force(s)
Wheel speed
Engine RPM
CHT X 2
EGT x 2
AFR x 2 (NTK wide band)
AFR x 2 (narrow band)
MAP
TPS

4 additional analog inputs that can be used for other data.

A "redneck" engineering special, did it as a spare time/fun project a long time ago and have used it for many different applications. I wrote all the software for it as well.

>>What controller are you using for the widebands?<<

Homebrew/web DIY controller that was originally designed for the 2 cell NTK sensors used on the lean burn Honda Civics. It's been re-designed a couple of times since the first iteration.
Thinking about doing something else using some of the commercial controllers that are now readily available ... but I don't want one that uses the common "inexpensive" Bosch wideband sensor.

[ederdelyi]

Another source, hardware and software, sensors, etc. for those that are into "roll your own" but don't want to start from bare components. In DA, the software is just as, if not more, important as the hardware. Raw data is good, but tools to analyze and organize that data into something meaningful is priceless. And a lot of frickin' work, even for an experienced test engineer/programmer! Other than the satisfaction of doing it, had a lot of this stuff been available at the price points they are now when I did mine I likely would have just purchased a package and been done with it.

http://www.performancetrends.com/drag_racing_datamite.htm

More there, surf around the site and see what they got. No affiliation and I'm not pushing anything,

[hrdtail78]

I have had good luck with the Innovate stuff.  The LM-1 is what I have and use to use a lot.  Now they have the LM-2.  The new OT-2 is slick.  My only compliant is the length of the cables.  Made for cars so they are long.


http://www.innovatemotorsports.com/products.php

[ederdelyi]

I had/have one of the early Innovate LM-1's ... gotta admit I had a good bit of problems with it, and when it finally died the last time I just gave up on it. Some of their newer stuff looks promising and I have been looking at it for some other things I have in mind. In all fairness I have to say that Innovate was good about trying to address the issues I had ... luck 'o' the draw, I guess.

[crazycalvin]

Way back when, in another thread, I stated that I had made up my sniffer to go up my tailpipe.  I finally got off my duff and made up the basic electronics for it.  I wanted to use a LM3914 and a LED bar graph; couldn't find either locally and did not want to order on the WWW for $15 worth of electronic components.  I decided that I would use common op amps for LED drivers.  Tried using LM741 op amps and they did not act like they were supposed to.  So I changed over to CA3160 op amps and bingo baby!  I only have my electronics on a breadboard right now; I will probably put them on a PCB this weekend.  Maybe I will try posting some pictures next week.  Later, Calvin.

[nc-renegade]

In DA, the software is just as, if not more, important as the hardware.

You got that right.

I built many DA systems for power system analysis during transient conditions and several very rugged dataloggers for recording voltage and current on houses and substations applications.  I also built a cool negative sequence recorder used on several nuclear stations to record base negative sequence and track it during transients.  Also did a real-time cycle by cycle frequency meter to record a hydro station used for an emergency generator.  That was a cool project.

Several of these were very high speed systems, multichannel systems.  Designed and built the hardware using a T-Tech machine and wrote all the softward myself as well.  Most were embedded systems using the lowly 8051 microprocessor and several were A/D boards in computers with custom software.

Adapted one logger to measure DC parameters for an experimental electric car.  Also built several controls for electrical appartus, one I patent.  All of these were essentially DA systems.

That was back in the my days when this stuff was fun.

To make a long story short, the most useful part of these projects was the software.  When choosing an DA, finding the hardware is usually easy for the slow speeds needed for sensors in our application, but the real value is the software.

Bob, Ed and others, the links you supplied are good.  I have been toying with using a telemetric system to read the data from a motorcycle while at the track, but decided to go to a datalogger.  I will most likely roll my own, but would prefer to buy if I can find it.  I need a datalogger for the serial bus on the bike.  Need to log the AFR data from my cheap wideband sensors. LOL

[eddfive]

NC, I do not have a Dyno-jet dyno.  I have a Dynostar which came with a lot more data gathering equipment.  The standard unit came with (2) LC-1's for AFR that link into the Dynostar ADS software.  When I was trained in the method of tuning I learned the old fashioned way of looking at the overall data, TPS/RPM/AFR, making corrections and tuning.  Once I got going I decided there had to be a faster way to collect the data and automate the calculation.  I have adopted the Daytona Twin Tec Twin Scan II and the WEGO.  I put my sensors in the OEM sensor holes or on the older bikes I designed a SS sensor holder with a copper tube.  The key part for the copper tube is the vacuum source used with the tube.  I have a pretty high dollar pump which pulls constant vacuum across the sensors and have seen very little to no delta in AFR with the pump and tube compared with the sensor in the header pipe.  The other key part to all this is a friend of mine is an Excel Spreadsheet guru, he was there for the training and went off and wrote spreadsheets so I can now just cut and paste the data out of Twin Scan and the tuning software,  the calculation of VE adjustment is done, and paste back into the tuning software.  It does not matter which tuning software package is used, just have to be careful to make sure rows and columns line up exactly.

Since I do not have a Dyno-Jet he also did some Powercommander spreadsheets so I can now set the AFR target during the tune, PC's are now a snap using the same theory.  I always believe that too much data is better than not enough.  I guess I have always believed "in god we trust all others bring data".  The Twin Scan will also give you most of the data streams to look at all the engine parameters.  Just my $.02 worth

[nc-renegade]

I guess I have always believed "in god we trust all others bring data". 

That is my moto here at work as well.  We build protective relays and many other products for the utility and industrial market.   Design and Manufacture all here in the USA.  Out products are what protects our electrical grid....they must be reliable.  Our founder has always stated your moto...so we are very data driven.

Your right, I've used the Twin Scan II in used it in the past and should give me the AFR's that I'm looking for.  Will dig it up, I think that might be the answer to logging the serial stream.

[Steve Cole]

Just make sure the data that is recorded really goes with the external data being pulled in. This can be a big issue since the factory data bus will only allow for a very small amount of data to be transferred (4 items per read). The factory buss will run between 6 - 10 frames of data per second at best. As more data packages are requested the data becomes inaccurate due to buss speed.

[crazycalvin]

Just make sure the data that is recorded really goes with the external data being pulled in. This can be a big issue since the factory data bus will only allow for a very small amount of data to be transferred (4 items per read). The factory buss will run between 6 - 10 frames of data per second at best. As more data packages are requested the data becomes inaccurate due to buss speed.

Does this happen with the SERT, SEST, and the TTS as well?  It seems like the data could be skewed with these devices also; or is the data all being buffered by the ECM and then sent to these devices?  Thanks, Calvin.

[Steve Cole]

The data is not buffered in the ECM really. I can only speak for TTS based software and for us that is why we keep the amount of data being asked for limited. If you look at the information we get in the Dyno Data form you will see it is very small so that we can properly do the calculations need with data that is needed. Other Data forms are also limited in size to keep out of the problem, but if you ask for too much it does begin to skew the alignment of the data. The buss speed is the issue and you just have to not push it too far. You always want the smallest amount of data you can get away with to keep the speed up on a HD. To sync the external data it is best to record an external data item that is the same as the buss data for alignment.

[crazycalvin]

I have never done a data recording with anything but SEST.  I know TTS was the manufacturer of the original SERT and makes the MasterTune device.  I assume that when you put the original SERT or MasterTune into data record mode, it records things like timing for both cylinders, knock retard for both cylinders, specified AFR, vehicle speed, engine RPM, etc.  That alone is more than four parameters.  So I guess that is why I was wondering whether or not we are missing data with these devices or is the ECM able to buffer a certain amount of data.  I guess we could miss some the data and it would not make any difference.

[ToBeFrank]

The other key part to all this is a friend of mine is an Excel Spreadsheet guru, he was there for the training and went off and wrote spreadsheets so I can now just cut and paste the data out of Twin Scan and the tuning software,  the calculation of VE adjustment is done, and paste back into the tuning software.  It does not matter which tuning software package is used, just have to be careful to make sure rows and columns line up exactly.

Ed, does this mean you're not using the TwinScan algorithm for generating the new VEs? I found it lacking, which is why I also developed my own. I've since adapted it to also work with narrowbands with the SERT and/or SEST and packaged it up in an easy to use GUI. I'll be releasing it very soon.

[ToBeFrank]

I have been toying with using a telemetric system to read the data from a motorcycle while at the track, but decided to go to a datalogger.  I will most likely roll my own, but would prefer to buy if I can find it.  I need a datalogger for the serial bus on the bike.  Need to log the AFR data from my cheap wideband sensors.

NC, I've got this in the works. The TSII will work for this, but in my opinion it is very limited. You can only log a small predefined set of the data and no faster than 5 frames per second. I can get 30+ frames per second for a VERY limited set of data, but 10-15 frames per second would be more likely for a useful set of data. Widebands aren't integrated into the logging system yet, but that's the next step. The hardware I'm using already supports ADC.

[ToBeFrank]

So I guess that is why I was wondering whether or not we are missing data with these devices or is the ECM able to buffer a certain amount of data.  I guess we could miss some the data and it would not make any difference.

Not to speak for Steve, but I believe that is the point he was making. There is no buffering going on. One piece of your data may be from the same combustion cycle as another piece of data, or they may be 10 or more combustion cycles apart. It all depends on how fast you are logging and what you are logging.

[eddfive]

I do not use the Daytona Twin Scan algorithms.  That is the reason I had the spreadsheets developed as I use the Twin Scan for live data collection only.  I feel more confident if I am in control of the calculations.  Not that the Twin Scan values for VE are off I just found some variance.  With my spreadsheet method I can have AFR's dialed in for front and rear cylinders in (2) tune runs.  Takes a total time counting dyno time to collect and reflash about 30-40 minutes.  Depending on what I hear while I am tuning AFR's I may do some timing runs in between so that the final AFR tune run is with the actual final ignition values.  I have found that every single bike is different for timing optimization so I spend the majority of the time getting the ignition tables adjusted for peak performance and no spark knock. 

[ToBeFrank]

With my spreadsheet method I can have AFR's dialed in for front and rear cylinders in (2) tune runs.  Takes a total time counting dyno time to collect and reflash about 30-40 minutes.

That was my experience as well when street tuning. Did a couple 10 minute data logging sessions and from that I had my VE table pretty much covered.

[FLTRI]

With my spreadsheet method I can have AFR's dialed in for front and rear cylinders in (2) tune runs.  Takes a total time counting dyno time to collect and reflash about 30-40 minutes.

Ed,
Heck, I can spend more time than that just normalizing temperatures after restart and baseline power pulls over a complete 2 cylinder tuning session. 
Bob

[Steve Cole]

The data the ECM sends out comes in the form of a packet. A packet is 6 bytes + the header, you have no choice. If you want data that is not in that packet you have to request another packet. So every packet comes at a different time and is read at a different time. So the question becomes how many are you going to allow before you have too much time between them. A frame of data is made up from many packets and the system can be told to send the packet in slow, medium or fast speed. You have to request and receive the packets so you use time up doing what is called the overhead. The ECM reads and sends the packets one at a time so there is time delay in every packet from one to the next. In Fast speed this is about one packet every 25 ms.

[nc-renegade]

I have been toying with using a telemetric system to read the data from a motorcycle while at the track, but decided to go to a datalogger.  I will most likely roll my own, but would prefer to buy if I can find it.  I need a datalogger for the serial bus on the bike.  Need to log the AFR data from my cheap wideband sensors.

NC, I've got this in the works. The TSII will work for this, but in my opinion it is very limited. You can only log a small predefined set of the data and no faster than 5 frames per second. I can get 30+ frames per second for a VERY limited set of data, but 10-15 frames per second would be more likely for a useful set of data. Widebands aren't integrated into the logging system yet, but that's the next step. The hardware I'm using already supports ADC.

Sounds cool!  Since we are running a T-Max on the supercharged bike that I want to monitor, I decided to run a small laptop with smartlink in logging mode to capture the data needed.  I do not like the logging feature of the smartlink software and would prefer to read the raw timestamped or time aligned data into a spreadsheet so I can view it the way that makes sense to me.  I have not taken the time to look at rolling my own logging software for the T-Max, might have too.  Trying to get something going quickly cause the May run at Maxtor is coming up fast!

[ToBeFrank]

I do not like the logging feature of the smartlink software and would prefer to read the raw timestamped or time aligned data into a spreadsheet so I can view it the way that makes sense to me.  I have not taken the time to look at rolling my own logging software for the T-Max, might have too.  Trying to get something going quickly cause the May run at Maxtor is coming up fast!

When I ran the tmax I hated their logging. You couldn't even graph the data! Makes it about impossible to really see how the tune is. I started looking into reading their raw data and was making good progress, but since I sold the tmax I didn't finish it. You'll have to reverse engineer their log file format so getting something going quickly is unlikely.

[nc-renegade]

When I ran the tmax I hated their logging. You couldn't even graph the data! Makes it about impossible to really see how the tune is. I started looking into reading their raw data and was making good progress, but since I sold the tmax I didn't finish it. You'll have to reverse engineer their log file format so getting something going quickly is unlikely.

I started to do that several years ago, but stopped.  I talked with engineers over at Thunderheart and they acted like it was a tough thing to do.  Never understood why they did not have an export feature for their log files.

For this superblown bike, the Alpha-N system is the way to go, so we are married to the T-Max on this application.

Thanks!