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

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

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

 ______  
(  ___ \ 
| (   ) )
| (__/ / 
|  __ (  
| (  \ \ 
| )___) )
|/ \___/ 
         

 _       
( (    /|
|  \  ( |
|   \ | |
| (\ \) |
| | \   |
| )  \  |
|/    )_)
         

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''' 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. ---- '''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. ---- '''First show-stopper?''' For no good reason, battery calibration has gone wrong. Two days ago, cal value of 187 read correctly. Now, the same cal value gives 18.6v. The only change has been to fit some bigger injectors. (Same sort of HighZ injectors, so should be no different) All the wiring has been checked, and it's OK. So what's caused the change? The wideband lambda has also given up. Megatune says it is turned off, but the LCD shows changes to EGO correction, but never displays a lambda reading. This problem appeared at the same time as the battery cal. I suspect a connection between the 2 - most likely A to D related. Going to try a firmware update tonight to make sure it's not a memory corruption issue. * Not memory corruption - I reflashed the firmware and there's no change. The ECU is 6 months old. Number 326. I did the required AREF mods a month ago and there have been no issues with it until now. Check the mod again, measure voltage on AVR pin62 and pin64 * Component values all look OK, but voltage is nothing like the expected 4.9ish (much lower). ** this suggests something around AREF is bad *** Total current consumption is 300mA *** voltages at pin 62 and pin 64 are both 3.1v. *** Voltage at the regulator is 3.19. *** When removed from the board (ie reg is run unloaded), the regulator produces 4.8v *** Supply voltage to the MAP sensor is 3.19v. *** I've removed the MAP and the AREF mod to see what happened - it made no difference. *** WHat else is powered from the regulator? Could really do with some help on this one :( Got to get the car back on the road ASAP - I don't think it'll be happy running with this problem. ---- 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.