New XFI update that supports Intelligent traction Control!!!

There is also a few other new things.
It will set a ckeck engine light if the Inj d/c gets out of range
Also has the capabilty to run it in flex/fuel mode,With the addition
of a fuel composition sensor it will automatically make the changes needed
for the different fuel
 
Questions

From Cal's response I assume... that the ecu detects unusual acceleration/time but is that something you set in the software? What about burnouts? It would seem the best logic is to compare the drive shaft speed vs the front wheel speed above "x" MPH and some sort of drive shaft delta accelaretion limit at the same time so when the front wheels are off the ground it dosen't cut power. Just trying to imagine how they are controling the power cut. If this acc/time is a parameter set in the software I would imagine you would have to change this limit for say a street tune and street tires compared to a track tune with track tires. And is this something that is switchable by the multi set up with the thumbwheel?
 
Is this traction control enabled with just a software or flash update or do I need to buy another XFI box reap the benefit?
 
It is my understanding that you need to send in your ECU to be updated and change the inclosure to one that has a traction control logo and different color. All the prototypes were suposed to be sent in for this update as well.
 
So on the driveshaft sensor, 40 pulses per driveshaft rev would be 140 pulses per tire rev assuming a typical 3.50:1 rear gear ratio. So it's really like having a 140 tooth sensor wheel mounted on the tire in that case, which gives us about 2.5 deg of tire rotation per pulse.

2.5 deg of tire rotation is then only about 0.65" of tire travel on the pavement per pulse on a 30" diameter tire.

At 8000 rpm then through the lights in high gear (1:1) we'd have a sensor pulse train coming in to the ECU at 133 pulses per second. Still pretty reasonable by modern computer standards actually, but probably quite a strain on a microcontroller based ECU also loaded with engine control code loops as well at maybe like 100Hz or so. For comparison we see about 300 interrupts per second on average coming in to a modern laptop CPU with Windows Vista when conditions are very "quiet" at idle :) But the CPU load stays < 2-3% on average while handling all this, and while also hamstrung in the minimum performance state as well. Plenty of computing hp available there.

Ahh fun (lol). Think the XFI ds sensor appraoch probably provides about all the tire slip resolution we could ever need or ask for here.

I tend to agree with MSD now that what they have in the 7531 (slew control) is not really traction control. Though it will probably remain controversial as long as there are race cars using it.

TurboTR
 
TurboTR said:
I tend to agree with MSD now that what they have in the 7531 (slew control) is not really traction control. Though it will probably remain controversial as long as there are race cars using it.

TurboTR
Click to expand...

Keep in mind the XFI can also do the slew control for those that prefer that method.
 
Thanks. So can you explain how you came to prefer the driveshaft sensor method vs the slew control? And is it generally enough to just retard the timing, or does the rev limiter have to be brought in to make it work best in your experience?

TurboTR
 
Cal looking in the help file, I don't see that it talks about being able to control with rpm slew rate vs driveshaft sensor input. Can you point out where this is mentioned please? Thanks.

TurboTR
 
I think this is what your asking for:

32.6 ITC PA Mode

PA Mode differs from Heuristic Mode in that it uses actual driveshaft RPM as the base curve to calculate from. The farther/faster your driveshaft goes over the programmed curve, PA Mode will begin cutting out cylinders sequentially (both fuel and spark) until the driveshaft RPM comes back to even or below the programmed curve. As mentioned above in Heuristic Mode, using actual driveshaft RPM instead of engine RPM gives you many advantages. There are no plots to chase, no gear shift spikes, no torque convertor/clutch slippage to deal with. It’s simply the speed of the shaft that the rear axle is being driven with


I have used this method in conjunction with the Heuristic Mode on certain applications. It is much more complicated to set up initially. I don't recommend it for the novice tuner.
 
After watching Dave's video, I am guessing that traction control is a feature that Big Stuff 3 does not have? :confused:
 
Big Stuff 3 has an excellent, highly advanced traction control system, Dave does not have it however. Might be something for him to look at :)
Mike
 
Please keep in mind, the traction control in these boxes do have limitations. They can help a driver get down a marginal track, but they can't perform miracles. Once Dave slammed on the brakes, the traction control was pretty much a non-issue
 
Guess I misunderstood your reply to Bill. It seemed you were saying the FAST can do traction control based on engine rpm, not drive shaft sensor input. From what I've been able to find in the help file, it seems it's all based on the driveshaft sensor input, with no mode that works on engine rpm instead.

TurboTR


Quote:
Originally Posted by EightSecV6
From my experience, it is much more accurate for an ECU to "predict" changes in engine RPM and adjust accordingly PRIOR to wheelspin than it is for an ECU to SEE drive shaft speed increasing (tires already spinning) and make changes to stop the loss of traction.

Then just use the slew rate of the XFI traction control and turn the delta d/s off. It will perform just like the MSD that you are familiar with.
 
So back to the question of resolution, it's an interesting problem, and guess it also depends on how the FAST acquires ds sensor pulse information. If it just accumulates a pulse count over a 0.1 sec interval for example (ie reads a pulse counter every 100ms), then we have a fixed 100ms resolution basically it seems. If it instead updates a ds sensor speed count on every pulse that comes in (interrupt style) then we could get up to like < 1" of tire travel resolution. Would likely have to filter that a bit too, so lower net resolution than that. But the work load on the FAST cpu would be much much higher with the interrupt method. Don't know that FAST will tell us, but would guess they may use the former method.

So then at say 60 mph (88 ft/sec) and with a 32" dia tire (about 100" circumference, 8.3 ft), we'd get about 10.6 tire revs/sec. About 1 tire rev per 0.1 sec interval. At 30 mph 0.5 tire rev/0.1 sec, At 120 mph 2 tire revs/0.1 sec, etc.

A 40 tooth ds sensor, with a 3.50 gear ratio would give us about 1500 pulses/sec at the point, or 150 pulses/0.1 sec interval. At 30 mph we'd have 75 pulses/0.1 sec, at 120 mph we'd have 300 pulses/0.1 sec, etc.

Trying to get a feel for how a "100ms resolution" would equate to a spinning tire in the real world, it would be able to evaluate slip over about 1/2 tire revolution at 30 mph, 1 tire rev at 60 mph, 2 tire revs at 120 mph, etc. Seems reasonable. Comments?

TurboTR
 
Heh, well guess it better. What do you have to do to get the TC control parameters to appear in CCom? Does your CCom machine have to "touch" a TC enabled ECU, or is it enough to just save the .gct in a TC enabled CPU? To be able to view the TC parameters on another CCom machine I mean. Thanks!

TurboTR
 
You must log in or register to reply here.

Similar threads

E
SD2 / Powerlogger Pro 2014 Update - Flexfuel
2 3 4
Replies
69
Views
14K
Eric Stage I
E
M
FAST XFI 2.0 has 2.001 update
Replies
6
Views
2K
turbobitt
turbobitt
T
XFI 101 and XFI Extreme coming to Memphis at Comp Sept 10-12th
Replies
0
Views
802
TurboNova
T
Top