[talladam]

I'm curious, can a tune become corrupt on its own? Reason I ask is my car occasionally would act like the spark dropped for a millisecond, and then everything would be fine. The closest I can describe it is imagine no fuel going to the motor and the throttle is 1/2 open while doing 55, just seems to loose all rpm/life for a second.

Well last week the car felt like it lost all spark for a second and a few moments later I down shifted to 4th gear for traffic ahead. When I gave it more gas, the car felt like it was sucking all air and no fuel as described above. I pulled over and shut off the car, put the tweecer to position 5 (stock tune) and started it back up. The car drove 100% after that, even put 25 miles on it without a single hiccup whatsoever. I haven't had a chance to drive the car since or to load a new tune since I'm painting the pony rims white and getting tires mounted.

My tune only consisted of a read of my a9m ecu with compensation for idle, and slight timing adjustments for 4deg global and 2 deg at 4500-6500 rpm, 95 maf transfer, no egr or pollution, disabled check engine light and possible speed limiter removal.

[cgrey8]

I have no clue what the answer is on that, but recently, sailorbob told me about a feature in TunerPro that compares BIN files to find any differences in them at the BYTE level, not just a compare of known things in the tune the way BE/CalEdit do. It found over a dozen different things that were different that I couldn't have knowingly changed because they are in spaces of the tune that currently aren't mapped/known.

What I did was reverted to an X3Z and manually moved over all the things I knew needed to be moved. Now my tune has ONLY known things changed when I do the compare. I was so impressed with the TunerPro feature, I told Clint about it and he whipped out a Bin Compare into Binary Editor AND improved on TunerPro's implementation of it as well. So if you have your tune in BIN format, update BE and run the "Difference" tool on your BIN compared to whatever BIN you started with to see if there are any "unknown" differences.

[Cougar5.0]

I have no clue what the answer is on that, but recently, sailorbob told me about a feature in TunerPro that compares BIN files to find any differences in them at the BYTE level, not just a compare of known things in the tune the way BE/CalEdit do. It found over a dozen different things that were different that I couldn't have knowingly changed because they are in spaces of the tune that currently aren't mapped/known.

What I did was reverted to an X3Z and manually moved over all the things I knew needed to be moved. Now my tune has ONLY known things changed when I do the compare. I was so impressed with the TunerPro feature, I told Clint about it and he whipped out a Bin Compare into Binary Editor AND improved on TunerPro's implementation of it as well. So if you have your tune in BIN format, update BE and run the "Difference" tool on your BIN compared to whatever BIN you started with to see if there are any "unknown" differences.

Wow, thanks for nudging Clint to get that implemented in BE - that was one feature in TunerPro that was very useful - especially when strange things started happening. I have also done the "start from ground zero" thing based on these unmapped changes.

[Cougar5.0]

Wierd - TunerPro has:
586B Checksum Base Address - ROM1 0 20

BE has:
586B Unknown 0 32

There is a recommendation to set the Checksum Base Address to "0" - I wonder if this matters?

[86GT]

The BE will display the values in decimal format. Leaving things in hex means nothing to most people. The BE will also display the differences in their scaled values if they are defined in the definition file.

If you find a difference while in the BE, you can open the binary explorer and modify whatever you need to. This will allow you to get the binary back to a good know state. When exiting the Binary explorer it will ask you if you want to commit the changes to the in memory copy of the binary. When you are done making changes to the defined parameter and or manual edits using the binary explorer you will need to save the binary.

[Cougar5.0]

Thanks Clint for the explanation. Actually, my concern wasn't whether the values were in hex or not - I understand that difference :)

I was wondering if the Checksum Base Address should be defined in BE :D

[Cougar5.0]

Hey Clint - couple of new issues with BE.

1. If I hit "Diff" after reading the ECU & saving the file (to do a compare of what's in there to the file), BE almost always locks up.

2. If I try to read the ECU after having used BE for datalogging, but since shut off and turned the key to "on" position, the "Read" button is still dehighlighted and the only way to reactivate it is to restart BE.

Karl

[86GT]

I will take a look at both of these

[89ragtopgt]

The BE will display the values in decimal format. Leaving things in hex means nothing to most people. The BE will also display the differences in their scaled values if they are defined in the definition file.

If you find a difference while in the BE, you can open the binary explorer and modify whatever you need to. This will allow you to get the binary back to a good know state. When exiting the Binary explorer it will ask you if you want to commit the changes to the in memory copy of the binary. When you are done making changes to the defined parameter and or manual edits using the binary explorer you will need to save the binary.

ok I used this tool to check my tune and found a bunch of corrupt data in the tune........ so what causes this? could copy paste functions screw this up? looks like i will be making a tune from scratch again. i will check the bin after every change to see what is corrupting the tune..... or is reading the data from tweecer and then editing and writing it back doing this???
ok started on the scalars
this:
ROM1 System - Checksum Base Address 0 8192 Integer
caused this corrupt bytes
586B Unknown 0 32
caused it to show a 0 and the factory is 32.....................................

[89ragtopgt]

ok one more question now that i have redid my tune from scratch the only problem i see is the above bytes. now if i data log, load this tune along with the data log options will this get loaded into the tune bin? if so then when i read it back and compare with b.e it will show the bytes as being corrupt but is actually is the data for datalogging? can we map this data and have it show up in be as logging data so i know what and where it is in the bin file? or am i way out to lunch here....

[86GT]

You should be able to do exactly what you described. Cougar50 has stated that there is an error in the BE that messes up when you read back the tune and then try the diff tool. I have not had a chance to look into this yet.

You can read the tune back and the save it as something like test1. Then close and reopen the BE and try the diff tool.

[89ragtopgt]

You should be able to do exactly what you described. Cougar50 has stated that there is an error in the BE that messes up when you read back the tune and then try the diff tool. I have not had a chance to look into this yet.

You can read the tune back and the save it as something like test1. Then close and reopen the BE and try the diff tool.

when i select datalogging and download the tune ... where does the datalog info date get stored?

[86GT]

The datalog info is placed into the binary as it is downloaded to the tweecer. So to answer the question, yes when you read the tune back you will see a bunch of bytes different.

[89ragtopgt]

sorry for being such an idiot :? but i curious why the datalog data is right in middle of the code, when there is a ton of free space at the end of the eeprom? is this overwriting critical data in the bin used for operation of the eec? or does it need to be there to intercept the data being fed to the cpu?

[86GT]

Te first part of the code tells the eec what and how to do it. This is kind of like the BIOS in your PC. The middle part of the code is the calibration data. This is the idle setpoint, fan setpoint and so forth. The last part of the code is for the calibration console that ford uses to monitor data while it was on the engine dyno. This calibration console is disabled when ford is done with the tune.

We basically re enable the calibration console and use it for datalogging.

[86GT]

Hey Clint - couple of new issues with BE.

1. If I hit "Diff" after reading the ECU & saving the file (to do a compare of what's in there to the file), BE almost always locks up.

2. If I try to read the ECU after having used BE for datalogging, but since shut off and turned the key to "on" position, the "Read" button is still dehighlighted and the only way to reactivate it is to restart BE.

Karl

I think i have both of these fixed.

[talladam]

I think I found my solution. I was finally able to calculate my throttle body airflow. I datalogged my engine when hot with the iac unplugged. I averaged 725rpm over 45 seconds with an average voltage of .74
I found that .75v = 19.96 or 19.699 kg/hr translated to .74 lb/min....I entered that into the TB Air Scalar. I found the kg/hr translation in the mass air transfer section of BE.

Forumla I used http://forums.stangnet.com/archive/inde ... 91948.html

I drove the car down the street some (country roads). No hiccups on some 1-3 WOT runs. Laptop battery died after getting home. Drove to work today without any hiccups or issues. I plan on punishing it a little on the way home tonight...probably some short distance stop light olympics.

Adam

[2Shaker]

Adam,

Where is Monroeville I'm near Dayton.

[talladam]

A few hours north and slightly east. 25 minutes from Cedar Point.

http://maps.google.com/maps?f=d&hl=en&g ... 8&z=9&om=1

[vtecwho]

talladam, how did you stop that cutting out problem.

i seem to be having a similar problem. eversince i have been tuning, every now and then the car will seem like i hit a fuel cutt off (my fuel cut off is not at 2200 rpm, i have checked).

call me crazy but it seems to happen more when i hit bumps in the road! my battery is secure too.

when this happend the first time i had just adjusted my TB air flow and that whole idle thing. i was driving and my car 100% cut out down a hill! i pulled over and tryed to start it but it would just crank. i switched back to stock tune and ran like it did before, kinda crapy, but it got me home. i was dataloging at the time and i saved that tune that made me stall. i read that particular tune and pulled the values up in the scarlars and found almose all values were OFF THE WALL. some were riddiculously high and some were just not there at all! i know i did not do that, it seems like it happen on its own!

what the hell is happening! hahaha

[cgrey8]

Try to get a datalog of this happening. As soon as it happens, stop the datalog so you know within a few lines of where to look in the capture. What you are looking for are any abnormalities in readings. To gauge what's happening, it may also be important to have as many different, unrelated things being datalogged at the same time. So for instance, if you are datalogging all the Bank2 data, remove the Bank2 from your payload, and instead, capture this (assuming you are using BinaryEditor):

1. ACT (which also gets ECT)
2. RPM
3. Spark
4. PW1
5. KAMRF1
6. LAMBSE1
7. HEGO1 or EVP if you have a WB wired into the EVP input of the EEC
8. Load (not Load%)
9. MAF or MAFv (preferably MAF just so you can see at a glance if something gets logged obviously wrong)
10. MPH
11. VBAT
12. ISC (Idle Speed Controller)
13. TPS (Throttle Position Sensor)
14. TS (Throttle Status which includes CT/PT indication)
15. FLAGS1
16. FLAGS2

With all that datalogged, if your VBAT dips, your MAF flutters, LAMBSEs go rich/lean, PW1 cuts out, HEGO/WB goes super Rich/Lean, you'll hopefully get a hint as to what caused the hiccup. If it doesn't help you find the problem, at least you can make some pseudo-safe assumptions about what the problem isn't...

[vtecwho]

cgrey8,
thanks for the suggestions, i will do that and see whats going on. i know things like this are hard to trouble shoot because it may not be mechanical, so thanks for the info.
eric

[talladam]

I changed spark plugs which seems to have cleared most of it up. I drove the car twice since changing plugs. I took it out Sunday with my brother and a friend in the car. On the way home it acted like the TPS was unhooked when I hit the gas, split second later it is ripping tire up in second gear. I need to try what cgrey8 said.

Adam

[cgrey8]

If it's hesitating right AT tip-in, but comes alive just as soon as you quit moving the throttle, you might want to try increasing the Accel Fuel multiplier. Stock A9L has it around .39 I think. Raise it on up to about .5 and see if that has any effect. If it helps, then you can get finer control on tip-in enrichment by going to the Accel Enrichment Table and adjust specific parts of the enrichment (i.e. add more enrichment to aggressive tip-ins while leaving lighter tip-ins alone).

Another possibility is if you have increased the diameter of your TB, then you are getting more inrush of air for the same TB position movement than the computer expects. But this usually affect smaller TB movements rather than larger ones.

[Cougar5.0]

My tune has been "uncorrupting" over time. My KAMRF's have drifted to 1.00 over time and barely deviate from that during normal cruising. I did have to up the accel multiplier recently but this was due to me installing a dial type of AFR gauge. After tip in the gauge was swinging to the right (somewhat lean) & now I can obcess over it even though it doesn't matter that much if it undershoots once the tip-in is over since the load is now steady-state again.

[cgrey8]

...& now I can obcess over it even though it doesn't matter that much...

I'm jealous. I need a WB, so I'll have new things to obsess over.

[talladam]

cgrey, I have compensated for the larger TB with the tweecer so I'll have to get the tip-in adjustment a go. Also, off topic....how do you like your TRE fuel pump?

Adam

[cgrey8]

So far so good. It's much quieter than the stock pump and fits right in where the stock pump was.

[Jimmies]

I've had an interesting tune corruption myself. To get my car to idle, I have to learn my MAF a little at idle voltages. (I've already leaned my low slope to 67)

If I drive my car for an hour or so, the idle will drop way way lean, and if I goose the throttle it returns to normal and idles fine. Bizarre.

[Jack Hidley]

I guess this is sort of a BE feature request.

Over the past couple of years of using the Tweecer, I've run into this problem where the bin file becomes corrupted. As Clint has pointed out in another thread, there is no error checking in the computer to Tweecer interface. I believe that this causes the bin files to become corrupted. From my experience it always does this at the worst possible time.

On our track car, this has caused us to competely stop using the Tweecer.

Here is the feature request. It would be great if in BE, you could check a box that was a write/read/then compare. So whenever you wrote a bin file to the Tweecer, BE would automatically execute a read cycle afterwards, then a compare. If it found any differences, it would automatically do the write/read/compare over again. I think this would keep the bin files from ever getting corrupted in the first place.