Data Acquisition System [Archive]

jlangholzj

12-14-2012, 08:53 AM

Originally posted by nkikas:
Hi everyone, we are currently searching for a data acquisition system and I would really like to hear your opinion on the matter. I am in between the following:
-Motec ACL or ADL3
-Race-technology DL2 & Dash4 PRO
-2D (not sure which one yet)
-Aim (not sure which one yet)

Could anyone recommend something different?
Which ones do your teams use?

We also have a Motec M800 ECU.
Looking forward to hearing from you guys! http://fsae.com/groupee_common/emoticons/icon_smile.gif

Nick Kikas
Electronics-Data Acquisition
Aristotle Racing Team

If you've already got an M800 I'm assuming that you've got experience with the i2 software that motec uses. Hands down one of the best software packages for data analysis. That being said, its also one of the more expensive options.

An equally impressive package is the AIM evo4 (this is what we use). Its got an option for USB storage as well as expansion hubs. The expansion hubs even have specialized options for thermocouples and other sensors. The software isn't quite as powerful as i2 but it'll do everything you want it to just as well. I've had a lot of good luck with the evo4 and its a bit more on the budget side. We payed ~$1400 for it to get into data logging and acquisition. Good bang for the buck if you're on a tight budget.

I've never worked with either of the other options but when we came to the conclusion the motec and the aim units are both great.

Shebert

12-14-2012, 10:51 AM

The Motec 1 Mbit CAN is sometimes an issue with non-Motec product.

If you want the "pro-loging" and more data capacity, you will find out that the ACL is not really more expensive than the ADL when you add up all the extras.

Plus, Ethernet download is a nice to have when you do long runs.

I didn't worked with the others, but the ACL is a good bang for the bucks... if you have the bucks.

BillCobb

12-14-2012, 12:22 PM

Matlab Instrument Control Toolbox

Write you own flavor A/D activity and post-process the data in an appropriate manner(s). 'Hire' a Team member assigned to get this task done. Then you will have a taste of how professional organizations work.

You could even use Excel to do this job. Yes, it takes some skill. Avoid the 'Hi guys, you will tell me how to do data inquisition' begging.

Then run some procedural tests. Compare variations in performance. Validate your designs. Consume some beverages when you are proud of your work.

Owen Thomas

12-14-2012, 01:08 PM

Originally posted by BillCobb:
Then run some procedural tests. Compare variations in performance. Validate your designs. Consume some beverages when you are proud of your work.
+10^9. 10/10 would recommend. Excellent advice for junior engineers.

js10coastr

12-14-2012, 06:01 PM

Cardriverx

12-14-2012, 06:33 PM

First off there is no reason for a ACL (Advanced Central Logger), it is a $10,000+ unit that has no inputs itself, you need to buy SVIMs and everything runs on CAN. Its what the NASCAR teams use... I mean if you have the money go for it but if not..

ADL3 is a great unit... but unnecessary for all but the most demanding stuff. If you really need to run SVIMs with strain gauges then you need a ADL3. If you have tons of inputs, then maybe you need an ADL3.

I would recommend what we are using for this year, an SDL3. Should have enough inputs with it plus the M800 (could always add a Texense A-CAN for more inputs), and with pro logging you can do just as much stuff with it as a ADL3 (minus the SVIMs).

I have used Race-Technology (had to deal with it last year... the software is.. well annoying), dabbled in AIM, and some Racepak (plus a little Mclaren but that is $$$ stuff with hard to use interfaces). The i2 software is just so much better than everyone else's (in my experience). Plus the SDL3 and M800 would work flawless over CAN.

An SDL3 with 16MB logging and Pro analysis runs about just under 6,000 for a reference.

murpia

12-15-2012, 09:26 AM

First of all, think carefully about what you are trying to achieve with data acquisition. Budget very carefully, especially for the sensors and wiring harnesses. In most setups, unless you grossly overspec your logger, the sensors and harnesses will cost more. Decide if you want idiot-proof plug and play, or if you are prepared to do some engineering. The former saves time and costs big money. The latter cannot be done overnight, but can deliver excellent results for much less money.

Originally posted by Cardriverx:
I have used Race-Technology (had to deal with it last year... the software is.. well annoying), dabbled in AIM, and some Racepak (plus a little Mclaren but that is $$$ stuff with hard to use interfaces). The i2 software is just so much better than everyone else's (in my experience). Plus the SDL3 and M800 would work flawless over CAN.

If I had to spec an FSAE logger setup, I'd seriously consider the latest Race-Technology DL1 Mk3 hardware. But, I'd throw away their software and use GEMS GDA Pro, which is on a par with MoTeC i2 and costs about £200 per dongle last time I checked. It accepts 'csv' files which the DL1 software should be able to export semi-automatically.

Google "dl1 mk3", "gems gda" & "ConvertRunToTxt" to find this stuff fast.

GEMS also supply loggers, but I'm not exactly certain about their current range. I've used their older analogue / CAN cardlogger, but it's no longer listed on their site. What they sell now are CAN loggers. These could easily be used with a bunch of Technological Arts NanoCore12MAX modules as distributed acquistion modules for Canadian$47 each. You'd have to add a few resistors etc. to protect the inputs, and write a little firmware, but you'd have the equivalent of a MoTeC SVIM setup at a much lower cost.

Google "tech arts nanocore12maxc32st" to find this device.

None of the above is plug and play, but if you are prepared to take on the engineering, you'll be able to do much more with a small budget.

Regards, Ian

Cardriverx

12-15-2012, 01:38 PM

That's what we used, the DL1 MK3. I have never tried the GEMS software, but if it is that good and you could directly read the files from the DL1 then it could be worth it.

Another thing to note is the set up software is sub-par for the DL1 too, zeroing sensors like steering and dampers is really a pain (especially because they integrated the CAN hi and low pins on the serial connector and you need to use serial if you want to see data live on the computer). Furthermore, I am really not a fan of the quick bare wire connector it uses.

It really just depends on how much money you have and how much time you have to work on just setting it up. And truthfully, you can have the best setup out there but if you have no one that actually knows (or is willing to learn) what to do with the data and analyze it then spend your money elseware.

Originally posted by murpia:
First of all, think carefully about what you are trying to achieve with data acquisition. Budget very carefully, especially for the sensors and wiring harnesses. In most setups, unless you grossly overspec your logger, the sensors and harnesses will cost more. Decide if you want idiot-proof plug and play, or if you are prepared to do some engineering. The former saves time and costs big money. The latter cannot be done overnight, but can deliver excellent results for much less money.

<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by Cardriverx:
I have used Race-Technology (had to deal with it last year... the software is.. well annoying), dabbled in AIM, and some Racepak (plus a little Mclaren but that is $$$ stuff with hard to use interfaces). The i2 software is just so much better than everyone else's (in my experience). Plus the SDL3 and M800 would work flawless over CAN.

If I had to spec an FSAE logger setup, I'd seriously consider the latest Race-Technology DL1 Mk3 hardware. But, I'd throw away their software and use GEMS GDA Pro, which is on a par with MoTeC i2 and costs about £200 per dongle last time I checked. It accepts 'csv' files which the DL1 software should be able to export semi-automatically.

Google "dl1 mk3", "gems gda" & "ConvertRunToTxt" to find this stuff fast.

GEMS also supply loggers, but I'm not exactly certain about their current range. I've used their older analogue / CAN cardlogger, but it's no longer listed on their site. What they sell now are CAN loggers. These could easily be used with a bunch of Technological Arts NanoCore12MAX modules as distributed acquistion modules for Canadian$47 each. You'd have to add a few resistors etc. to protect the inputs, and write a little firmware, but you'd have the equivalent of a MoTeC SVIM setup at a much lower cost.

Google "tech arts nanocore12maxc32st" to find this device.

None of the above is plug and play, but if you are prepared to take on the engineering, you'll be able to do much more with a small budget.

Regards, Ian </div></BLOCKQUOTE>

Rex Chan

12-16-2012, 05:17 AM

We used to run RT DL1,and we're currently using ADL3.

The RT Analysis software is ok if you know how it works, but learning curve is a bit higher than i2, and it just doesn't work as well in the end. The big difference for me is that MoTeC require you to input the calibration/transfer function in the device config before you can log, and then logs actual values. DL1 pretty much logs voltages, which means you have to know what was connected to which pin for every data file.

this works if you have a very organsied data logging management system, but I'm betting that most teams don't, and in 5 years, no-one will know what the data means. Anyone can pull an old MoTeC file and still have usable data.

In short, the main reason to pay the big bucks for MoTeC is that the software/ecosystem is setup to be easy to use/idiot proof. Use it if you want/need data to make your drivers faster. IMO, FSAE is very much a driving competition, and use of daq is a must if you want to go fast.

Something I noticed about the Monash drivers - they ALL take a serious interest in their own driving data, and use it to go faster/improve. IMO, that's why they win - they have grasped what the "problem" is, and use their resources to find the most effective/efficient solution, which is good engineering.

murpia

12-16-2012, 11:41 AM

Originally posted by Cardriverx:
That's what we used, the DL1 MK3. I have never tried the GEMS software, but if it is that good and you could directly read the files from the DL1 then it could be worth it.
You have to us 'csv' format as the intermediary.

I.e. Export from DL1 to csv, import from csv to GEMS. I don't know exactly how much extra work that is on the DL1 side, on the GEMS GDA side that's one extra mouse click only.

The major disadvantage of csv is the lack of variable rate data, i.e. all channels have to be exported / imported at the same rate. So, not a perfect solution, but one that offers good value for money.

For csv import you have to use the 'Pro' version of GEMS GDA, which is dongle protected. That version also offers a powerful maths engine, which is pretty much indispensable for serious data work.

Regards, Ian

Cardriverx

12-16-2012, 04:46 PM

If I remember right the Race-Technology software will only export the CSV file at 50hz, it would render shock position, raw accelerometer, etc data pretty moot.

Originally posted by murpia:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by Cardriverx:
That's what we used, the DL1 MK3. I have never tried the GEMS software, but if it is that good and you could directly read the files from the DL1 then it could be worth it.
You have to us 'csv' format as the intermediary.

I.e. Export from DL1 to csv, import from csv to GEMS. I don't know exactly how much extra work that is on the DL1 side, on the GEMS GDA side that's one extra mouse click only.

The major disadvantage of csv is the lack of variable rate data, i.e. all channels have to be exported / imported at the same rate. So, not a perfect solution, but one that offers good value for money.

For csv import you have to use the 'Pro' version of GEMS GDA, which is dongle protected. That version also offers a powerful maths engine, which is pretty much indispensable for serious data work.

Regards, Ian </div></BLOCKQUOTE>

Nicky

12-17-2012, 12:14 AM

IMHO, I think that instead of setting up a whole data acquisition unit paralleled to the Motec M800, it would be better to buy an off the shelf CAN logger and read off the Motec CAN stream. Else if you don't have the bucks for it, get a junior to make a CAN logger. You can tie a big SD card to it and voila you have GBs of space for datalogging with fast download too!

The motec custom dataset setup makes it easier to log the data that you are looking for. A little coding with Matlab and a shabby looking GUI is good enough to view and analyze the data.

murpia

12-17-2012, 07:32 AM

Originally posted by Cardriverx:
If I remember right the Race-Technology software will only export the CSV file at 50hz, it would render shock position, raw accelerometer, etc data pretty moot.
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by murpia:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by Cardriverx:
That's what we used, the DL1 MK3. I have never tried the GEMS software, but if it is that good and you could directly read the files from the DL1 then it could be worth it.
You have to us 'csv' format as the intermediary.

I.e. Export from DL1 to csv, import from csv to GEMS. I don't know exactly how much extra work that is on the DL1 side, on the GEMS GDA side that's one extra mouse click only.

The major disadvantage of csv is the lack of variable rate data, i.e. all channels have to be exported / imported at the same rate. So, not a perfect solution, but one that offers good value for money.

For csv import you have to use the 'Pro' version of GEMS GDA, which is dongle protected. That version also offers a powerful maths engine, which is pretty much indispensable for serious data work.

Regards, Ian </div></BLOCKQUOTE> </div></BLOCKQUOTE>
I thought it worth a check. Both the DL1 Mk3 setup application and the 'Run To Text' converter indicate 100Hz maximum.

I disagree that 50Hz is no use for damper & accelerometer data, and certainly I think 100Hz is fine. But don't take my word for it, do the necessary analysis:

Start with a true assessment of the capability of the data hardware (any make). In particular, sample some pure analogue sine waves of different frequencies. Characterise the hardware, especially the anti-aliasing characteristics. Design & implement hardware analogue filters between your sensors and the hardware if necessary, so you are getting a true digital representation of your signal. For 100Hz sampled data, you should be able to measure ~20Hz sprung mass movements (accels, loads & displacements) with confidence.

20Hz is enough to distiguish all the classic vehicle dynamics modes cleanly enough, in my opinion.

(If you want to have some fun at a salesman's expense, start asking them about the anti-alias filtering in their data acquisition hardware, and how that relates to the specified logging frequency in their setup software. Either they are filtering out the high freq. analogue so the low freq. sampling is valid according to Nyquist, they are screwing the low freq. sampling so they can claim the high freq. sampling, or they are implementing a digital filter plus downsampling to generate the low freq. sampling. If the latter, check they are correctly anti-aliasing the high freq. sampling anyway, many aren't).

Regards, Ian

exFSAE

12-17-2012, 07:47 AM

Originally posted by js10coastr:
The MoTeC is by far the most powerful and easieet to use... it'll also give you a leg up in terms of using a system that pro teams use.

I liked i2 for its ease of use. As for "what pro teams use" I'd consider that Pi and Mclaren have a pretty huge market share in some pro series.

Not that it particularly matters... learn one and the others are pretty easy to pick up.

In all reality while personally I'd go MoTeC in FSAE, it is worth considering doing your own MATLAB data viewer maybe in parallel. Once you get knee deep in car data analysis you may find that i2, Toolbox, and ATLAS aren't really all that powerful by themselves. Great for casual, quick analysis though.

murpia

12-18-2012, 06:10 AM

Hey, 2 threads!

http://fsae.com/eve/forums?a=t...20097151#93720097151 (http://fsae.com/eve/forums?a=tpc&s=763607348&f=125607348&m=29220097151&r=93720097151#93720097151)

Originally posted by exFSAE:
[QUOTE]Originally posted by js10coastr:
In all reality while personally I'd go MoTeC in FSAE, it is worth considering doing your own MATLAB data viewer maybe in parallel. Once you get knee deep in car data analysis you may find that i2, Toolbox, and ATLAS aren't really all that powerful by themselves. Great for casual, quick analysis though.
We have done kind of the opposite. Not for FSAE, but we have a MATLAB vehicle performance simulation for hybrids. Originally it output MATLAB graphs according to a complex set of scripts that took quote a few man-hours to develop. But, in the end we got too frustrated with the inability to display distinctly different data ranges on the same MATLAB plot. E.g. you want a graph with engine rpm from 0->8000rpm, alongside speed from 0->50m/s.

Now we export the data from MATLAB and load it into the GEMS GDA Pro mentioned above. Much easier to view a single dataset, infinitely easier to compare 2 or more datasets side by side as overlays.

The power of i2 Pro, ATLAS, Pi Toolbox, WinTax and GEMS GDA Pro lies in the user math channel features. Some are easier to deal with than others, but user maths channels in some form are pretty indispensable. ATLAS & WinTax offer an 'ActiveX' interface for true custom control. I think i2 and Toolbox may have this, but I did not try it out when using them.

Regards, Ian

jlangholzj

12-18-2012, 07:20 AM

Originally posted by murpia:
Hey, 2 threads!

http://fsae.com/eve/forums?a=t...20097151#93720097151 (http://fsae.com/eve/forums?a=tpc&s=763607348&f=125607348&m=29220097151&r=93720097151#93720097151)

<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by exFSAE:
[QUOTE]Originally posted by js10coastr:
In all reality while personally I'd go MoTeC in FSAE, it is worth considering doing your own MATLAB data viewer maybe in parallel. Once you get knee deep in car data analysis you may find that i2, Toolbox, and ATLAS aren't really all that powerful by themselves. Great for casual, quick analysis though.
We have done kind of the opposite. Not for FSAE, but we have a MATLAB vehicle performance simulation for hybrids. Originally it output MATLAB graphs according to a complex set of scripts that took quote a few man-hours to develop. But, in the end we got too frustrated with the inability to display distinctly different data ranges on the same MATLAB plot. E.g. you want a graph with engine rpm from 0->8000rpm, alongside speed from 0->50m/s.
</div></BLOCKQUOTE>

this should be pretty easily done with a plotyy command or if you're looking for 3 or more, making your own script like a plot4y or plotNy to accomplish it for you.

back on topic now.....

BillCobb

12-18-2012, 07:45 PM

Your graphing requirements are very easy if you drop the notion of 'graphing' and make use of the 'Object Oriented' figure paradigm. I recommend using GUIDE to construct gui's to do this. The Matlab User Groups library probably already has a few examples of how to do this. A full time Matlab programmer as a Team member makes a lot of sense.

That's my two dimes worth. (Pair a dimes, eh?)

murpia

12-19-2012, 03:27 AM

Originally posted by BillCobb:
Your graphing requirements are very easy if you drop the notion of 'graphing' and make use of the 'Object Oriented' figure paradigm. I recommend using GUIDE to construct gui's to do this. The Matlab User Groups library probably already has a few examples of how to do this. A full time Matlab programmer as a Team member makes a lot of sense.

That's my two dimes worth. (Pair a dimes, eh?)
I have no doubt a suitable GUI _could_ be built in MATLAB, but it makes no sense to do it if the alternative is cheap enough. Normal make-vs-buy decision.

This was available to us for less than half the cost of a MATLAB license:

http://www.gems.co.uk/assets/Image/Products/Software/GDA/gda%20screen%20overview.png

Bill, if you are skilled in MATLAB, can you estimate the man-hours required to implement something similar? What about if you weren't skilled in MATLAB at first?

If MoTeC i2 Pro or Pi Toolbox or Marelli WinTAX were available with csv import & maths for a similar cost, we could have gone with one of them instead.

Regards, Ian

exFSAE

12-19-2012, 04:44 AM

My earlier point with using (or integrating) MATLAB into data analysis is that while i2 and Toolbox and all these things do have some math channel functionality... they're still fairly limited. ATLAS does excel a bit in that respect, but then falls short in other areas.

In all reality, anything FSAE level I'm sure is more than adequately met by any of the common data analysis packages. Just saying it's worth keeping in mind that at a higher level - particularly where dedicated or more experienced programmers are available - it's not an insurmountable undertaking to do a more functional and custom-tailored data tool in MATLAB or Visual Studio or what have you.

murpia

12-19-2012, 05:45 AM

Originally posted by exFSAE:
My earlier point with using (or integrating) MATLAB into data analysis is that while i2 and Toolbox and all these things do have some math channel functionality... they're still fairly limited. ATLAS does excel a bit in that respect, but then falls short in other areas.
What functionality did you find missing in i2 & Toolbox?

I agree ATLAS seemed best last time I used it, not least because you can write your own custom controls. If I remember right, i2 has single-statement maths (like an Excel formula), unless you write a plugin. Toolbox & GDA offer multi-statement maths, while ALTAS offers C-syntax scripting (if you need it).

As an aside, does anyone know of an FSAE team that actually ever used Pi Toolbox, MES ATLAS, Bosch WinDarab or Marelli WinTAX?

Regards, Ian

exFSAE

12-19-2012, 09:44 AM

Toolbox uses single expression maths.. or at least I've never seen otherwise. Advanced math, analysis, reporting, visualization etc. just not immediately there. Then there are small things. i2 being the first package I used I really like being able to overlay any two laps from an outing, which can't be done in Toolbox or ATLAS without loading the same outing/session multiple times.

ATLAS maths are much more 'legit' in that you can do much more in a programmatic approach, but so much of the base functionality of the program's interface is... not sure I'd call it buggy... but not well thought out or executed. Come to think of it, some of it is downright slow or buggy and crashes. Boggles me that F1 teams use this.

Then i2 is great for ease of use, doesn't require a USB dongle or MAC-address license, but all of your analysis capabilities are keyed to the data set and whether it was done with "Pro Logging" or what have you. At least in ATLAS and Toolbox you can do an ASCII import or use the wrapper to make a *.pds and go to town.

I've used some stuff from RaceLogic.. not particularly impressed there. Haven't used Marelli or Bosch products.

As I say, they're all adequate for casual or trackside general data work. For deeper "analyst-level" stuff, IMO the best bet is to do a generic MATLAB GUI front end where you can pretty quickly set up tabbed displays in any configuration you want, and then on the back end you can add all the functionality you can dream of.

In any event, been a while since I did FSAE but no, I don't recall seeing anyone using Pi, MES, Marelli, etc. DAQ packages. Never saw them market themselves to the field, whereas MoTeC did (including through Claude's ubiquitous seminars)

Menisk

12-19-2012, 07:20 PM

Originally posted by exFSAE:
Then i2 is great for ease of use, doesn't require a USB dongle or MAC-address license, but all of your analysis capabilities are keyed to the data set and whether it was done with "Pro Logging" or what have you. At least in ATLAS and Toolbox you can do an ASCII import or use the wrapper to make a *.pds and go to town.

If you know what you're doing you can get any data into i2 Pro so long as you can get it into CSV format. It's a hell of a roundabout but it works.

First you need to grab the installer for interpreter as it has motec_convert.exe, but you'll need to use the waybackmachine on archive.org to find the right version because I've found the recent versions of interpreter come with a broken version of Motec_convert. You'll find that Motec_convert is picky as hell about your CSV format. Export something as CSV from interpreter and copy the format they come out as.

After you run your CSV through Motec_convert you get an old .ld file. To convert it to a new standard log you'll need an exe called motec_fix.exe or motecfix.exe that you'll find on the rFactor forums somewhere. Search for MoTeC on there and you'll find it.

Then if you want to convert them up to a pro-log it's a matter of changing 7 bytes in the header of the ld. I won't tell you which 7 because you shouldn't be doing it anyway.

And just remember that the i2 EULA specifies that you can only use i2 with data that was created on a MoTeC device.

nkikas

12-20-2012, 10:49 AM

My first thought was to go with motec too, since we already have a motec ECU. This way, and knowing that the i2 is easy to use, I could get all the data from the sensors including the ones from the engine that are connected to our ECU, to be displayed together. Problem is I am not sure we can afford it. So I contacted the other companies I mentioned above and they have sent me their offers. The price difference is quite large. As for the MATLAB solution, we have thought about it, but it is not possible to do it for now. I am thinking of slowly working on it, but we need a data logging system as soon as possible. Any of you working with:
-evo4 from AIM
-uCAN from 2D
-DL1 MK3 from race technology
These are the ones the companies recommented. Also someone mentioned that the race technology software displays only the voltages of the sensors. That sounds like it could be a problem.
Do you believe that motec is worth the extra bucks?

P.S. I appreciate your opinion and any suggestions are welcome.

Nick Kikas
Electronics-Data Acquisition
Aristotle Racing Team

jlangholzj

12-20-2012, 12:34 PM

Originally posted by nkikas:
My first thought was to go with motec too, since we already have a motec ECU. This way, and knowing that the i2 is easy to use, I could get all the data from the sensors including the ones from the engine that are connected to our ECU, to be displayed together. Problem is I am not sure we can afford it. So I contacted the other companies I mentioned above and they have sent me their offers. The price difference is quite large. As for the MATLAB solution, we have thought about it, but it is not possible to do it for now. I am thinking of slowly working on it, but we need a data logging system as soon as possible. Any of you working with:
-evo4 from AIM
-uCAN from 2D
-DL1 MK3 from race technology
These are the ones the companies recommented. Also someone mentioned that the race technology software displays only the voltages of the sensors. That sounds like it could be a problem.
Do you believe that motec is worth the extra bucks?

P.S. I appreciate your opinion and any suggestions are welcome.

Nick Kikas
Electronics-Data Acquisition
Aristotle Racing Team

any decent DAQ unit should have CAN capability. If it doesn't, I'd honestly rule it out as an option. If the unit itself isn't already programmed for the MOTEC protocol, its available online or through motec and with some additional setup you'd have all your sensors. The AIM unit we use has the motec protocols in it already so it was literally a plug and play.

Matlab would be more for the back end of things and it can be *cough* "found" *cough* around the web for a "reduced price" so to say.

exFSAE

12-20-2012, 01:06 PM

Or you could get it legit reduced price through your school. Maybe even free if they do network licensing and you VPN.

murpia

12-21-2012, 01:20 AM

Originally posted by nkikas:
... Also someone mentioned that the race technology software displays only the voltages of the sensors. That sounds like it could be a problem.
I don't think that's true. If it was, it would certainly be an issue. Probably it's just a setup thing.

By coincidence, I've been using MoTeC i2 again this week, instead of GEMS GDA Pro. One thing I do not like is the global nature of channel colours & axis limits. Editing these on one graph affects all the others in the project.

Does anyone know if / how this can be overridden?

Thanks, Ian

Rex Chan

12-21-2012, 03:25 AM

RT only *logs* voltages, YOU have to tell it the transfer function in the Analysis software. MoTeC requires you to tell it the calibration curve in the device setup, and usable values appear in i2 Std/Pro.

Both work, but I think MoTeC works better in the long run when you have high turnover rates of team members.

Cardriverx

12-22-2012, 08:12 PM

Do I think its worth the extra money? Yep, I mean even if you only look at the hardware, it is way better built that anything else I have used (Mclaren and Bosch excluded because they cost even more).

Ill give you an example. Last year I spent over two weeks just to get the CAn communications to work between our DL1 MK3 and our PE ECU3 (both devices JUST had CAN support added). Even after I got them to communicate, the DL1 still did not work well, channels are transmitted at a very low rate and overall it doesn't work well.

This year I got our MoTeC SDL3, M400, and PDM30 in about a week ago. I wired everything up on the dyno in a weekend, fired everything up, and finished setup in about 4 hours. Everything works flawless.

It really just depends on how much money you have. If you can't afford MoTeC, then you can't afford it. Find the next best solution and go with it.

Originally posted by nkikas:
My first thought was to go with motec too, since we already have a motec ECU. This way, and knowing that the i2 is easy to use, I could get all the data from the sensors including the ones from the engine that are connected to our ECU, to be displayed together. Problem is I am not sure we can afford it. So I contacted the other companies I mentioned above and they have sent me their offers. The price difference is quite large. As for the MATLAB solution, we have thought about it, but it is not possible to do it for now. I am thinking of slowly working on it, but we need a data logging system as soon as possible. Any of you working with:
-evo4 from AIM
-uCAN from 2D
-DL1 MK3 from race technology
These are the ones the companies recommented. Also someone mentioned that the race technology software displays only the voltages of the sensors. That sounds like it could be a problem.
Do you believe that motec is worth the extra bucks?

P.S. I appreciate your opinion and any suggestions are welcome.

Nick Kikas
Electronics-Data Acquisition
Aristotle Racing Team

nkikas

12-23-2012, 07:06 AM

Thanks a lot. Since you guys have used more than one DAQ system you are the ones that can compare them. I would like to go with Motec too, but we don't know if we can afford it yet. :/ .
In case we can't, I was thinking of AIM as a second best maybe...

SNasello

12-23-2012, 10:23 AM

I'll chime in here, as no one has said anything yet about the 2D-Datarecoring system. Do not let the small company fool you, as this is quite a powerful data logger and software. The price for formula student teams is unbeatable for what you get, and the software is just as powerful as Motec, albeit a little bit dated perhaps.

It is still quite an easy system to set up and use. Even if you don't have any money for additional sensors, you get a 3-way Gyro and GPS built in, which will get you started. All the inputs are 16-bit and you can log at up to 800Hz per channel, which should be more than enough for shock displacement. I think the new version also has 4 frequency inputs, the one we have only had 3, but its also a few years old. Finally it has 2 independent CAN buses, with full CAN routing, which means you can send data from one bus to the other, or send the data from the GPS, analog or digital inputs on one of the busses.

The software is capable of the all the same analysis functions as Motec, like Histograms, XY plots, FFT, Min-Max tables. The offline maths are also there, but a little bit tedious to use and get used to. There is a MATLAB interface apparently but I have somehow not got it working properly, and I can't speak for what it is capable of.

The software also has a database program called 'Specsheet' where you can keep setup notes, and quick information about the data file. Every time you make a download it updates it, including the driven mileage from your last run, the lap time, total run time, etc. as well as any vehicle specs that you want to define or track (like spring rates, damper settings, ride heights, cold pressures, etc.).

If you want to get a hand for the software you can grab the demo from their homepage, which is actually the full version with some demo data. See if you like it first, in the end the software is the most important, when the logger is good.

As for my experience of the other systems, I would also not recommend the DL1. The software is horrible, channel setup is a nightmare, and you are limited to relatively slow logging. I also think the inputs are only 12 bit, which should be enough if you pick your sensors properly.

The Motec software is excellent, but I have never really worked with their systems. I would say the 2D software is almost on par with Motec, but not quite as good. Motec can do some things better than 2D and vise versa. On the other hand, you are paying quite a bit for it. If you compare the price of the 2D system to that of Motec (for formula student teams), I would take 2D.

jlangholzj

12-23-2012, 07:42 PM

Originally posted by nkikas:
Thanks a lot. Since you guys have used more than one DAQ system you are the ones that can compare them. I would like to go with Motec too, but we don't know if we can afford it yet. :/ .
In case we can't, I was thinking of AIM as a second best maybe...

The aim is more than just a second best. Channels are all set up per the name already. I wired it into the motec's can within 15 minutes and had it reading values from the ECU. It also supports multiple can devices connected.

One of the reason's I'd pick the motec over the AIM is for the I2 compatibility. If you're not proficient in either yet, then its 12 one way and a dozen the other.

Ours has worked flawlessly over the last year and has been a valuable asset. Also its great for teams on a budget...which was a big reason for us choosing it. We got ours through Precision Auto Research (the guys who sell RDP and are also an AMAZING company btw) for about $1400 if i remember right.

murpia

12-24-2012, 12:31 PM

Originally posted by Cardriverx:
Ill give you an example. Last year I spent over two weeks just to get the CAn communications to work between our DL1 MK3 and our PE ECU3 (both devices JUST had CAN support added). Even after I got them to communicate, the DL1 still did not work well, channels are transmitted at a very low rate and overall it doesn't work well.
Did you have access to a 3rd party analyser of some kind? Without one, CAN can be difficult, with one the reason for problems usually becomes obvious.

I can recommend either of these, your budget may dictate a particular solution:

http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 (http://www.peak-system.com/PCAN-USB.199.0.html?&L=1http://www.peak-system.com/PCAN-USB.199.0.html?&L=1)
The free software is fine, the paid-for is better, and there is a free DLL to write your own. Better for protocol level debugging.

http://www.picotech.com/oscilloscope.html
The scope software includes CAN decoding off just 1 physical line. Better for physical layer debugging.

I'm also aware of:
http://www.canusb.com/

No doubt you can find a dozen more if you Google for 'USB CAN'.

Merry Christmas and a Happy New Year, Ian

Cardriverx

12-24-2012, 12:53 PM

The canusb works well, I have used it before.

It wasn't the setup of the CAN bus that was the issue, it was the fact that I had to go back and forth with Race-technology multiple times to get it to even work on the MK3 (again, brand new feature, had to do with their unlocking scheme). Then after I did get it working the update rates were very slow (on the order of 5 hz). Of course that could be the PE ECU or the MK3. Also I don't like that the CAN pins are on the same connector as the serial port. And the lack of any live view other than using RS232 (which I couldn't get to work) is annoying as well.

I mean all this can be worked around, but if you have the money its not worth it. Plus MoTeC stuff has great CAN diagnostic features on board.

Originally posted by murpia:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by Cardriverx:
Ill give you an example. Last year I spent over two weeks just to get the CAn communications to work between our DL1 MK3 and our PE ECU3 (both devices JUST had CAN support added). Even after I got them to communicate, the DL1 still did not work well, channels are transmitted at a very low rate and overall it doesn't work well.
Did you have access to a 3rd party analyser of some kind? Without one, CAN can be difficult, with one the reason for problems usually becomes obvious.

I can recommend either of these, your budget may dictate a particular solution:

http://www.peak-system.com/PCAN-USB.199.0.html?&L=1 (http://www.peak-system.com/PCAN-USB.199.0.html?&L=1http://www.peak-system.com/PCAN-USB.199.0.html?&L=1)
The free software is fine, the paid-for is better, and there is a free DLL to write your own. Better for protocol level debugging.

http://www.picotech.com/oscilloscope.html
The scope software includes CAN decoding off just 1 physical line. Better for physical layer debugging.

I'm also aware of:
http://www.canusb.com/

No doubt you can find a dozen more if you Google for 'USB CAN'.

Merry Christmas and a Happy New Year, Ian </div></BLOCKQUOTE>