Go Back   EcoModder Forum > EcoModding > Instrumentation > OpenGauge / MPGuino FE computer
Register Now
 Register Now
 

Reply  Post New Thread
 
Submit Tools LinkBack Thread Tools
Old 07-20-2013, 06:26 PM   #31 (permalink)
EcoModding Apprentice
 
Join Date: Aug 2009
Location: terra firma
Posts: 138
Thanks: 4
Thanked 24 Times in 22 Posts
Quote:
byte oldSREG = SREG;
Ah, thanks. I was calling it from an ISR or two.

I'll ponder the whole Read-CheckOverflow-ReadAgain thing later. I'm not sure it really makes a big difference. If it's off by 256usec (or 1024), it only affects a calculation at that moment, and it's not cumulative, so what are we really losing? There's a total of 11 clock cycles (< 0.7usec @16mhz) between cli & sei here.


The original recursion code was testing against 4290560000, which is 4407296 less than FFFF FFFF. That means it would recurse, except during the last 4.4 seconds of the timer's 68 minute life cycle. I tried googling around for those numbers, but was only pointed back to the mpguino code, so it doesn't appear to be an established practice.

Also, i only removed that recursion thing very, very recently, so i dont think it was preventing any freezes or resets i was having.

  Reply With Quote
Alt Today
Popular topics

Other popular topics in this forum...

   
Old 07-21-2013, 03:49 PM   #32 (permalink)
EcoModding Apprentice
 
Join Date: Aug 2009
Location: terra firma
Posts: 138
Thanks: 4
Thanked 24 Times in 22 Posts
Quote:
Remember also that if you happen to read TCNT2, it might roll over and overflow right before you read it, thus giving a false lower value. This is why it's generally better to read the value, check for overflow condition, then read again and adjust for the overflow if the overflow condition is found to exist. All this, of course, is done while interrupts are disabled.
Looking at this again, I thought cli also shuts off timers, thus preventing any undesired counter hijinks.
  Reply With Quote
Old 07-21-2013, 05:06 PM   #33 (permalink)
MPGuino Supporter
 
t vago's Avatar
 
Join Date: Oct 2010
Location: Cedar Rapids, IA
Posts: 1,766

The Karen-Mobile - '05 Dodge Magnum SXT
Team Dodge
90 day: 26.72 mpg (US)

Fiat Dakota - '00 Dodge Dakota SLT RWD Quad Cab
90 day: 16.67 mpg (US)

The Red Sled - '01 Dodge Durango SLT 4WD
90 day: 16.96 mpg (US)
Thanks: 799
Thanked 681 Times in 437 Posts
Quote:
Originally Posted by nickdigger View Post
Looking at this again, I thought cli also shuts off timers, thus preventing any undesired counter hijinks.
Nope. cli() only disables interrupts. The timers themselves will keep on going, with all that that implies.

For instance, say you disable interrupts inside MPGuino using cli(). Timer 2 is still merrily going on its way at 1/64th of the system clock, as it was configured. During the course of your routine, timer 2 overflows. It sets the overflow flag, but since interrupts are still disabled, your routine will continue to execute without any interruption. Once interrupts are re-enabled (via sei(), or restoring the SREG from a pre-cli() state), the timer 2 overflow interrupt will now fire.
__________________
The Fiat Dakota


The Karen-mobile


The Red Sled
  Reply With Quote
Old 07-21-2013, 09:53 PM   #34 (permalink)
EcoModding Apprentice
 
Join Date: Oct 2010
Location: winterpeg, manisnowba
Posts: 211

clank - '99 jeep tj sport
90 day: 17.32 mpg (US)
Thanks: 9
Thanked 18 Times in 18 Posts
vago; where'd you get your fuel pressure from because everything i've read for every chrysler produced from 99 or earlier, on is suppost to be 49+/-5psi?

if your fuel pressure reg is actually getting 58+psi(you said 58psi over atmospheric so 72psi) you might want to replace/fix it; it might fix your problem

from a factory service manual

(4) If operating pressure is above 54.2 psi, electric
fuel pump is OK, but fuel pressure regulator is defective.
Replace fuel filter/fuel pressure regulator. Refer
to Fuel Filter/Fuel Pressure Regulator Removal/Installation
for more information.

Last edited by baldlobo; 07-21-2013 at 10:39 PM..
  Reply With Quote
Old 07-22-2013, 10:02 AM   #35 (permalink)
MPGuino Supporter
 
t vago's Avatar
 
Join Date: Oct 2010
Location: Cedar Rapids, IA
Posts: 1,766

The Karen-Mobile - '05 Dodge Magnum SXT
Team Dodge
90 day: 26.72 mpg (US)

Fiat Dakota - '00 Dodge Dakota SLT RWD Quad Cab
90 day: 16.67 mpg (US)

The Red Sled - '01 Dodge Durango SLT 4WD
90 day: 16.96 mpg (US)
Thanks: 799
Thanked 681 Times in 437 Posts
Quote:
Originally Posted by baldlobo View Post
vago; where'd you get your fuel pressure from because everything i've read for every chrysler produced from 99 or earlier, on is suppost to be 49+/-5psi?

if your fuel pressure reg is actually getting 58+psi(you said 58psi over atmospheric so 72psi) you might want to replace/fix it; it might fix your problem

from a factory service manual

(4) If operating pressure is above 54.2 psi, electric
fuel pump is OK, but fuel pressure regulator is defective.
Replace fuel filter/fuel pressure regulator. Refer
to Fuel Filter/Fuel Pressure Regulator Removal/Installation
for more information.
From page 14-2 of the 2005 LX platform Factory Service Manual:

58 psig, or 400 kPa.

Now, my truck, on the other hand, does have that 49.5 psig rating. That's good to know information - I will need to add another eeprom parameter to compensate.
Attached Thumbnails
Click image for larger version

Name:	2005LX-14-2.png
Views:	92
Size:	8.4 KB
ID:	13490  
__________________
The Fiat Dakota


The Karen-mobile


The Red Sled
  Reply With Quote
Old 09-02-2013, 12:17 PM   #36 (permalink)
MPGuino Supporter
 
t vago's Avatar
 
Join Date: Oct 2010
Location: Cedar Rapids, IA
Posts: 1,766

The Karen-Mobile - '05 Dodge Magnum SXT
Team Dodge
90 day: 26.72 mpg (US)

Fiat Dakota - '00 Dodge Dakota SLT RWD Quad Cab
90 day: 16.67 mpg (US)

The Red Sled - '01 Dodge Durango SLT 4WD
90 day: 16.96 mpg (US)
Thanks: 799
Thanked 681 Times in 437 Posts


The injector pressure differential correction factor code has been written, and is now in a stable version. Code testing is underway.
__________________
The Fiat Dakota


The Karen-mobile


The Red Sled
  Reply With Quote
The Following User Says Thank You to t vago For This Useful Post:
KY Metro (09-03-2013)
Old 09-03-2013, 05:51 PM   #37 (permalink)
MPGuino Supporter
 
t vago's Avatar
 
Join Date: Oct 2010
Location: Cedar Rapids, IA
Posts: 1,766

The Karen-Mobile - '05 Dodge Magnum SXT
Team Dodge
90 day: 26.72 mpg (US)

Fiat Dakota - '00 Dodge Dakota SLT RWD Quad Cab
90 day: 16.67 mpg (US)

The Red Sled - '01 Dodge Durango SLT 4WD
90 day: 16.96 mpg (US)
Thanks: 799
Thanked 681 Times in 437 Posts
Unhappy WARNING - Novel Alert

Results of testing today - Partial success.

Today, on my drive to work, the calculated injector correction factor was a bit off, from what I expected, leading to lower-than-correct fuel consumption readings.

However, my code was easily able to read and process MAP sensor readings for each individual fuel injector event. Given that said events can occur from once every 150 ms to once every 19 ms, this represents a very significant capability.

Equation 1 below is used to correct the fuel injector pulse length reading for a returnless fuel system-equipped vehicle, when said vehicle uses a constant-pressure fuel pressure regulator.

(1) - F = sqrt( P(diff inj) / P(fuel pressure regulator) )

However, the equation for determining the pressure differential across the fuel injector,

(2) - P(diff inj) = P(fuel system) - P(intake)

has some complication associated with it. In particular, P(fuel pressure regulator) is a gauge pressure reading, while P(intake) is an absolute pressure. Or,

(3) - P(fuel system) = P(baro) + P(fuel pressure regulator)

Where P(fuel pressure regulator) is the rated fuel pressure of my fuel pressure regulator, and p(baro) is the absolute atmospheric pressure. Thus, equation 2 above turns into:

(4) - p(diff inj) = P(fuel pressure regulator) + P(baro) - P(intake)

Right now, my P(baro) estimator works by setting P(baro) to P(intake) when it senses that both the engine is turned off, and the vehicle is not moving. Ideally, this would give an accurate P(baro) right before the engine is turned on. However, in real life, this isn't always the case. The MPGuino hardware is always turned on, but the engine computer is sometimes shut off. When this happens, the power to the MAP sensor goes to 0 VDC, so the MAP sensor output itself goes to 0 VDC. This is what happened today.

I noticed that my estimated P(baro) was effectively at zero psi. This will (and did, of course) throw off the correction factor, rendering it useless for its intended purpose. Clearly, I will need to do something about that.

Now, I could recode the P(baro) estimator, but it would cause my code to grow more than it already is. As of right now, the code sits at 19640 bytes. Or, I could retain the existing code, and simply wait for a few seconds or so, after turning the ignition key to On, and before starting the engine. That would certainly give me an accurate P(baro). However, that would require that the driver wait before starting the engine every single time. Maybe the average MPGuino user would be this anal... I don't know. However, I don't want to depend on that.

Just had this thought - even if I did get an accurate P(baro) right before starting the engine, that P(baro) would only be accurate for a little while. Weather changes, elevation changes, and temperature changes all affect P(baro). My engine computer gets around this by estimating P(baro) based on throttle position, the MAP sensor, engine speed, and a lookup table. However, to implement something like that into my code would require both using the remaining analog input, and a calibration to generate a suitable lookup table. That could prove to be very challenging.

Were I to add a separate pressure sensor dedicated to solely measuring atmospheric pressure, that would certainly get rid of any costy estimation code, and any undue expectation on the part of the driver, but it would do so at the cost of using up the remaining analog input. This might not be a problem, but then again, it might be. For instance, I've read in this forum that other users saw how system voltage changes cause changes in injector reaction time, and went about coding to compensate for that. Well, that needs an analog input to be able to measure system voltage. If that input were instead used for barometric pressure, one would have to assume a more-or-less constant system voltage (which the base MPGuino code does, BTW).

Not to mention that a separate MAP sensor costs in the range of $40 or so.

I will probably end up going with adding a separate MAP sensor that is dedicated as a barometric pressure sensor. It will, of course, eat up that remaining analog input. However, it might be beneficial to members like KY Metro, who are looking to add a fuel pressure sensor due to how they operate their fuel pump. As long as the fuel pressure sensor would also read absolute pressures, this would not pose any problem with my code.
__________________
The Fiat Dakota


The Karen-mobile


The Red Sled
  Reply With Quote
Old 09-03-2013, 06:26 PM   #38 (permalink)
EcoModding Apprentice
 
Join Date: Aug 2009
Location: terra firma
Posts: 138
Thanks: 4
Thanked 24 Times in 22 Posts
If you only need one more analog pin, you could move the VSS over to your newly-free pin3.

The buttons are a big waste of analog inputs. I plan to add resistors to mine, and have all 3 (plus a 4th) share a single pin.

Also, if you happen to use a TQFP atmega, there are 2 extra analog inputs available: A6 and A7.
  Reply With Quote
The Following User Says Thank You to nickdigger For This Useful Post:
t vago (09-03-2013)
Old 09-04-2013, 02:45 PM   #39 (permalink)
EcoModding Apprentice
 
Join Date: Dec 2012
Location: Portugal
Posts: 197
Thanks: 93
Thanked 69 Times in 64 Posts
Quote:
Originally Posted by nickdigger View Post
The buttons are a big waste of analog inputs. I plan to add resistors to mine, and have all 3 (plus a 4th) share a single pin.
The idea to use one pin for the buttons, it is a good idea but in other projects, this project is more difficult due to the combination of buttons, that causes the value of resistances combined, is identical in some combinations of buttons .
But try it yourself.

Josť Rodrigues
  Reply With Quote
Old 09-05-2013, 03:49 AM   #40 (permalink)
EcoModding Apprentice
 
Join Date: Aug 2009
Location: terra firma
Posts: 138
Thanks: 4
Thanked 24 Times in 22 Posts
That's easy for you to say, Jose, with your 16 Analog & 53 Digital I/O =)
I am going to try it though.

  Reply With Quote
Reply  Post New Thread


Thread Tools




Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com