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

  ______ 
 |  ____|
 | |__   
 |  __|  
 | |____ 
 |______|
         
         

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

  ____  
 |  _ \ 
 | |_) |
 |  __/ 
 |_|    
        

  _____ 
 | ____|
 |  _|  
 | |___ 
 |_____|
        

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:
'''Fitting sensors''' *The car already has usable CLT and TPS sensors. *There's a connection on the plenum all ready for MAP *Have installed a Jaguar XJS IAT sensor *I have removed the old MAF sensor - replaced with drainpipe! The old MAF sensors are difficult to buy now, so it can be sold to pay for more interesting VEMS developments... Note to self: Don't use drainpipe - it melts into interesting shapes.... Now replaced with aluminium tubing. It looks much better. *Old narrowband sensors are not good as they are titania type and too expensive - they have been replaced with a pair of LSU widebands (one not in use, so is really a dead NB sensor.) ---- '''Testing the Sensors''' ---- '''21/5/2012 - Wheel speed sensor''' I have finally got around to making use of the wheel speed sensor. It is being used to control the electric power steering assistance and also being passed to the VEMS ECU for logging. I have used an AVR tiny45 to provide a frequency shifter for the EPAS system, and passed the speed signal through an amplifier and protection diode etc to the ECU. My problem is that the ECU gets confused when the speed signal is greater than 1096 Hz. This is about 55km/h on my car, so not all that useful. Is this a known limit for the speed signal? (Note that the divider logic is not a useful fix to this because it divides after the counter) If so, I'll produce an additional frequency shifted output for the ECU from the AVR chip. Thanks ---- I've bench tested the NTC sensors and they work in pots of water at varying temperatures. Here's a picture of my "lab" (kitchen) http://www.aqyz05.dsl.pipex.com/tvr/sensor_cal_sml.jpg I need to add a IAT sensor to the plenum somewhere. Found one in a scrappy for £1. It works nicely. Here's a shot of it installed in the plenum. http://www.aqyz05.dsl.pipex.com/tvr/iat.jpg Coolant and IAT sensor tables have been calibrated manually. For some reason EasyTherm always produced the wrong answers * and most often produced non-monotonic curves => non-monotonous is clearly wrong for any NTC curve; it likely fitted a wrong parabola ( so I chose not to use it.) ** none of the precompiled propertherm values was sufficient for your sensor ? hexpatch should be easy to use with them '''AREF for my Genboard is wrong - Fixing it''' The value for AREF was wrong, so I fixed it using instructions on BuildProcedures/SectionThree. '''Q:''' However in doing so I clumsily disturbed capacitor C5, so had to replace it. Should it be 0.22uF? (Or does it not really matter?) ** yes, 220nF originally (but as you say, 100 nF would be just as good) at position 35.53, 1.3 mm from the fiducial point: <code> 220nF|C5|0805|Top|SMD|180|3553|130 </code> At least I can believe the EasyTherm answers now. The Steinhart-Hart equations were solved (by hand in one case!) and they give the correct temperature for the resistance according to my measurements. ||S-H|| CLT || IAT || || A ||1.22E-03||6.12E-04|| || B ||2.76E-04||3.90E-04|| || C ||7.26E-08||-4.99E-07|| I recorded the temperature reported by the ECU for a selection of known resistances with the original GM curves compiled into the firmware. This let me know what A to D bin each resistance fitted in, so I could then build correction tables using an excel workbook for my sensors and compiled these into the firmware. [To add: Excel workbooks for calibration] Recently, I found that the IAT sensor was getting heat soaked. It has been moved from the plenum to the drainpipe where the MAF sensor used to be. The car is much happier with this - and it doesn't get heat soaked as much now. ---- '''Knock Sensor''' I have bolted a single Bosch accoustic knock sensor to the block. The location isn't ideal, but I can't easily do anything about it until I take the engine out at some point. I did just that over the winter and now I have a much better positioned sensor. The knock frequency for the engine is approximately 6.6kHz from the "standard" estimation equation. I have not verified this with a datalog yet because the engine doesn't knock (I'm not trying hard enough) Wiring and pinout are as in the user manual. I bought an assembled unit with EGT and knock ready installed. '''Configuration''' Gain is set to maximum (this is 2) Integrator time constant is approx 140us Everything else set as in Rob's userguide. '''Knock sensor produces output''' Here is a graph of the raw knock sensor outputs from a short run logged with Megatune. These are usually divided to produce "knock_diff". http://www.aqyz05.dsl.pipex.com/strange_knock.gif Note the flat spots in the data - why are they there? They cover both the knock phase and the noise phase. These are typical of the general behaviour of the car. ---- '''EGT Sensor''' I have now installed an EGT probe. The idea being to push the mapping on the car as hard as possible now, both for maximum power and economy. (Up till now, it's been pretty conservative) The parts were bought from Farnell using the list on PhatBob's page. I'm seeing approximately 500C from the probe at the moment, so there is scope for extracting more from the engine... Then I can consider exotic coatings on parts. ---- '''Wideband Lambdas''' I have done some work on the exhaust so the widebands will fit. Two new bosses have been welded in as the LSUs are bigger than the old sensors. I've fitted two - one for each bank. We need to modify the firmware for the 2nd to be supported. * A very old (read broken) LSU sensor is being used to block the second hole up until the firmware is available * Doesn't really matter anyway since the car is off the road anyway because the radiator is broken! [Add pic of modded exhaust] ---- '''Firmware mods for 2 widebands''' We have some code in the round to be backported (mostly prepared for 2 channels, but some more changes still needed) * adc.c irq handler * wbo2.c ** reworked/cleaned up some parts ** we saved some SRAM and even config variables. ** Filtering change for even lower latency * comm.c and lcd_display.c : log and display the new variables * fuelcalc.c : for the 2 independent ego-correction, we need to know which cylinders belong to each bank. ** Would it be feasible to assume that 01, 04, 10 and 40 (odd cylider nos 1, 3, 5, 7) are in one bank and 02, 08, 20 and 80 (even cylinder nos 2, 4, 6, 8) are in the other. No variables are required for this as it can be assumed... (The firing order can be determined by physical connections if the engine is odd-fire or something else weird.) I think cylinder numbering is pretty conventional these days, so it should be able to be generalised for any V or flat engine - we just need to know the cylinder count which is already a varaible. We then just need a variable to determine if which o2 sensor is for left bank (odd number on my engine) and right bank (even cylinders) Or we could again infer this from the physical wiring... (Not nice, but it is practical!) ** Only reasonable with camsync ? *** My engine has a camsync - definitely required for this, so you know for sure which o2 to use... Would it be worth having some form of "average" or selection mode in case camsync is not there? Not a simple mean as this would be silly. Do we simply assume the sensor showing maximum richness as "the one" for this event? Do we actually care? - most people who want to control 2 separate exhaust gas streams on one engine will want to do it properly with a camsync anyway, won't they? * Megatune changes ** At least pump_pw_zero could be independent for the second sensor. ** some variables like max-heat and friends could be dropped, and calculated from battery voltage * Currently reading the firmware code to see if I can work this one out for myself... ** it's unlikely you would want to do this yourself. If you have much sparetime, work on the (SPI=>) MMC logging (and we'll get the 2nd wbo2 channel: for better project efficiency, since wbo2 is simpler for us, while MMC is same amount of work for us as for you) ***Not enough spare time as I'd like! I have been told I need to tile the kitchen (see calibration pic) or get a divorce... Will see what I can do about logging and SPI. Would be OK, as I have a bit of backround in serial comms. '''Calibration of WBO2''' This is well documented in the wiki and manual, but the q & a here is interesting to keep. The '''cal resistor''' in the wideband sensor is '''NOT connected'''. We use the wbo2_calibration setting in firmware instead of the cal resistor. Just measure the cal resistor for verification '''A''': The calibration resistor is not used in the v3.x wideband controller implementation, calibration is done trough adjustment of the calibration constant until your free-air o2% matches 20.95%. However, measure and document Rcal (allows verification of wbo2_calibration value). Don't forget that wbo2_calibration value is sensor dependent. ---- Because of your project documentation was the best (most complete, constructive and clear) of all, you won a v3.x assembled controller (that you can use either as spare while hammering this issue or for new project). Please fire order in webshop for best tracking and precise specs. Thanks very much!! :-) It'll get me back on the road with this car for the moment. I can then get the current one refitted for the Subaru or MGB v8. ---- 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.