VEMS uses the PS2 clock signal to receive 0/5V wheelspeed frequency signal.
Therefore the non-PS2 firmware must be used ( my_make.16x14/vems.hex ). See GenBoard/UnderDevelopment/FirmwareChanges around and after 1.1.53
VemsTune 2009-04-24 does not have the launch-table yet. We used [vemsTune-v3-1.1.53.ini.zip] file. Use more recent vemstune if [available].
Sensitive pin
PS2 clock input is a direct CPU pin. It is very sensitive. Either static electricity or 12V will damage the main processor immediately.
Therefore many users request in the WebShop order note:
- PS2 clock wheelspeed input on EC18/17 instead of 2nd WBO2 FET.
- I have been using EC18/17 for sensor ground (easy COMM and additional input wiring) and using EC18/8 for the Speed Input.
- 4k7 pullup to +5V
- 4k7 and 5V1 zener protection on the processor pin
- Excellent news. Anything to protect the ecu from damage saves us time and money!
This way it is less likely to damage it, and an open-collector HALL sensor or a VR signal and a simple NPN inverter can be used to drive the signal (LM1815 is not necessary for this, although that would work too). Care is still needed of course.
- May I see a diagram of the NPN Inverter? KevinBlack
- Please? :)
Wheelspeed data usage
- logging wheelspeed to notebook, or SDcard
- sending to AfreshTiny/AimDisplay for well-visible display
- boostcontrol - gear dependent boost
- launchcontrol - wheelspeed dependent rpm-limit
Launchcontrol
The good old initial launch behaviour with retard and launch-enrichment is still there.
But after reaching the first entry in an 8 entry table (array), no retard, no enrichment:
2x8 bytes for wheelspeed => RPMlimit. Firmware uses interpolation for smooth transitions between table-points.
RPMlimit is in 100 RPM unit.
wheelspeed is the unit of your choice. Usually:
- km/h
- or mph
- or any other. It really just depends on calibration
The same table is time => RPMlimit for the PS2 firmware where wheelspeed is not available. Time is in 64 msec unit.
The first and last bin in the table are somewhat special:
- Before the first entry is reached, the good old one-value RPMlimit set in config is used and retard and enrichment is applied
"Launch RPM vs Road Speed" screen:
Kevin's note: I have the table/curve in the MegaTune(works in Megatune but not tested on engine yet)
You'll note in the main menu and the [ini] that I have changed many of the titles and have organized the functions differently.
Note: the "launch-active" flag in VemsTune only lights up when the RPM-limit is reached (not when the button is pressed - this can be confusing). So if you want to test an analog input switchbutton, configure the ALS input to that pin to see that it lights up.
Temporary note - for .ini file tweakers.
This section should be cleaned up when these are deployed in both MegaTune and VemsTune 2009-05-xx releases.
Direct commands for page15 (launchcontrol wheelspeed=>launchRPMlimit) read/write are [] brackets.
- Offset 0..7 are RPM (unit=100 RPM)
- offset 8..15 is the wheelspeed (unit of your choice, depends on calibration)
Check the mct dump to see if s[0]= and s[1]=... values are set as you expect.
REST OF THE PAGE IS BRAINSTORMING
Freq to voltage - could also be used
[LM2917] frequency to voltage converter to get wheelspeed info on the LCD and for logging.
The app note even has a design almost ready for use
Is anyone besides me interested in this?
Is there any problem with this solution that I am missing? //Emil