ESI Project: Digital tachometer, speedometer, and intelligent shift light

[bobnova 59]

Recently there was a contest for applications using TI's ESI hardware rotation/flow sensing peripheral, I was one of the winners of that. Actually TI did a pretty cool thing and gave the prize (target board and programmer) to everybody who entered rather than just their favorite five. Go TI!

In any event, here is product pitch I submitted:

 

 

Digital tachometer, speedometer, and intelligent shift light.

Uses the ESI to read either the ignitor's tach output (one pulse per ignition event, so two per engine revolution) or the vehicle speed sensor's square wave (whichever is more difficult to do with interrupts/timers, unknown at this time) as well as the throttle position sensor.

Displays engine RPM via either LCD screen or RGBLED bars (or both, plenty of GPIO here), also vehicle speed with LED indicators for common speed limits.

Based on throttle position, engine RPM and vehicle speed (and gear, calculated via engine RPM and road speed) it will also have a pair of shift lights, one to indicate for downshifting and one to indicate for upshifting.

Example: On the freeway behind someone at 60MPH in a 65 zone in 5th gear, left lane opens up and you can accelerate. If you give the engine a little bit of gas to accelerate slowly, no lights. Stomp on the gas and the downshift light comes on (perhaps blinking, to indicate multiple gears downward are indicated, as full throttle 60MPH is best done in 3rd gear on this car). If/when you downshift, the light goes out. Let off the throttle to maintain your new speed and the upshift light comes on, as 65MPH in 3rd is lousy for cruising.

Also indicates upshifts based on engine RPM directly, given a 6750 redline and high throttle angle the upshift light would come on around 6500RPM.

I may make the MCU learn the rev limits, may not.

ESI and FRAM are not specifically needed for this project, but using ESI for either tach or road speed would eliminate timing artifacts that would happen if the road speed and tach signals happened simultaneously, something that is guaranteed to happen eventually.

 

I also submitted a more advanced version that ties into the fuel injectors and computes instant and average mileage, but I may or may not get to that in a reasonable time period.

 

This is my project thread for this project, if you hadn't guessed.

I'll be updating this first post as progress continues, as well as making more posts in the thread.

I welcome any/all input, feature ideas, suggestions, comments, etc.

 

I'm hoping to begin work on prototype code later today, I'll probably start off using a MSP430G2553 rather than a FRAM w/ESI chip, as I'd much rather blow up a $2.70 chip than a $25 launchpad or a FRAM MCU that isn't available for sale yet. I do have a FR5969 launchpad, which has the ESI bits in it as well, that will go into use once I make sure the inputs are at the voltage(s) I think they are.

 

 

[spirilis 1,265]

Recently there was a contest for applications using TI's ESI hardware rotation/flow sensing peripheral, I was one of the winners of that. Actually TI did a pretty cool thing and gave the prize (target board and programmer) to everybody who entered rather than just their favorite five. Go TI!

In any event, here is product pitch I submitted:

 

 

 

I also submitted a more advanced version that ties into the fuel injectors and computes instant and average mileage, but I may or may not get to that in a reasonable time period.

 

This is my project thread for this project, if you hadn't guessed.

I'll be updating this first post as progress continues, as well as making more posts in the thread.

I welcome any/all input, feature ideas, suggestions, comments, etc.

 

I'm hoping to begin work on prototype code later today, I'll probably start off using a MSP430G2553 rather than a FRAM w/ESI chip, as I'd much rather blow up a $2.70 chip than a $25 launchpad or a FRAM MCU that isn't available for sale yet. I do have a FR5969 launchpad, which has the ESI bits in it as well, that will go into use once I make sure the inputs are at the voltage(s) I think they are.

I don't think the FR5969 has ESI fyi ... just the FR6989 or whatever.  The header files (grepping/searching for MSP430_HAS_) elucidates this.

[abecedarian 330]

I like your idea. May I suggest adding a manifold pressure sensor to the design?

 

You could program the shift light to illuminate at certain RPM for over-revving protection and use manifold pressure as another trigger for the light, such as during partial throttle application. When you press the pedal down some, manifold pressure will increase (less vacuum = more pressure), and RPM will climb. During this period, manifold pressure will decrease (more vacuum) as the RPM approaches the peak power output at that throttle opening angle. So, if you watch manifold vacuum until it's rate of change slows, that is the point where you could trip the shift light. Don't know if I'm making sense.

 

MPG is fairly easy to implement: speed divided by fuel consumption, both measured in a common unit of time such as seconds. Instantaneous would be miles per second divided by liters (gallons) per second; accumulated would be the running average of all instantaneous calculations up to that point. Calculating fuel consumption will require knowing fuel pressure at the time of sampling the injector pulse-width and the injector flow rate at that pressure. Most vehicles have variable fuel pressure such as 34PSI at idle increasing to 43PSI, correlated to manifold vacuum; turbo/supercharged vehicles can have peak pressures nearing 80PSI or more.

 

You could also sense the fuel level and extrapolate fuel consumption from that, if you can accurately calibrate the fuel level sensor. A Kia I recently rented did that- it would reset the accumulated fuel economy tally when you filled the tank. You could get fancy and do a 'lifetime', 'tank', and 'instant' economy tracking.

 

Okay, I'll shut up now.

[bobnova 59]

I don't think the FR5969 has ESI fyi ... just the FR6989 or whatever.  The header files (grepping/searching for MSP430_HAS_) elucidates this.

Well that's awkward. TI's combined datasheet/user guides frustrate me for this reason. I'll check that. Thanks!

 

I like your idea. May I suggest adding a manifold pressure sensor to the design?

 

You could program the shift light to illuminate at certain RPM for over-revving protection and use manifold pressure as another trigger for the light, such as during partial throttle application. When you press the pedal down some, manifold pressure will increase (less vacuum = more pressure), and RPM will climb. During this period, manifold pressure will decrease (more vacuum) as the RPM approaches the peak power output at that throttle opening angle. So, if you watch manifold vacuum until it's rate of change slows, that is the point where you could trip the shift light. Don't know if I'm making sense.

 

MPG is fairly easy to implement: speed divided by fuel consumption, both measured in a common unit of time such as seconds. Instantaneous would be miles per second divided by liters (gallons) per second; accumulated would be the running average of all instantaneous calculations up to that point. Calculating fuel consumption will require knowing fuel pressure at the time of sampling the injector pulse-width and the injector flow rate at that pressure. Most vehicles have variable fuel pressure such as 34PSI at idle increasing to 43PSI, correlated to manifold vacuum; turbo/supercharged vehicles can have peak pressures nearing 80PSI or more.

 

You could also sense the fuel level and extrapolate fuel consumption from that, if you can accurately calibrate the fuel level sensor. A Kia I recently rented did that- it would reset the accumulated fuel economy tally when you filled the tank. You could get fancy and do a 'lifetime', 'tank', and 'instant' economy tracking.

 

Okay, I'll shut up now.

The MAP sensor is definitely on the list of possibles as well, as you mentioned it's a lovely load indicator, more specific to engine load than the TPS.

Honda typically runs the fuel pressure at 38-44 PSI over intake pressure, so I'd need to measure that and find out exactly where it is with regards to intake pressure. After that it's essentially static as far as fuel flow goes.

What you're talking about is pretty much exactly my thought process. I know the MPGduino already exists and does something similar already, but that's no fun

Thankfully (or not...) the vehicle in question is a 100% stock 97 civic, very simple car. No forced induction or sneaky variable runner lengths or anything.

Fuel consumption based on fuel level is something that hadn't occurred to me, that could be interesting to pursue. The more I think about it, the more I like this idea.

Thanks for the ideas!

[bobnova 59]

Minor update, did some very preliminary work on getting a FRx9x9 (currently, 5969) set up and timers running for pulse width counting / display update intervals / etc.

These things are far more complicated internally than the 2553s, that's for sure. It's been a bit of a headache, but I'm making headway.

It doesn't help that I've been almost entirely using Energia up to this point. Using CCS-level code inside Energia is all well and good, but Energia still takes care of all the basic setup, so I've had to figure out how to get all that going.

I think I've gotten most of it at least.

 

I start a new job on Monday, so things may go slowly. I really want to have this for my car (as I think I mentioned, my car has no tach at all, which frustrates me), so it will get done!

[spirilis 1,265]

Heh come to think of it, my wife's car doesn't have a tach... and that does drive me nuts!

 

Sent from my Galaxy Note II with Tapatalk 4

[bobnova 59]

Haven't had a ton of time, but I did have a chance to open up the TI packages last week, and had some time to sit down with the dev board and programmer today.

I like both of them.

LED on P1_0 is happily blinking away, energy trace is still awesome.

[bobnova 59]

Even less time! Amazing!

 

Did figure out exactly what I want to do with the ESI bits though. I'm thinking that their ability to start/stop a timer to measure a pulse width is going to be used to collect ON time of a fuel injector.

For the early going I'll just measure fuel in seconds of flow per distance, or seconds of flow per trip. It won't be something that can be converted to MPG, but it'll be easy to see the difference driving style/etc. makes.

 

Having the ESI do the timer running means not having to use CPU cycles to do it but still getting a good solid time on it, which I like.

 

 

Spent some time trying to get the UART transmitting for debuging. Didn't manage to. I need to pry the setup out of the Energia FR5969 setup bits and try that.

[abecedarian 330]

An injector open time of 2ms at 800 RPM will flow less fuel, overall, than an injector with 2ms open time at 5000 RPM.

 

Duty cycle determines the total fuel flow.

 

 

*edit- didn't mean that to come out like you already didn't know better.

[bobnova 59]

It's all good. Hard to get tone/mannerisms in text so I try to assume the least offensive interpretation is true.

 

What I'm planning on doing is having a (big) variable with the total ms (or maybe tenths of a ms) of fuel injected into one cylinder, so each time the injector fires the firing time is counted (if I can get a sensitive enough scope in there to measure how long it takes to open, I'll subtract that from the open time) and added to that running variable.

 

A probably-won't-compile-and-definitely-won't-work semi-pseudocode/semi-energia/semi-ccs example:

unsigned long totalFiringTime;
unsigned char thisFiringTime;
boolean injectorFired = false;
 
while(1){
  thisFiringTime = 0; // It's being zero'd constantly so that it'll be zero when the injector fires.
 
  while(injector == firing){  //
    delayMicroseconds(100);  // wait 100 microseconds.
    thisFiringTime++; // mark off that 100microseconds.
  }
 
  totalFiringTime += thisFiringTime;
 
}

It'll need Awesome Features like a way to report the collected data and track/report other things too of course, but that's the basic idea.

So at 800RPM for a minute with a 2ms injector pulse it'll report ~800ms of fuel injected, while a minute of 5000rpm and 2ms injector pulses will report 5000ms of fuel. (One pulse every other RPM in this theoretical motor. Real world may well be different, but it'll be the same across all four cylinders at a given moment of time so that's OK I think).

What units I use will depend on testing. I just ran some numbers through calc.exe and it looks like if I assume my civic has 240cc/min injectors (I think it's somewhere around there) a full tank of fuel is ~189 minutes or 11356 seconds. Given that I have four injectors running but am only tracking one, it'd take ~2839 seconds to empty my fuel tank. If I pretend an unsigned long is 4 billion exactly that suggests that I should use a unit of 0.00000070975 seconds for best accuracy, or ~701ns.

That seems overly exact, I could see going for microsecond accuracy, should be easy enough to feed the ESI timer a 1MHz clock to count with. That'd give me enough exactitude to take the injector opening time out without mucking with the fuel pulse too much.

Using microsecond accuracy justifies the ESI though, so that's nice!

 

It's all lovely and theoretical still of course. I haven't had time and the required brainpower available to actually muck with it since the failed attempt at UART functionality.

Loving the new job, but having spent much of the day figuring things out makes it harder to get into the swing of it at home!

 

The more I think about this theoretical project the more I want to have it though.