Jester did a pretty good judgment on mine, im only running .6 off from 11.5 so its not too to lean.

 

You are so conceited. Before the 2byteload we had the LoadCalc. Brian already told you that he uses that primitive method of yours when he tunes "on the fly." He also told you that he uses 2byteload now.

You still have not answered the question: How do you know that your method is more accurate than the 2byteload? You keep repeating that it is and yet you do not show us the evidence. Where is your evidence?

Again, you are so filled with hubris. My method leaves no room for "intuition." I rely on logging data when I tune. The information on how to tune is widely available. I did a long write-up on the methods that I use to tune. There is no need whatsoever to "rip off your knowledge." Nowhere in the write-up did I mention your archaic method. All the knowledge is available right here in Ecuflash forum.

Please stop saying that your method is more accurate than the 2byteload or even loadcalc for that matter. Until you provide data to prove it, you are simply stating an opinion.

 

Please stop posting nj1266. I think I speak for the forum majority when I say I find your posting most annoying. Like you are trying to make a name for yourself by argueing with vendors or something. I have watched you pull a number of threads off topic and am tired of reading your crap.

 

This is not off-topic. It is on topic. The thread is about tuning w/o afr and logging the 2byteload is central to finding the correct cells for AFR targets. 2byteload is far more accurate than any other method when locating the correct cell to tune. It is more accurate than LoadCalc and certainly more accurate than guessing AFR target cell by looking at the timing log.

 

your tire of reading and you only have 12posts newbie

 

I also found TTPs comment about 2Byte being training wheels as patronizing. Initially I used the timing method when tuning as no other method was available, but 2byte makes things a lot faster when you have map tracing. I still use the timing method to cross reference.

A well know tuner has posted before that 2byte is inaccurate as the loggers use a flawed calculation, at best this means they mistook 2byte for load calc, at worst they had no idea how the 2 byte load was derived.

I would like to know what is wrong with questioning another posters statements, whether the poster is a vendor or not, especially if you cab back your comments with data.

MB

 

I use logworks for tracing multiple logs in one chart. I use 2byteload and RPM for the two dimentional charts. The combination of Evoscan and Logworks has really worked for me.

I am willing to bet that the same applies here. TTP probably does not know how to do 2byteload, but rather than admit that, he simply says that it is inaccurate. I would love to see the data to prove that 2byteload is inaccurate. Since he has not provided any data to back up his claim, I think he is simply making things up.

 

The rise you are trying to extract will not be entertained. I have 2byte load on my own car and did it just for the hell of it. Still don't use it.

 

OK, fine...Then please tell us how you discovered that it is not accurate. Produce some evidence to back up your opinion.

 

^^^ ...TTP, answer please?

 

Ignorance is Bliss....

when you don't know something its just sometimes better to play it off as being unworthy to make one's self feel smart.

 

some of you are ****ing stupid period. AFR ain't everything you ****ing dumbass. You can have a perfect AFR but that doesn't mean the car isn't going to knock. Timing/knock count is the main thing. You can tune of just that.

 

^ I think one or two of us might know that AFR isn't everything, but the point is, in case you missed it, you can log everything else, except boost with just the Tactrix cable and even boost can be approximated by tuning for desiered load.

Quite why you have to use bad language to get your point across is not clear.

MB

 

Hell, you can tune just off the sound the car makes at WOT, does it mean it's going to be the best, most consistant tune that specific Evo could have? I doubt it.

 

Having "invented" 2 byte load logging (and managing to not always select the applicable load depending on the intake temp as discovered by Bez and mrfred), I also rarely use it when tuning because it doesn't add a terrible amount of value. Its real use is automatic map tracing/painting.

In the same way having started tuning before widebands were in widespread use, I am also comfortable using narrowband in some cases, recognising its limitations. I no longer tune commercially, but when I do freebies for enthusiasts, I do always use my wideband, and it becomes vital in sorting out funny intakes, but on stock intake with mild mods and known lean spool settings, I don't think the AFR would be any further off from intended than it varies between different environmental conditions or different gears.

Narrowband O2 is a sensor everyone has and can log very easily. I was thinking about patching to test for boost > 20 PSI and narrowband > 0.89 V to allow boost to continue as a save-your-***. There is of course more resolution (10 bit 0-5V) than in our logs... we could get to 5mV approx rather than the present 20mV, and I wonder how much closer nj1266 would be NB vs WB if he had these extra two bits? The conversion to voltage also depends on the ECU sensor supply rail voltage, if 5.0V and 255 FSD, then the conversion is 0.0196, however, often ECU supply rails are more like 5.05-5.10V (I need to check the Evo - anyone done it?) which would mean that the conversion is 0.02, so your values around the area of AFR we are interesting in are 0.88, 0.90, 0.92V. I use these on the Pocket PC to give easy reading.

My wideband is one of the original Techedge devices, and it is not I suspect as fast as the Innovate stuff for transients. You can set acceleration enrichment by feel, or by avoiding any excusion leaner than stoich on a narrowband during a throttle stab, but I cannot do it with my wideband.

My forthcoming DMA logging patches will have very fast logging in 2 bytes of RPM, O2, Airflow, Load and 1 byte of knock, timing, AFRMAP, MAP, IPW, TPS. There will be slower logging of other items that don't have a high rate of change. The aim is for the fast stuff to have a log at least every engine revolution. Perhaps overkill, but the patches I'm doing probably won't help my car go faster, just the challenge and "fun" of doing it, and I hope some will find them useful. Anyway, I digress, except to state that I will be putting narrowband O2 in the very fast collection as I think it has real value as a fast and universal sensor that is always on.

I would also point out to vboy425, that you can seriously overheat an engine and its ancillaries by paying only attention to knock and not to AFR. I'm sure he is aware of this and was merely trying to balance other arguments