Datalogging - Page 6

JamesH · 11 Sep 2008, 15:41 (Ref:2287263)

CRC? Pah. I was there when it was CCAT - Cambridge College of Tarts and Sexology. (class of 85)

James

Andrei · 11 Sep 2008, 20:20 (Ref:2287484)

Well, maybe I do not understand the philosophy behind STACKS's option to unlock software features.

From my point of view (and I know what you are saying about devlopment, programing and so on), when I am spending a couple of tousends on a display and a recorder module, I want to have a software capable of doind everything I want with the data, not to have to spend money on certain features.
I am now exporting the data la Matlab and work with it there. This is a solution evybody has, no doubt, but, in my opinion, it would be better to have the possibility to do the stuff with the original software.

JamesH · 12 Sep 2008, 08:24 (Ref:2287840)

But then you have to pay for Matlab....why not pay for the module you want instead?

The problem is with your statement - "I want to do everything I want with the data". The problem is that what you want may not reflect what everyone wants. If everything is put in to start with them the price you pay goes up. The way its done here you only pay for the bits YOU want.

It seems to me that you just want a cheaper price...!!!

Rubinho · 12 Sep 2008, 13:29 (Ref:2288060)

Quote:

Originally Posted by Andrei

Well, maybe I do not understand the philosophy behind STACKS's option to unlock software features.

From my point of view (and I know what you are saying about devlopment, programing and so on), when I am spending a couple of tousends on a display and a recorder module, I want to have a software capable of doind everything I want with the data, not to have to spend money on certain features.
I am now exporting the data la Matlab and work with it there. This is a solution evybody has, no doubt, but, in my opinion, it would be better to have the possibility to do the stuff with the original software.

The philosophy is easy; it's called business. They have spent resources developing software for which they want a return on their investment so they can stay in business. The extra features cost extra to develop so they charge extra for it.

I presume you don't own MATLAB under your own personal licence. The fact that a data logging supplier in a small market cannot absorb the costs of piracy is why they protect software with hardware keys and extra-cost licences. The fact that Mathworks (and Microsoft etc.) software is so easily copied isn't an excuse to complain when one must pay for extra features in legitimately protected software.

Forgive me for accusing you of pirating MATLAB but if you can afford a licence for this (which costs £700 even in academic guise) then you can afford any of the data packages and their extra features out there.

In the grand scheme of things a couple of thousand (pounds, euros or dollars) is pretty inexpensive to expect professional level motorsport features bundled in for nothing.

JamesH · 12 Sep 2008, 15:03 (Ref:2288129)

You could always write your own software if you don't want to pay for it! Make it open source! Give it away!

Or will that take too long?

Armchair Enthusiast · 12 Sep 2008, 15:53 (Ref:2288180)

If there was no such thing as piracy, I wouldn't be able to download motorsport events that aren't shown on TV in the UK.....

I think a good point has been made, but let's not dwell on it too much, lets get back to discussing the pro's and con's of datalogging for various types of motorsport.....

Andrei · 13 Sep 2008, 20:38 (Ref:2289246)

Well, I am in the good position not having to pirate sofware for racing.
I am using Matlab normally from my employer, also like I have used 2D, Stack, Bosch and some other DAQ-Software.
The version wee have had form 2D was basic and I have understood it because it was for entry level motorsport for kids.
We have ordered 3 STACK systems last year with 8109G display and a recorder module to be able to record CAN informations. Here I hav beend really surpized that I am missing some math channels in the basic software.
In STCC I have used Diadem routines with a unknown system for general motorsport, where I have had maximum possibility to do whatever I want.
Motec was also with all the features I needed with the donloaded analyser from Internet and the Bsch software I have used was also with all features normally neaded.
I am usualy using Matlab for performing calculations that I think are to much for the DAQ-software.
I have really appreciated STACK for a couple of features, but I have to say that STACK was over all bellow my expectations.

lander · 21 Sep 2008, 11:13 (Ref:2294572)

What you think about AIM MyChron3 XG Log? I am thinking to install it on steering wheel in my Dallara F394. I have Magneti Marelli dash display, but it hasnt dataloging.

ubrben · 21 Sep 2008, 16:41 (Ref:2294694)

I can sort of see both sides of this argument, but on the other hand Motec do very well as a business as much because intepreter and i2 are free than in spite of it.

You have a huge number of people who know i2 inside out and as a result there is a decent pool of cheap data engineers who want experience and a large demand for Motec products because of that user base.

Catia has cornered the CAD market because (and one of their UK vendors told us) they turn a blind eye to engineering students pirating V5. Again a huge number of people have bought V5 because the user base is there.

Taking a different tack with the person *****ing about a lack of features, export the data set as a .csv or .ascii file and use Scilab (free version of matlab essentially) to calculate whatever you like.

Ben

williamsf1 · 23 Sep 2008, 08:07 (Ref:2295850)

does anyone here know the rough cost of the software PI use for their data logging?

PS I love the motec i2, so simple, and easy to use... is PI nasty? or similar...

Rubinho · 23 Sep 2008, 12:33 (Ref:2296045)

Quote:

Originally Posted by williamsf1

does anyone here know the rough cost of the software PI use for their data logging?

PS I love the motec i2, so simple, and easy to use... is PI nasty? or similar...

There are two Pi suites for data analysis. Club Expert Analysis which is supplied with the club logging products and Pi Toolbox which comes with the professional level products. Both Club Expert Analysis and Pi Toolbox Lite come included in the price of their respective data products. To get the full version of Pi Toolbox a hardware licence key must be purchased for £1000. The Lite version of Toolbox contains all features except real-time telemetry viewing, power spectral density display, and multiple worksheets/tasks. Full maths channel capability is in the Lite version.

The user interface is very similar to I2 and was designed first. Some people even say that the I2 interface is a rip-off of Toolbox's.

ubrben · 23 Sep 2008, 16:14 (Ref:2296211)

Quote:

Originally Posted by Rubinho

The user interface is very similar to I2 and was designed first. Some people even say that the I2 interface is a rip-off of Toolbox's.

Quite possibly, but most people won't know that because most people will never get the chance to get near PI toolbox. PI's top end stuff is good, but Motec have a much better idea of how to sell to lower levels of racing.

Be

Belatti · 10 Nov 2009, 14:46 (Ref:2579556)

Quote:

Originally Posted by youngoldy

When it comes to configuring the logger, Pi, as far as being the only data system that you have to setup, is the easiest. Make sure that you enter all the values correctly into the logger. You can then save a config file. This saves all the confiuration settings, so whenever you need to configure the logger/system again, all you do is load the config file, and apply it. I found this out at the 06 WHT, and that really will save me shed loads of time when we are out again this year.

You could do this in you garage before the start of the season, and make sure you know where the config file is saved, so when you need to reset the system, you don't have to enter all the values of the sensors again. And when configuring the logger, with Pi you can alter the logging rates pretty easily. The only negative of that is longer downloading time, bigger size of the file, but doesn't have any effect on the quality of the data, only increases the quality, like looking for understeer/oversteer on the g sesnor reading.

Really?

Right now Im having problems with a couple of Pi logging systems I have acquired second hand.

Box #2 runs perfectly in both cars, but Box #1 doesnt.

I cant seem to configure Box #1 when I load both *.map and *.plc files on it. I have even formated the #1 Box with the same *.pdp file as the Box #2 and nothing.... with Box #1 I can watch the sensors and they seem to work OK but after a session, the date is 00/00/2000 and the Pi Delta software wont create the *.pid file to see the logged data in the Pi Toolbox.

Does anyone have had this problem before?

I dont know if I can ask for Pi support because system is second hand... and I wont get track support (Im in Argentina) thats for sure...

greenamex2 · 10 Nov 2009, 17:10 (Ref:2579629)

Can't hurt to try them.

Alternatively try www.apexspeedtech.com, Neel is very helpful.

Belatti · 11 Nov 2009, 18:24 (Ref:2580262)

Thanks Denis!

Rubinho · 12 Nov 2009, 19:03 (Ref:2580950)

Quote:

Originally Posted by Belatti

Really?

Right now Im having problems with a couple of Pi logging systems I have acquired second hand.

Box #2 runs perfectly in both cars, but Box #1 doesnt.

I cant seem to configure Box #1 when I load both *.map and *.plc files on it. I have even formated the #1 Box with the same *.pdp file as the Box #2 and nothing.... with Box #1 I can watch the sensors and they seem to work OK but after a session, the date is 00/00/2000 and the Pi Delta software wont create the *.pid file to see the logged data in the Pi Toolbox.

Does anyone have had this problem before?

I dont know if I can ask for Pi support because system is second hand... and I wont get track support (Im in Argentina) thats for sure...

Backup battery for the real-time clock in the Delta logger has run out. You can send it back to Pi for a replacement. I'll PM you an email address you can contact.

Belatti · 13 Nov 2009, 12:30 (Ref:2581334)

Indeed!

Thats what they told me!

Thanks you very much for the PM Rubinho

johnny99 · 17 Nov 2009, 08:13 (Ref:2583356)

I am looking at the Digidash from ETB, a dash and data logging all in one, and reasonably priced. I spoke to them on the phone a few weeks ago , and they seem very well informed and hlepful.

John

Belatti · 19 Nov 2009, 15:53 (Ref:2585150)

I have been using now the Pi and watching the logged data in Toolbox I realised I have 2 steering channels, 1 named "steering" wich displays what the sensor measures and another named "real steering" wich is a mathematical channel.

The mathematical formula for this last channel is the following:

180/3.14159*asin(2.55/(pow(([Speed]/3.6),2)/(9.812*[Lateral G])))

I cant seem to fully understand this formula... what is that 2.55?

Can somebody help me to sort this formula out?

Is "pow(([Speed]/3.6),2" = (V/3.6)^2 ???

I dont know if I can trust the data from this channel and I want to use it in order to guess tyre slip angle because I know my ackerman arm is way wrong but I want to know how much

Rubinho · 25 Nov 2009, 21:20 (Ref:2589230)

Quote:

Originally Posted by Belatti

180/3.14159*asin(2.55/(pow(([Speed]/3.6),2)/(9.812*[Lateral G])))

This is a confusing channel because there are many unit conversions which are unnecessary in Pi Toolbox if you are using the maths functions correctly. It will convert channel units for you automatically meaning you don't have to use the fudge factors.

9.812 * [Lateral G] converts the [Lateral G] channel from G to m/s^2
[Speed]/3.6 converts [Speed] from kph into m/s
pow(([Speed]/3.6),2) raises [Speed] in m/s to the power of 2 (squares it)
asin(...) is the inverse sine of everthing in the brackets
180/3.14159 * everything looks like a conversion to degrees from radians

The instantanous corner radius the car is travelling on is [Speed]^2 / [Lateral G]. It is calculating an angle between a this and a side of 2.55m (wheelbase probably) which it then converts to degrees.

I would say that it is trying to calculate the instantaneous neutral steering angle. By comparing this to the actual measured steering angle it will crudely tell you if the car is under- or over-steering. Except it is wrong.

A better approach is:

(CONST(Wheelbase) / pow([Speed],2) / [Lateral G]) * CONST(Steering_Ratio)

Wheelbase is in m
Steering_Ratio is the ratio between front wheel angle and steering-wheel angle

Using the conversion ratios built in to Toolbox and setting the output Quantity and Unit to Angle, Degrees will allow you to dump the conversion factors. In my experience though, the signal-to-noise ratio of these under-/over-steer channels is not high and it is usually better to look at the steering channel independently to see the driver's reaction to the car's behaviour.

Belatti · 26 Nov 2009, 03:09 (Ref:2589363)

Rubinho, thank you very much!

Indeed, I found 2.55 is wheelbase!

Quote:

Originally Posted by Rubinho

Wheelbase is in m
Steering_Ratio is the ratio between front wheel angle and steering-wheel angle

Using the conversion ratios built in to Toolbox and setting the output Quantity and Unit to Angle, Degrees will allow you to dump the conversion factors.

How can I know whats the steering ratio when I have not parallel ackerman geometry?
About the conversion ratios built in to Toolbox I´ll have to dig in a little more... (some things lost in translation

)

Quote:

Originally Posted by Rubinho

In my experience though, the signal-to-noise ratio of these under-/over-steer channels is not high and it is usually better to look at the steering channel independently to see the driver's reaction to the car's behaviour.

I agree! Id rather look and compare laps between different races/sessions what the driver was doing with the steering wheel (and throttle and brakes at the same time)

Belatti · 26 Nov 2009, 14:02 (Ref:2589690)

Quote:

Originally Posted by Belatti

...

About the conversion ratios built in to Toolbox I´ll have to dig in a little more... (some things lost in translation

)

Rubinho, never mind this question, I have found this older thread where you already answered my question to another guy

http://tentenths.com/forum/showthread.php?t=99236

Belatti · 26 Nov 2009, 14:25 (Ref:2589699)

OK, now I tried your approach in the Real ST channel I created, I have picked a 0.777 steering ratio (7 deg in wheel for 90 deg in steering wheel input ) but it returned No Value

I even tried changing units from the input channels...

Check that with the channel I had (green trace) you can see the "bit nervous" driver input (black trace)...

Rubinho · 28 Nov 2009, 00:10 (Ref:2590502)

I should have explained better, sorry. When you use CONST() Toolbox expects to find a name in the () which evaluates to a constant value in Tools|Constants. For example where I have said CONST(Wheelbase) you would set up a constant named Wheelbase with a value of 2.55 in Constants Management. If you want to use a literal value you can simply use it in the maths channel without the CONST() function. So:

(2.48 / pow([Speed],2) / [Lateral G]) * 0.777

Would be your channel using literals, or you could use my original version with constants named Wheelbase and Steering_Ratio set up in the workbook.

There's an assumption in this channel that the car follows the "bicycle model" (i.e. has only two wheels) so complications like toe and bump effects on the steered wheel angle is ignored.

P.S. I've just noticed in your channel you have speed as kph, you probably want this in m and Lateral G in m/s^2.

forestdweller · 28 Nov 2009, 15:33 (Ref:2590818)

Since this thread appears to be centered around understeer angle at them moment, I was wondering if any of the experts could comment on an observation I made. I've been comparing two different drivers, looking for differences in style that could potentially help one or the other improve. The application is SCCA autocross. The two driver's are sharing the same car.

I'd been looking at steering angle, Ackerman steering, and understeer angle. As there seemed to be a fair amount of "artificial" understeer at initial turn-in, which is a large amount of time in autocross, I filtered the understeer channel for lat g values greater than 0.9 g and plotted the frequency distribution. Some differences between the two drivers started to show up. Looking at datalogs from various events through the season, the patterns were pretty consistent regardless of which driver was faster on that particular day. (There are MANY other factors that could have contributed to that though.)

My take on it is that the second driver (black) is doing a better job of feeling the the limits of the tires on a consistant basis. OR the first driver (red) is just more aggressive. I'm leaning towards the former. Am I reading too much into a channel with a low signal to noise ratio?

Have a look and tell me what you think: