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
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.
- 4k7 pullup to +5V
- 4k7 and 5V1 zener protection on the processor pin
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
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
- Should I change the first bin (from 0 to 5 kph) in order to not interfere with the Launch Control Retard? KevinBlack
- after the last bin, launch is disabled and not active any longer.
"Launch RPM vs Road Speed" screen:
Kevin's note: I have the table/curve in the MegaTune now and it seems to work.
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