#### ## ##### ## ## ## ## ### ##
_ _ | | | | | | | | | | | | | |_| | \___/
|\ /| ( \ / ) \ (_) / \ / ) ( | | \_/
##### ## ## ## ## ##### ## ##
## ## ####### ####### ## # ## ## ##
IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now. Visit Preferences to set your user name Summary of change: Not just about testing fans any more, so the page will be renamed to something like "Ancilliary Output Testing"... '''Ancilliary Output Testing''' A page about all the fun I've had making VEMS drive the ancilliary stuff you need to run an engine (and know what it's doing) *Fans *Fuel pump *LCD *OE tacho gauge [etc...] '''Testing the Fan Control''' I'd very much like to get rid of the silly otter switch arrangement that drives the fans. There are 2 fans on the later Griffs. My current plan is to control them independantly from the fan and water pump controls from VEMS, with different on temperatures and different levels of hysteresis. Temperature control is very important in a fibreglass car - because fibreglass is such a good insulator. TVR used a 75 degree thermostat to get around this, but it was fixing the symptoms not the problem. I have installed a huge ratiator, proper 85 degree stat and will have staged fan controls. Well, after an exhausting search for the coil wires on the fan relays (they went into the engine bay and came out again...) I plugged them in to VEMS, set the temperatures and they worked. First time too - most impressive. Temperature control is very stable once the car is warm. There is a dip just as the stat opens when it is warming up (nothing I can do about this). Even sat in traffic, I very rarely see anything above 98C. In free flowing traffic it sits at about 85C. Exactly where it should. [Add graph of temperature control from Megatune] * I noticed the relays have diodes built into them. Nice and easy! ** what type of relays ? Most relays don't have flyback diode inside *** They're a Lucas/Bosch 5 terminal relay used on the TVR and Range Rover. The diode is (obviously) across the coil terminals. The original ECU needed the diodes or it sulked in a fairly major way! Will look up the part number and post it here. ---- '''Fuel pump''' Fuel pump relay has been connected. I'm using EC36 pin15 - P259 channel 5. I'm using 3.5 seconds for initial prime and it continues for a second after the engine stops. Both parameters unscientifically measured from the previous ECU. It's often a good idea to use free injector outputs (If you still have some free) first (more rigid) before using up p259 outputs. Measure resistance of relays (and inductivity too if your DVM supports L measurement). I have 8 injectors running sequentially so there's none spare. I've used the same relay as the fans have (ie those with added diode) so I have at least the illusion of protection for P259. '''Q:''' I have found a "funny" with the fuel pump. When I have the ECU switched on (with the car not running) and I turn on the headlamps, the fuel pump will run for a second or so (the time appears to be the "fuel pump off after x seconds" parameter in Megatune). When I turn the lights off again, the pump sometimes does the same. If the fuses are removed from the power side of the lights, then the problem doesn't happen. I have sorted out the grounding of the ECU such that the sensors are grounded to the engine and the power to the -ve terminal (previously everything went to the -ve terminal) and the problem persists. I think the only cause could be the huge inrush current caused by turning on the headlights. They draw something like 10A normally, so inrush is huge... The question is, how is this affecting VEMS and causing it to think the engine has stopped? '''A''': It seems you headlights lift ground level slightly during switchon, a single trigger will turn on the fuelpump for at least "fuel pump off after x seconds time" when the ecu sees a trigger event (even without wheel in sync) it prepares the engine for running (turning on fuel pump etc), nothing to worry about - DB ---- '''Tacho Output''' Should have been simple, BUT * the tacho in the TVR originally took its output from the "-ve" terminal of the old coil. This means the input can jump to 200V or above and can be tricky to drive this via an ECU. * I don't have any IGBT channels to spare... Used all 8 on my coils. ** There's not enough drive from P259 to solve this - the necessary inductive loading would fry it all too easily. ** You can buy tacho adaptors to solve this exact problem - AutoMeter and MSD both make them. Of course I won't be doing this as where would the fun be then? ;) ** The P256 simply isn't cut out to deal with inductive loads, so I have used an external transistor that will work with the an inductor/resistor pullup combination to drive the tacho. This may be integrated inside the tacho in due course as the tacho damping is playing up and it needs to be taken apart anyway... ---- '''Evaporative Emissions Control''' - EvaporatorCanister The vent pipe from the fuel tank goes to a carbon canister in the inner wing. Another pipe comes from this to the plenum on the engine. Under certain conditions a solenoid is pulsed to evacuate the carbon canister of any fuel vapour it's collected (into the intake manifold for digestion inside the engine). Guessing the conditions: * When the engine is warm - I thought when the CLT reaches the highest bin (the 71 degree one) would be adiquate. * Between 1500ish and 4500ish RPM, any MAP less than 75 kPa. (Can use the existing config variables here) ** Mid RPM & Mid MAP. (High RPM and MAP also makes sense: at high injector pulsewidth the extra fuel matters less.) Most factory engines use NBO2 and they might restrict the solenoid to closed-loop operation and change solenoid duty slowly so EGO-correction can catch up. With WBO2 and closed loop at high load, it should be much easier. ** Shouldn't vent at idle. This may well cause emissions testing problems. * Fixed frequency of solenoid operation (slow - say 10 Hz) Does this need to be adjustable in config? I think not at the moment. * Duty cycle proportional to MAP. ie so approximately the same volume of air will be sucked through the can at each purge operation. Needs proportion config constant. * Will need start and stop config parameters for MAP So proposed config parameters for the evap_duty(MAP) function are: * purge_evaporator_channel - output selection * min MAP. fuelcut_min_kpa + 8 kPa (not exactly same to make it easier to tell from log which should be checked, if there is stumbling or something). * mid MAP: purge_evaporator_midmap the duty function would reach max (pinned at 60..70 %) duty at this point. Eg. with fuelcut_min_kpa=14kPa and purge_evaporator_midmap=60 kPa ** 0% at 22kPa ** 70% (max duty for the whole range) at 60 kPa ** 0% again at or above 98 kPa (60-22 + 60 ) Obviosly, interpolation in between. This would result in smooth transitions (less chance of stumble or similar), while preventing blow out (pressurize the tank ??) through the purge canister at boost (unless someone specifically configures so). Config parameters I'd like, but are not essential are: * CLT bin to start purge ** the highest CLT bin could be fine, unless ... (is cold purging required for some setups? Swedish "granny cycle" ?) * RPM start/stop ---- * as an experiment, try to enable with a misc output from 40..70kPa (only at RPM<3000 first) and see how lambda changes. ** Tried this - resulted in me not seeing anything - the changes in fuelling were swamped by the effective noise caused by having really dreadful injectors. These have now been changed so I will have another go! This should save me a bit of cash in summer - a black car gets very hot and no doubt lots of fuel evaporates... ;) Evaporating hydrocarbons and not burning them is just wasteful anyway. Marcell's engine should have EvaporatorCanister connected too (especially with the warm seasons coming), just have to find the evaporator in the engine bay (IIRC I found earlier). ---- '''LCD Issue''' Just picked up a little LCD problem. It works for the most part, but sometimes just stops displaying anything (backlight stays on). It then periodically works, but partially displays gibberish. If I turn the car off and on again, it always works properly again. I've checked the wiring, and that looks to be OK. * are you sure that contrast is wired right, without contact problems (not a suspect, when it displays gibberish, though) **Should be wired OK.** * what is the length of cable ? **Approximately 1 metre * what is lcd cablelength delay in configuration ? ** Set to 2,2 (and tried 3,3 with no change in results) * what is lcd_c0 configuration item ? lcd busypoll turned on? (try 0xFF) ** Already set to FF * does mli (lcd initialization) command fixes it ? ** Yes, mli fixes it every time. Seen a similar thing on MembersPage/PhatBob. I have replaced the wire with something that's shielded a bit better and the LCD is much better, but not perfect yet. '''Q:''' The LCD problem has been narrowed down to a problem with the fans - when either fan starts or stops, the LCD problem happens. This is regardless of how well shielded the cable is. An MLI command always fixes it. So the noise is either injected into the * data (not much to do) * or to supply => a cap (220nF .. 10uF) on the LCD (between pin1 and 2) might fix it. We could maybe make some firmware change so reinit happens often, automatically. New firmware (.36) has completely cured this problem. It now never happens. '''LCD Parameters from Config''' <code> lcd_c0=FF lcd_delay=22 lcd_backlight=FF lcd_offs[0]=FF lcd_offs[1]=FF lcd_offs[2]=FF lcd_offs[3]=FF lcd_default_view=00 </code> ---- Back to MembersPage/DavidBlades Optional: Add document to category: Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.