Jump to content
SAU Community

Recommended Posts

yeah I personally think it's a bad idea and a waste of time and money for anything except a maximum effort race car. and even then I don't see any of the top level circuit cars using such a system. good tuning, and correct size for application turbos mean it's not needed. there is no doubt it's damaging to your car.

lol, I just realised this thread title is funny. "true anti-lag" what you have is not true anti lag. like you mentioned it's just an ignition cutting misfire type.

but isnt that the basis for anti lag?

on launch induce spark cut to create backfiring and wind up the exhaust housing

on gear change if the user flat shifts induce spark cut to wind up the exhaust housing

what other form of antilag is there ?

the real deal has control over both fuel and spark to get things working. and it can be mapped against load and throttle. ie you can have the anti lag kick in when you back off the throttle. if michael has his set-up to misfire as he is acclerating between 3000 and 4000 I would say it's having a negitave affect, not a positive one. have a listen to wrc cars to get a feel for where (ie what throttle position) the anti lag is operating.

I have setup a few cars with anti lag on autronics, but to some degree it can be done with all programmable computers. I cant see any reason why you would ever have the antilag operating for 30 seconds. IMO there are two differnt schools of thought for antilag, drag and circuit. Drag just gives a stationary rev limit, allowing boost to be developed ready for launch, this can be used with enrichment and retardation for better results. Secondly there is the rally car style which is primarily to maximise transient throttle response. This can be setup in many different ways, stepper motor on the throttle. air injection(as late evo's) and rotating idle . Circuit cars dont tend to need it, as they tend not to need instantanious throttle response as it tends to unsettle the car. The other way of doing antilag for a car is to set your high rpm/light throttle load cells(above 3500rpm with vacuum below 15")to a mixture of 12.5:1 and retard the timing to 5 deg. In doing this upon gearchanges in nthe upper rev range, it significantly reduces transient response or "lag". This seems to also work well on the track with big turbos, as it can be done cheaply and can be tailored to suit the driving style. It also doesn't affect any other driving characteristics, and is a set and forget sort of thing.

yeap its a big waste of time :P i will agree 100% there but i got it cheap form yahoo auction, and wanted to give it a try (wasn't really looking for any sort of anti-lag full boost under 3500rpm is good enough for me)

Beer Baron, when on full throttle the system does not missfire (so i can be accelerating down the straight and the system wont engage) BUT when on half throttle (for example taking a turn) the system sometimes turns on and results in the car jerking around like it get full boost but the throttle position (half open) wont let it use it all. This can be very frustrating as it normally results in my jumping off the throttle more (slowing down) or opening on the throttle more and losing grip (then taking the incorrect line).

I wasn't able to get my data logging system to work (epson ej1) so i wasnt able to properly time a run with the system on and one with it off. BUT it did feel as if i was going faster (coming out on turns i was higher up in the rev range, and getting a generally higher max speed for the track)

then again i am still new to track time, so it could of just been me improving over time and learning to uses my cars power and brakes more efficiently.

ohh discopotato03, the system doesn't have a launch control feature so basically i just have to hold the rev in the rpm range. I should also mention that i just did this for fun to see if it would make a difference, i dont have a issue with the lag the pro s turbo creates or lack of :)

And im due for a tune up sometime in the near future, so i get them to launch the car in 1st with the system on and off and see if it really does work

Cheers Michael

lol, I just realised this thread title is funny. "true anti-lag" what you have is not true anti lag. like you mentioned it's just an ignition cutting misfire type.

ahaha :P when i bought the system i was under the impression from the translation it was true antilag lol. Guess i need to invest in learning Japanese :)

random purchases from yahoo auction is great :P

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Similar Content

  • Latest Posts

    • First up, I wouldn't use PID straight up for boost control. There's also other control techniques that can be implemented. And as I said, and you keep missing the point. It's not the ONE thing, it's the wrapping it up together with everything else in the one system that starts to unravel the problem. It's why there are people who can work in a certain field as a generalist, IE a IT person, and then there are specialists. IE, an SQL database specialist. Sure the IT person can build and run a database, and it'll work, however theyll likely never be as good as a specialist.   So, as said, it's not as simple as you're thinking. And yes, there's a limit to the number of everything's in MCUs, and they run out far to freaking fast when you're designing a complex system, which means you have to make compromises. Add to that, you'll have a limited team working on it, so fixing / tweaking some features means some features are a higher priority than others. Add to that, someone might fix a problem around a certain unrelated feature, and that change due to other complexities in the system design, can now cause a new, unforseen bug in something else.   The whole thing is, as said, sometimes split systems can work as good, and if not better. Plus when there's no need to spend $4k on an all in one solution, to meet the needs of a $200 system, maybe don't just spout off things others have said / you've read. There's a lot of misinformation on the internet, including in translated service manuals, and data sheets. Going and doing, so that you know, is better than stating something you read. Stating something that has been read, is about as useful as an engineering graduate, as all they know is what they've read. And trust me, nearly every engineering graduate is useless in the real world. And add to that, if you don't know this stuff, and just have an opinion, maybe accept what people with experience are telling you as information, and don't keep reciting the exact same thing over and over in response.
    • How complicated is PID boost control? To me it really doesn't seem that difficult. I'm not disputing the core assertion (specialization can be better than general purpose solutions), I'm just saying we're 30+ years removed from the days when transistor budgets were in the thousands and we had to hem and haw about whether there's enough ECC DRAM or enough clock cycles or the interrupt handler can respond fast enough to handle another task. I really struggle to see how a Greddy Profec or an HKS EVC7 or whatever else is somehow a far superior solution to what you get in a Haltech Nexus/Elite ECU. I don't see OEMs spending time on dedicated boost control modules in any car I've ever touched. Is there value to separating out a motor controller or engine controller vs an infotainment module? Of course, those are two completely different tasks with highly divergent requirements. The reason why I cite data sheets, service manuals, etc is because as you have clearly suggested I don't know what I'm doing, can't learn how to do anything correctly, and have never actually done anything myself. So when I do offer advice to people I like to use sources that are not just based off of taking my word for it and can be independently verified by others so it's not just my misinterpretation of a primary source.
    • That's awesome, well done! Love all these older Datsun / Nissans so rare now
    • As I said, there's trade offs to jamming EVERYTHING in. Timing, resources etc, being the huge ones. Calling out the factory ECU has nothing to do with it, as it doesn't do any form of fancy boost control. It's all open loop boost control. You mention the Haltech Nexus, that's effectively two separate devices jammed into one box. What you quote about it, is proof for that. So now you've lost flexibility as a product too...   A product designed to do one thing really well, will always beat other products doing multiple things. Also, I wouldn't knock COTS stuff, you'd be surprised how many things are using it, that you're probably totally in love with As for the SpaceX comment that we're working directly with them, it's about the type of stuff we're doing. We're doing design work, and breaking world firsts. If you can't understand that I have real world hands on experience, including in very modern tech, and actually understand this stuff, then to avoid useless debates where you just won't accept fact and experience, from here on, it seems you'd be be happy I (and possibly anyone with knowledge really) not reply to your questions, or input, no matter how much help you could be given to help you, or let you learn. It seems you're happy reading your data sheets, factory service manuals, and only want people to reinforce your thoughts and points of view. 
    • I don't really understand because clearly it's possible. The factory ECU is running on like a 4 MHz 16-bit processor. Modern GDI ECUs have like 200 MHz superscalar cores with floating point units too. The Haltech Nexus has two 240 MHz CPU cores. The Elite 2500 is a single 80 MHz core. Surely 20x the compute means adding some PID boost control logic isn't that complicated. I'm not saying clock speed is everything, but the requirements to add boost control to a port injection 6 cylinder ECU are really not that difficult. More I/O, more interrupt handlers, more working memory, etc isn't that crazy to figure out. SpaceX if anything shows just how far you can get arguably doing things the "wrong" way, ie x86 COTS running C++ on Linux. That is about as far away from the "correct" architecture as it gets for a real time system, but it works anyways. 
×
×
  • Create New...