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

     #   
         
    ##   
     #   
     #   
     #   
 #   #   
  ###    

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

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

 _     
| |    
| |    
| |    
| |____
\_____/
       
       

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:
= Round Usage Issues = These are the problems reported by Users: == Dropping RPM == Serial Number: 825 Best illustrated with the following data log: http://i110.photobucket.com/albums/n110/butchs13/graph2.png This is the second Nissan to show this problem with RPM logging. '''other datalogs to follow''' === Narrow Band Output === I plotted some of the logs and there are a couple of interesting things (oh no here we go....) If you plot output voltage against lambda, you should get the response curve right? Well you do, but also a bit extra! Have a look at the attached file. I think there are two points worthy of note. There is a second response line when the engine is very lean i.e. in fuel cut, or more specifically transitioning into and out of fuel cut. I've highlighted the data points where this occurs in the data columns. If this is actually truely the output then I could see this as a problem if the ECU goes closed loop and gets told the engine is rich even though it is very lean, e.g. during fuel reinstatement or other conditions. Of course what I would like to do now is feed the lambda output back in to the analogue input and see what the real voltage is. I'll try and get round to it if I get a chance. http://vems.hu/www.vems.co.uk/VEMSInstalls/datalog200612271612.xls '''We're making the curve user programmable''', that is 8..10 points of lambda (or Ip, so O2% values can be handled as well) to output voltage. == Round Analog Inputs == RPM in pin 10 open circuit voltage = 5v touch the lead to earth and hey presto rpm readings on the laptop (obviously slightly spiky but there is life Smiley) So this appears to work fine. This is the first time I've tried it! Analogue in pin 8. open circuit voltage = 4.02 to 4.08v (this is good) With lambda signal out set to NB02 and sensor in air, pin 1 output voltage = 0.1v Connect this to the analogue in and pin 8 = 1 volt, and no reading on the laptop. What does "no reading" mean ? laptop whole display turns blank ? Next, with lambda out set to EGT, and thermocouple at room temp, pin 1 output voltage = 0.5v Connect this to ana in, pin 8 = 1.06v, and no reading on the laptop Last, connect pin 8 to earth = 0v and probably no reading on the laptop (but it starts at 0 anyway) So, I think there is something up with the analogue input on my gauge. Have you got any more ideas on what I should try? Or maybe I should post it back to you to have a look? == Observations == On receiving the gauge and testing it I found that the most obvious issue is that of the EGT value reading +50degC higher than ambient both on the gauge and on MegaTune. I tried a different thermocouple and got exactly the same result. * There is a recommended value for EGT calibration, but * '''There is NO "standard recommended value" for EGT offset'''. 192 can be used as a starting value. If the calibration is lost, simply '''calibrate: short the EGT inputs with an alligator clip, and adjust to known temp.'''. Appr 0.5C/value, so egt_offset=92 will be good for you.
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.