- Lambda protection/Lean power(soft ignition cut with following conditions)
- MIN RPM, MIN MAP, MIN TPS, LAMBDA THRESHOLD, LATENCY
- configurable dwell settings(for dummy ignition)
- (cranking, running and minimum discharge period) with duty cycle settings
- Predefinied settings ("configlets") for some hardware components like ETC, Knock sensing and other
This can be done by anyone, and actually welcome (it is config, configlets, small pieces of text, even possible to add to VemsTune ini files). Recommend some setting (starts with project pages and notes about the actual setup, and config), and we can add some easy to select "configlets" to VemsTune default release
- hopefully users still read the awesome detailed documentation about ETC, knock sensing (because even with some default values, it is required to understand the operation).
- output for digital speedometer (you mean wheelspeed?). RPM and wheelspeed is already sent 3+ ways, eg. to VemsTune and via AIM stream (that can be sent to arbitrary number of devices simultaneously)
- BroadcastDatastreamAim
- BroadcastDatastreamAimSecondSerial
- VemsTune communications, directly connected, or even via LAN or wireless or WAN (including VPN or other tunnels)
- OverTCPWireless
- OverTCPWifiModule
- realtime data can be sent to arbitrary number of devices simultaneously (only 1 VemsTune can change config or be used for tuning at any one time)
- cruise control
- better protection for Inputs and outputs against to short circuits and alien voltage
- despite warnings here and there, mcp3208 inputs are actually have good onboard protected since v3.8 (previously it was optional, and sometimes implemented, but not always). CLT, MAT, TPS, Trigger and other inputs have been well protected since the very start. Stepper output protection is an option ("protected stepper... used for logiclevel ignout for active coils). Other outputs must be protected via fuse. More protection could certainly be applied, except encouraging installers to make even bigger "shortcuts" and nastier installs.
- A sane install is already extremely reliable; A sloppy install is unlikely to turn out good even if we encourage it.
- two way bluetooth communication, virtual buttons on table/phone (for launch control activation, ALS, possibly change boost targets later, it needs more options)
- ALS, launch activation can be done from dedicated input.
While phones/tablets are good for display, it is highly encouraged to use very reliable dedicated controls for ALS and Launch activation. It might not be a good idea (and a support nightmare) to use unknown quality phones/tablets (with unknown quality HW, OS, libraries, other applications, BT HW, BT stack, spyware) and an attack vector from those devices (with unknown number of manufacturer, echelon and third party backdoors and vulnerabilities) is also undesired. Needs evaluation.
- vemsdisplay gauge can be set to fast red blinking for warning sign
- New firmware for new board
- with faster cpu speed, can be changed in the software trigger(VR/hall) and ignition output(IGBT/logic)
- more user friendly WIKI page ... yes, desired (new tiki.org seems good, right?)
OK?)