MPGuino release one workspace

[ptsmith24]

Originally Posted by ecoxantia

Yes - I have been doing this successfully, since I've been playing with the code. I left the jumper on car power and updated using a laptop (running on battery power).

I guess the arduino is powered so doesn't care how...

For info I have a freeduino, usb version.

Ok, thanks. I too have the freeduino (I bought the assembled version from NKC, rather than the kit).

[ptsmith24]

I got the new software uploaded. The RPMs were WAY off to begin with. So I multiplied by an appropriate factor and ended up at 32 pulses/2revs for a fairly decent RPM reading at idle. However, when I'm in park and rev it, the RPMs don't go up. They hover around the same number. Even when I hold the throttle constant for a couple seconds, the same holds true. Problem? Or maybe something unique to my ECU/fuel system? The RPM reading isn't absolutely necessary for me, as I have a tach, but I figured I'd mention it so a potential issue is known ASAP. Any thoughts?

[dcb]

Just curious, what screen are you looking at and which corner? Aside from RPM, it is basically working though?!? Given your initial reports of having to use a huge microseconds/gallon I wonder if there is a hardware issue going on either in the car or on the guino. What does instant raw data screen say?

re: raw screen, it will be gone, need the space when in debug for Serial.

re: EOC is miles for now, idle is gallons. One each on the tank trip and the current trip. Useful for determining the costs/benefits of these techniques.

[ptsmith24]

I'm looking at one of the custom screens in the bottom left corner (RP is the label, is that right?). That number changed when all I changed was the pulses/2revs in setup. I don't know why my usec/gallon is so large, but MPG seems to be fairly accurate...I haven't driven with the new software, so it was jumpy earlier today. I'll find out tomorrow if the update fixes that. I'll know how close my usec/gallon is over the next fillup or two.

[dcb]

Ahhh!!!, I think I got it. You have an early tbi!! The pulse frequency simply has nothing to do with RPM (duh!)

[ptsmith24]

That wouldn't affect my mileage numbers, would it? Also, there isn't a way to get the RPM to work properly? (hopefully without much of a software change)

[dcb]

The mpg reading should be fine, but it is not simple to add rpm for this injection type. Needs additional hardware/wiring/code.

I would recommend customizing the custom screen to put something more useful in that spot, i.e. before you load it try (to display instant gph):

change:
void doDisplayCustom(){displayTripCombo('I','M',instantmpg(),'S',instantmph(),'R','P',instantrpm(),'C',current.mpg());}      

to:
void doDisplayCustom(){displayTripCombo('I','M',instantmpg(),'S',instantmph(),'G','H',instantgph(),'C',current.mpg());}

[ptsmith24]

I'll change it around and upload after I get it calibrated. In the meantime, I'll keep it on the Instant/Current screen that I had it on before the software update. Thanks.

[jmilk]

Originally Posted by ptsmith24

The gallons going nowhere would be more useful to me than EOC since I have an automatic and am kinda not sure about coasting in neutral with the motor off until I know specifics about how the transmission fluid works and gets pumped through the necessary parts.

I'd be curious what you find. I tried EOC on my automatic (sigh) Kia on a stretch of country road, and it's just not feasible. Put tranny in neutral, turn key, and what you get is something that moves like an oil tanker. Interior lights come on (minor annoyance), steering is essentially gone, and brakes are abysmal. The vehicle won't start up again while rolling; has to be in Park and foot on break, so it's a no go for pulse & glide.

The brakes are fine for slowing to a stop if you apply them before killing the engine. I've taken to EOC red lights -- Neutral, brake, kill engine, coast/brake to stop; once stopped, put car in Park and ready for start.

(sorry for the OT'ness...)

[jmilk]

Hey dcb et al,

it's the first time I actually looked at the code. I see a few places where I think I can optimize the size requirements, and possibly the speed as well. First off tho, is there a reason why the LCD's data lines are fragmented? If we used, say, pins 4-7 or 8-11 we could simply push the nibbles into PORT_D or PORT_B, respectively. Am I missing something?

I'm bored, so I'll go through a bit of this tonight.