Changes by last author:
Changed:
| * firmware 1.0.19 (in BMW) for sure ? |
|
* firmware 1.0.19 (in BMW) for sure ?
Yes, installed in summer/autumn 2005. You know, if it works don't fix it :). |
| in Toyota we have... |
| in Toyota we have -> read now, had. |
|
Trigger wheel was little bit too small, for the OEM sensor - which caused triggering errors in higher revolutions. Lasercut slightly larger 215 mm wheel. To someone reading this in distant future. One might to try Toyota oem VR sensor with Toyota oem (32 + 4 type) wheel mounted under crankshaft front pulley with future VEMS firmware version. We tried it with firmware 1.1.23, but the wheel type was unsupported (or at least did not work). |
|
Next trigger tooth = 30 (NOT 35 !!!)
Crank min period 1808 usec (you can safely use 0) |
|
Next trigger tooth = 30
Crank min period 0 usec |
| Filtering disabled. |
|
Filtering and Advanced filtering was tried enabled and disabled -> it didn't help, but tooth normal/missing relative minimum and maximum didn't tried to change. Values are 'by the Megatune F1 help'.
Tooth Normal Relative min% 31 Tooth Normal Relative max% 144 |
| VR sensor polarity is checked (how?), also signal and its shape is good. Checked polarity by moving mild steel plate towards the sensor and continuing moving piece away from it. |
|
Tooth Missing Relative min% 213
Tooth Missing Relative max% 388 VR sensor polarity is checked (how?), also signal and its shape is good. |
|
Correct VR sensor connection (polarity);
DVM reads positive voltage when plate comes to sensor tip and negative voltage when plate was moved away from tip. |
|
Any idea ?
Should we change sensor, solder/change some ecu components or try some setting values ? |
| Yes, the VR sensor voltage was 0.15 volt positive biased because of too small trgger wheel. Actually tooth/space ratio too small. |
| Could somebody check our tooth_twidths and other triggering/filtering etc. related settings. |
| Our settings (for the inline 4, firing 1,3,4,2 (coil on plug's in dual out mode). |
| COP's wired wastespark mode, physical connection |
|
COP's wired wastespark mode (Ign_Dualout)
physical connection |
| (but fill in 4 entries in h[1] and h[2]) |
| Made # comment to config line, which meaning/correctness is somewhat suspicious (or at least unknown to us). |
| # DISABLE FILTERING !!! Only advanced filtering is allowed for multitooth |
|
primary_trigger=01 # Multitooth without filtering
# primary_trigger=09 # Advaced filtering # DISABLED FILTERING !!! Only advanced filtering is allowed for multitooth |
| primary_trigger=09 |
| ign_out=70 # Dual_out is not in use, is value OK ? |
| ign_out=70 # Dual_out is used |
|
h[0]=02 08 04 01 00 00 5D 6A
h[1]=1E 00 1E 00 E3 B7 00 00 h[2]=30 20 00 00 00 00 00 00 |
|
h[0]=02 08 04 01 00 00 00 00
h[1]=1E 00 1E 00 00 00 00 00 h[2]=30 20 30 20 00 00 00 00 |
|
Other problem is that Megatune somewhat messes some settings and values in h(0), h(1) and h(2) table -> so made them by hand and downloaded separately.
in h(0) table four leftmost is used, zeroed others by hand and uploaded tables to ecu. Started Megatune opened h(1) table setting page and sent to ecu. Values 5D and 6A appeared mystically. Same happened in h(1) (E3, B7 values) Also... When downloaded tables from ECU -> to tables.txt file, made edits with Notepad and did generate config with generate_config12x12.bat Warning: table t has less than 8 items Looked our tables.txt (which in a first place was downloaded from ecu), only to find that it did not contain t() table at all. global.h (version 1.1.18) was in same directory root /firmware/ folder -> verified it's version and location against config.bat. |
| Beware that.. Megatune could mess some settings and values in h(0), h(1) and h(2) table -> so make these by hand and download separately. |
| in h(0), h(1) and h(2) table four leftmost placeholders are used. |