| Author | Message | ||
     Mmcn49 |
I've tweaked the Buells Fuel & Timing Maps and EEPROM quite a bit, (ECMSpy and Megalog viewer). Some of the ECM changes were suggestions from friends, or from the board. Others were changes to see what would happen, (loading other maps for example). After most every change, the bike either ran better, (less vibrations, or was quicker, or both) a few changes ended with either increased vibrations or poorer performance and were dropped. Something odd happened the last time I burned the ECM. Several values on both the front and rear fuel maps will not change. Additionally the value at position TPS-100 & RPM-0 on the rear fuel map has dropped to zero and will not change. My initial guess is, is that I've probably gone beyond the limit of burning new values into the ECM/EEPROM. Does anybody have any idea of how many times you can burn the ECM? Anyone have any ideas or tricks on getting the apparently dead cells to accept new values? | ||
| Mr2shim |
I highly doubt there is a limit, given EcmSpy is not a program from Buell so they would have no reason to put a limit on an Ecm that was originally un-editable. Your burn probably got interrupted. (Message edited by mr2shim on September 05, 2008) | ||
| Froggy |
Did you burn an EEPROM from another bike or you found online? The EEPROM's are not compadible with a ECM that it wasnt made for. The values are stored in different locations in the memory from ECM to ECM. Restart from your stock EEPROM and try again. | ||
| Mmcn49 |
I had saved the original EEPROM and burned it back into the ECM this morning, (burned the EEPROM and maps). The ECM seemed to accept it and all the old map values reappeared. I loaded the latest VE corrections to the rear map, calculated and loaded the %ages for the front map and burned them. After burning, the same problem as outlined in the earlier post has reappeared. I’ve been doing all the work with an old laptop. In case there were any issues with it I brought the PC down to the shop and used it instead of the laptop. Same problem with both computers. Anyone have another suggestion? Can’t figure out what, if anything I’m doing wrong. Could the ECM have reached its limit? Thanks. | ||
| Mesozoic |
I highly doubt that the ECM has reached it's "limit," but I'd look closely at the data cable you're using as well as how well grounded everything is before you initiate a write. EEPROMs are super sensitive so any voltage fluctuation during a write can mean bad news. | ||
| Oldog |
it sounds like issue with map locations & hardware versions as stated above, the fact the stock base line map values reload fine indicates that the new values cant be accepted at the write locations the reason for my comment is that there are certain industrial devices I use in my work that have eeprom memory and some of those do have write life limits these are in the tens of thousands of cycles so even if the prom has a write life span it "should take a while" to get there | ||
| Hermit |
Try editing and burning the problem values directly from the EEPROM tab. I had problems when changing the column and row headers of the fuel table and had to edit the headers directly to correct. | ||
| Mmcn49 |
I usually use the up and down arrows to change cell values, (unless there’s a big change). On the cells that appear to be dead, the only way I can get the values to change is by typing the new value into the box by the arrows and hitting the equal sign. When I do this the cell number changes to the new value. After I burn the map and toggle the bike everything appears to be fine. However when I pull up the EEPROM, map values on those few cells never change. There is no problem with changing values on the other cells with either the up or down arrows, or box and equal sign. Will try Hermit’s suggestion and hopefully get the new values in | ||
| Mmcn49 |
Found this in wikipedia about EEPROM's. From the description it sounds like several of the cells are stuck in programmed state. It also says the that EEPROMS are good for a million reprograms. I've only made 14 or 15 map changes, and one of the cells that dropped to zero, I never touched. Failure modes There are two limitations of stored information; endurance, and data retention. During rewrites, the gate oxide in the floating-gate transistors gradually accumulates trapped electrons. The electric field of the trapped electrons adds to the electrons in the floating gate, lowering the window between threshold voltages for zeros vs ones. After sufficient number of rewrite cycles, the difference becomes too small to be recognizable, the cell is stuck in programmed state, and endurance failure occurs. The manufacturers usually specify minimal number of rewrites being 10to the 6th or more. During storage, the electrons injected into the floating gate may drift through the insulator, especially at increased temperature, and cause charge loss, reverting the cell into erased state. The manufacturers usually guarantee data retention of 10 years or more.[2] | ||
| Id073897 |
Check comm lines. Check ECM type. | ||
| Ratyson |
Mmcn49, Do you have anyone around you with another cable you could try? You could also contact the ecmspy folks too. There may be a bug that needs fixing. Every piece of software known to man has at least one bug in it. | ||
| Typeone |
You could also contact the ecmspy folks too. 'ECM Spy folk' just responded above you  | ||
| Mmcn49 |
Have checked the cable, connections, etc. If it were a cable issue why does it work on most cells but not on a few? If the ECM type was wrong, why haven't problems appeared sooner? I loaded an 07 race EEPROM in with no problems. Next I left the race fuel maps in place but loaded back the stock timing maps. I data logged with the race fuel maps, made changes and had no problem. I reloaded the stock fuel maps, data logged, made changes and again no issues. It was only after the last round of data logging that I had issues with several cells on both maps and had one cell drop to zero. This weekend I'll make the latest map changes directly to my original stored EEPROM, load the revised EEPROM into the ECM and see what happens. | ||
| Mmcn49 |
Found a BadWeb thread from last February with a dyno tuning question. Al’s response is below The only real question is whether you've run out of bandwidth in the fuel tables with the mods you have. It's an 8 bit system, when you hit a seed value of 255, you're done. Put one more in there and it is the same as a seed value of 0. There are some other constants that can be changed to override that, but they aren't currently turned on in DL. They likely will be soon. Al Question: Is the maximum cell value that can be entered into an 07 12S stock ECM 255? Megalog put several cell values higher than 255. I remember one at 258. Could this be the source of my problems? | ||
| Dmhines |
8 BITS (1111 1111) = HEX FF = 255 .. that is the max number that 8-bits can represent. | ||
| J2blue |
Can you redirect the output of your programming software to a file? If so I would do a comparison of a known good file to the problem one. You will have to use a hex editor or similar utility, and will need to know how to convert values back and forth. The other thing that you suspect is the physical EEPROM device, I would go ahead and buy a replacement and begin playing with it. It is possible to damage these devices, or for them to fail. If that is the case a replacement is needed anyway. | ||
| Slaughter |
YOU MUST BE VERY CAREFUL when you edit your tables!!! Max Value is 255 - YES, it will "take" a higher number but as Al pointed out, a value of 256 is an ACTUAL call for ZERO fuel, 257=1, 258=2, and so on...! There is nothing that PREVENTS you from entering higher numbers but it is interpreted as something you DO NOT WANT! This is where you start melting motors! (and also why you should ALWAYS do a few dyno pulls to verify air/fuel - you'd have seen this) | ||
| Id073897 |
This is where you start melting motors! This is pure FUD. As long as OL learning is enabled, nothing at all will happen to the engine. Regards, Gunter | ||
| Alex |
As long as OL learning is enabled, nothing at all will happen to the engine. Sorry, but that depends on the bike and how far off the maps are. Try to load a way to lean front map with a good rear map on a bike with only rear lambda sensor and watch parts melting in the front cylinder. Or use a map way off in WOT. 3 seconds delay time before even starting to try to correct the problem can be a hard time for an engine under heavy load. | ||
| Id073897 |
I agree with you in that the different maps for front and rear cylinder might lead into problems. But I don't agree with the other one. If adding fuel values above 255 and therefore reducing fuel to very low values, then ignitability limits will be reached and this won't harm the engine and will not melt anything. As the same situation applies in the former case too, I feel safe to state nothing will happen at all. Regards, Gunter | ||
| Slaughter |
Gunter IS absolutely right - if you run very lean, you have problems - if you STOP the fuel - or have it so lean, you'll just STOP the ignition... no fire = no heat = no melt = no power. Bottom line, keep your "numbers" below 255 to stay within range. Just check your air/fuel after changes. (Message edited by slaughter on September 12, 2008) | ||
| Mmcn49 |
Success! Thank you to everyone who offered comments & suggestions in helping me work through the map issues. Made, MegaLog value changes to the 07 stock rear fuel map, and %age changes to the stock front map via the EEPROM Tab. Every value change was loaded successfully. Can’t be certain but suspect problem was caused by several VE fuel cell values which exceeded 255. First test ride indicated big improvement. Next I applied Baplaux’s timing changes to my stock timing maps and the Buell is running great. OTHER MAPS TAB If you click on the Other Maps Tab in ECMSpy you’ll see the AFV table. The Max AFV value is 150 and the minimum is 60. I’ve experimented with changing these values and have gone on 20 mile test rides after several changes. I’ve tighten the values down to 130-70, 120-80, 110-90, 105-95. I’ve found that the bike runs noticeably better, (best) at 105-95. Questions: Which sensor am I affecting by tightening these values? Is it the Air Sensor, 02 sensor, (probably not) or both? All my test rides after tightening the AFV range were probably between 70 to 700 feet in elevation. At these low altitudes the bike ran better. Will tightening the AFV range to 105-95 affect the ECM’s ability to compensate for altitude change at higher elevations? I’m going for a several hundred mile ride tomorrow which will probably climb to 2000-2500 feet. Because I’m uncertain of how tightening the AFV range to 105-95 will affect the bike at higher elevations, I reset the AFV back to 150-60. After resetting the AFV to 150-60, I took another test ride. Within 9 or 10 miles the AFV went from 100% to 94.6%. The bike still ran well, but not quite as good as when it was at the tighter range. After resetting AFV to 100% the bike ran great again. Hopefully it will stay but somehow I don’t think it will. | ||
| Moosestang |
I’ve tighten the values down to 130-70, 120-80, 110-90, 105-95. I’ve found that the bike runs noticeably better, (best) at 105-95. Questions: Which sensor am I affecting by tightening these values? Is it the Air Sensor, 02 sensor, (probably not) or both? Bump! I'd like to know about that as well. |
