VEMS uses the PS2 clock signal to receive 0/5V wheelspeed frequency signal. Became very popular recently.
The PS2 firmware uses the PS2 port for keyboard, and launch-RPM is time-based (not wheelspeed). For wheelspeed input to work, the "non-PS2" firmware must be uploaded ( my_make.16x14/vems.hex ). See GenBoard/UnderDevelopment/FirmwareChanges around and after 1.1.53
Use recent VemsTune.
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.
Customers are advised to request in the WebShop order note:
- PS2 clock wheelspeed input on EC18/17 (used to be 2nd WBO2 FET).
- This is standard since 2009-08-01 unless you request otherwise (in the order note).
- someone 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
- the last steps on MembersPage/GergelyLezsak/AssemblyThreePointFive show a practical layout of the zener and the pullup resistor.
- Excellent news. Anything to protect the ecu from damage saves us time and money!
With the 5V1 zener it is less likely to damage it, and an open-collector HALL sensor or a VR signal and a simple NPN inverter (same as CamHALLInverter) can be used to drive the signal (LM1815 is not necessary for this, although that would work too). Care is still needed of course.
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