_______ 
 |__   __|
    | |   
    | |   
    | |   
    |_|   
          
          

         
 ##      
 ##      
 ## ##   
 ####    
 ## ##   
 ##  ##  
         

 __     __
 \ \   / /
  \ \_/ / 
   \   /  
    | |   
    |_|   
          
          

______ 
| ___ \
| |_/ /
|    / 
| |\ \ 
\_| \_|
       
       

  _   _ 
 | \ | |
 |  \| |
 | . ` |
 | |\  |
 |_| \_|
        
        

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. '''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 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? ---- '''Tacho Output''' Should have been simple, BUT * the tacho in the TVR originally took its output from the "-ve" terminal of the old coil. Guess this means the 0V input that jumps to 350V or above * I don't have any IGBT channels to spare ** There's not quite enough drive from P259 to solve this (did you actually try it? 10..220uH could work with a 47..100..270 Ohm protecting resistor - we should calc the avalanche energy stress of the p259 internal flyback and check against datasheet) * so I need to think a bit more... Probably going to make a tacho driver circuit ** if you find that the p259 output clamp voltage (50V or similar) is too low (which I doubt) for the gauge input, you can try to use a small signal transformer (something from an old radio could work) to get higher output voltage on the secondary to drive the demanding (;-) RPM gauge. ---- '''Evaporative Emissions Control''' - EvaporatorCanister I ought to be a good boy and sort this out properly. I've ignored it up to now, and I really shouldn't... The vent pipe from the fuel tank goes to a carbon canister in the inner wing (not examined yet, I disconnected the system at the tank end). Another pipe comes from this to the plenum on the engine. Presumably the carbon canister is also vented to atmosphere with a non-return valve, i.e. it can suck air in, but not let it and the petrol fumes out. 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: * at warm WBO2 sensor ** I thought when the CLT reaches the highest bin (the 71 degree one) would be adiquate. No config variable needed... * one would think low RPM & low MAP, but the other way around 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. ** High load makes less sense when you consider "granny cycle" operation - ie the car does a few short journeys to the shops and not at high loads. * as an experiment, try to enable with a misc output from 40..70kPa (only at RPM<3000 first) and see how lambda changes. ** Good idea. Will do this when I get the radiator back. (Long story which has made me angry.) Question: How best do I drive the purge solenoid with VEMS. I thought about a Misc output channel, but there's no temperature dependance on it. Am I understanding this correctly? 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). '''Detailed Proposal - to be expanded''' * Enabled when the CLT is in the top bin - ie above 71 degrees C. * Fixed frequency of 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 * Independant of RPM. Is this valid? I think so at the moment. 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 * Frequency adjust I've been away for a while. Is there any progress on this in the firmware yet? * purge evaporator ? no * dual WBO2 ? not yet. But backport from round seems easy. Though we need to tune for the NTK sensor first (more and more frequent nowadays). ---- '''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. '''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.