Fuel Injected TXT 295cc w/ LS2 Coils

[1989Marathon]

It has wideband, and an AFR table. Crank position is calculated based on trigger position and rpm. The trigger fires an interrupt for very accurate rpm calculation.

[02TXT]

Are you doing closed loop fueling with the wideband? That would be neat to see. Have you posted your code anywhere?

So are you doing fuel only and fixed timing? Using the Arduino's interrupts and a single trigger will provide RPM, but is not ideal for timing advance since the resolution of crank position is too low to accurately predict it's location.

[1989Marathon]

Originally Posted by 02TXT

Are you doing closed loop fueling with the wideband? That would be neat to see.

I have run it closed loop with the AFR for a short while during testing. It works well, but not good enough to use it as the only sensor for fuel adjustment.

Originally Posted by 02TXT

Have you posted your code anywhere?

I have a lot of the code, in various stages, posted in my EFI thread. The current code is not posted.

Originally Posted by 02TXT

So are you doing fuel only and fixed timing? Using the Arduino's interrupts and a single trigger will provide RPM, but is not ideal for timing advance since the resolution of crank position is too low to accurately predict it's location.

Currently, I am controlling fuel only. I agree that the Arduino can not control fuel and timing together, without the missing-tooth wheel. I am running 2 processors. One for fuel, one for timing. The sensors are paralleled into both controllers. A normal hall-effect sensor does not have the switching speed required to perform the timing calculations without a missing-tooth wheel. I am using a US1881 latching Schmitt trigger which has a typical rise-time/fall-time of 0.25 microseconds. Testing with an oscilloscope tells me that I have more than enough resolution, even up to 8000rpm. The timing is much harder to achieve than the fuel delivery. With dual 16Mhz processors, each running its own task, I can maintain 3-4 microsecond accuracy with the interrupts(that's about .018° @ 1000rpm, and about .144° @ 8000rpm), and about 1.0msec accuracy controlling the injector, or the dwell on the coils. That 1.0msec can be adjusted out because the timing of the main programs(fuel and timing) is very consistent. The programs are extremely efficient. Not counting the comments and the variable assignments in the programs, the fuel program is only 75 lines long, and the timing program is 74 lines long.

[RibbedGiraffe]

I'm impressed!
Just a thought and slight concern... In tank pumps are designed to be cooled by the surrounding fuel in the tank, I know in automotive applications the pumps tend to fail more for people that run their cars on 1/4 and bellow more frequently than others.

If it were me - I would look for an aftermarket pump.

This is great - well beyond my electrical abilities.

[1989Marathon]

My pump is in the tank. Much quieter too.

[02TXT]

Originally Posted by 1989Marathon

Currently, I am controlling fuel only. I agree that the Arduino can not control fuel and timing together, without the missing-tooth wheel.

I think you misunderstood what I am saying - a single crank trigger is the issue for accurate timing, not the Arduino. A single 16Mhz processor is plenty to do fuel and timing, even over 10,000+ RPM. 10k RPM with a single crank trigger is only 167hz vs 16,000,000hz of the Arduino.

Originally Posted by 1989Marathon

I am running 2 processors. One for fuel, one for timing. The sensors are paralleled into both controllers. A normal hall-effect sensor does not have the switching speed required to perform the timing calculations without a missing-tooth wheel.

As stated above, one processor is plenty for both fuel and timing, you shouldn't need two (my cart is doing both with one Arduino Mega).

As for the hall effect/missing tooth wheel, I am not sure you understand the correlation between missing tooth wheels and timing. The teeth on the wheel are like pixels on a screen, the more you have, the better the resolution of the picture. Same thing for the crank shaft - the more teeth on the wheel, the better picture (aka "resolution") the ECU has of current crankshaft position. The better understanding the ECU has of the crank position, the better it can predict when to fire the ignition in advance of (before) top dead center.

To state simply, no matter how fast the Schmitt trigger is at picking up your single trigger on the crank, you will never be able to predict as accurately the position of the crank BEFORE your trigger as a multi tooth minus one setup.

And lastly, it actually requires more from the hall effect sensor VS your setup because it triggers as many times per RPM as there are teeth on the wheel (5000RPM / 60 seconds * 36 tooth wheel = 3,000hz, as opposed to your setup with a single trigger 5000RPM / 60 seconds * 1 "trigger" = 83hz)

Originally Posted by 1989Marathon

I am using a US1881 latching Schmitt trigger which has a typical rise-time/fall-time of 0.25 microseconds. Testing with an oscilloscope tells me that I have more than enough resolution, even up to 8000rpm. The timing is much harder to achieve than the fuel delivery. With dual 16Mhz processors, each running its own task, I can maintain 3-4 microsecond accuracy with the interrupts(that's about .018° @ 1000rpm, and about .144° @ 8000rpm), and about 1.0msec accuracy controlling the injector, or the dwell on the coils. That 1.0msec can be adjusted out because the timing of the main programs(fuel and timing) is very consistent. The programs are extremely efficient. Not counting the comments and the variable assignments in the programs, the fuel program is only 75 lines long, and the timing program is 74 lines long.

What you are talking about here is the speed at which the Arduino responds to the trigger - I was asking about how accurate your timing advance is between commanded advance VS actual advance. Since you are doing fuel only and fixed timing, this is probably something you haven't measured.

I am not trying to talk smack.. I can see you have put a lot of work into learning and building, which is a great thing. If you want to continue to learn, your approach will get you there - if you want to get your golf cart back on the road with the most power, there are existing projects to do so.

Louis

[02TXT]

Originally Posted by RibbedGiraffe

I'm impressed!
Just a thought and slight concern... In tank pumps are designed to be cooled by the surrounding fuel in the tank, I know in automotive applications the pumps tend to fail more for people that run their cars on 1/4 and bellow more frequently than others.

If it were me - I would look for an aftermarket pump.

This is great - well beyond my electrical abilities.

Funny, I had the same concern. The pump is cool to the touch irrespective of run time. I bought two for $20, which was far cheaper than I could find a 3 bar external pump (~$90)... if it fails in short order I will probably upgrade, but if it lasts, then what the hey, I have a spare

It is a bit louder out of the tank than in, but it seemed easier to mount outside of the tank. In tank would have required cutting and/or drilling - no bueno.

I have a few hours on it and all is well.. if it dies early I will report back.

[RibbedGiraffe]

Originally Posted by 02TXT

I think you misunderstood what I am saying - a single crank trigger is the issue for accurate timing, not the Arduino. A single 16Mhz processor is plenty to do fuel and timing, even over 10,000+ RPM. 10k RPM with a single crank trigger is only 167hz vs 16,000,000hz of the Arduino.



As stated above, one processor is plenty for both fuel and timing, you shouldn't need two (my cart is doing both with one Arduino Mega).

As for the hall effect/missing tooth wheel, I am not sure you understand the correlation between missing tooth wheels and timing. The teeth on the wheel are like pixels on a screen, the more you have, the better the resolution of the picture. Same thing for the crank shaft - the more teeth on the wheel, the better picture (aka "resolution") the ECU has of current crankshaft position. The better understanding the ECU has of the crank position, the better it can predict when to fire the ignition in advance of (before) top dead center.

To state simply, no matter how fast the Schmitt trigger is at picking up your single trigger on the crank, you will never be able to predict as accurately the position of the crank BEFORE your trigger as a multi tooth minus one setup.

And lastly, it actually requires more from the hall effect sensor VS your setup because it triggers as many times per RPM as there are teeth on the wheel (5000RPM / 60 seconds * 36 tooth wheel = 3,000hz, as opposed to your setup with a single trigger 5000RPM / 60 seconds * 1 "trigger" = 83hz)



What you are talking about here is the speed at witch the Arduino responds to the trigger - I was asking about how accurate your timing advance is between commanded advance VS actual advance. Since you are doing fuel only and fixed timing, this is probably something you haven't measured.

I am not trying to talk smack.. I can see you have put a lot of work into learning and building, which is a great thing. If you want to continue to learn, your approach will get you there - if you want to get your golf cart back on the road with the most power, there are existing projects to do so.

Louis

I want to have beers with you while you teach me! Cheers!

[1989Marathon]

First, a bit about my background, and why I have taken the approach I did...
I write software for a living. Specifically, control software. The control software I write is in some of the most complicated and precise machine tools in existence today. Some of the parts on your car, lawnmower, tractor, or the airplanes you fly on were possibly produced on a machine that has some of my software in it. I've been doing this for over 30 years.

Companies don't stay at the top unless they are willing to develop the latest technology and get a leg up on the competition. You can't do that if you are convinced that there is only one way to do something. That's the approach I take when developing new ideas. Nothing is off the table. The objective for my EFI project is not to just purchase someone else's project, or pay an excessive price for a marketed system. It is to create my own system, with good performance, at a reasonable cost and minimal complexity for the end-user.

It appears that you have a nice setup and you are happy with it. We just have a difference in opinion as to how it can be refined to reduce complexity, and keep cost down.

Originally Posted by 02TXT

As stated above, one processor is plenty for both fuel and timing, you shouldn't need two (my cart is doing both with one Arduino Mega).

I decided to go with dual processors for a couple of reasons. Each can have a dedicated task, they fit into a smaller footprint than a single 2560, and they ended up being cheaper than the single 2560 controller.

Originally Posted by 02TXT

As for the hall effect/missing tooth wheel, I am not sure you understand the correlation between missing tooth wheels and timing. The teeth on the wheel are like pixels on a screen, the more you have, the better the resolution of the picture. Same thing for the crank shaft - the more teeth on the wheel, the better picture (aka "resolution") the ECU has of current crankshaft position. The better understanding the ECU has of the crank position, the better it can predict when to fire the ignition in advance of (before) top dead center.
To state simply, no matter how fast the Schmitt trigger is at picking up your single trigger on the crank, you will never be able to predict as accurately the position of the crank BEFORE your trigger as a multi tooth minus one setup.

I understand how all of that works. I just don't think it is necessary. Traditional EFI setup has taught people that it IS necessary. I believe there is an easier/cheaper way that gets the job done just as well. The primary job of the EFI should be to deliver accurate amounts of fuel, at the right time. It shouldn't need to be burdened by having to count teeth on a wheel.

Originally Posted by 02TXT

And lastly, it actually requires more from the hall effect sensor VS your setup because it triggers as many times per RPM as there are teeth on the wheel (5000RPM / 60 seconds * 36 tooth wheel = 3,000hz, as opposed to your setup with a single trigger 5000RPM / 60 seconds * 1 "trigger" = 83hz)

That's what I'm talking about. That's a lot of burden on the processor. If you aren't doing something with every single trigger, you are just wasting processor time. What I mean is this... if you trigger off of 36 teeth of the wheel, the program has to be interrupted every time a tooth triggers the sensor. For what reason? The program should be written efficiently enough to provide "deterministic timing". That means it should have reliable and repeatable processing times. That "deterministic timing" can be used to your advantage in cases like this.

[02TXT]

Originally Posted by 1989Marathon

First, a bit about my background, and why I have taken the approach I did...
I write software for a living. Specifically, control software. The control software I write is in some of the most complicated and precise machine tools in existence today. Some of the parts on your car, lawnmower, tractor, or the airplanes you fly on were possibly produced on a machine that has some of my software in it. I've been doing this for over 30 years.

That is great, and I too have much professional experience in embedded development.

Originally Posted by 1989Marathon

The objective for my EFI project is not to just purchase someone else's project, or pay an excessive price for a marketed system. It is to create my own system, with good performance, at a reasonable cost and minimal complexity for the end-user.

Isn't that exactly what the Speeduino project is? It's free, open source, community driven project that is far more advanced than what you have developed so far. Their stated goals are "Simplicity of development, Low barrier to entry (ie price and availability of hardware), and Capabilities / Features".

Originally Posted by 1989Marathon

It appears that you have a nice setup and you are happy with it. We just have a difference in opinion as to how it can be refined to reduce complexity, and keep cost down.

Your goal is to reduce complexity? Aren't you running parallel processors? That is fundamentally more complicated than a single processor.

If you are referring to my missing tooth/hall setup as complex, you have yet to demonstrate your setup can match it's performance in ignition timing - remember, you are still running fixed timing and I am advancing timing.

As to cost, I haven't seen your bill of materials, but what are we talking about, $20 difference?

Originally Posted by 1989Marathon

I understand how all of that works. I just don't think it is necessary. Traditional EFI setup has taught people that it IS necessary. I believe there is an easier/cheaper way that gets the job done just as well. The primary job of the EFI should be to deliver accurate amounts of fuel, at the right time. It shouldn't need to be burdened by having to count teeth on a wheel.

You don't need a missing tooth wheel setup for fuel only - a single trigger like your setup is fine for fuel only. The missing tooth wheel comes into play with ignition timing. If your goal is fuel only and fixed timing, you are good. If you goal is fuel and timing to make more power, it won't happen on your single trigger setup.

In fact, the Speeduino supports single trigger input for fuel only.. That's how I ran my cart for a while before adding the missing tooth setup for ignition w/ the LS2 coils.

Originally Posted by 1989Marathon

That's what I'm talking about. That's a lot of burden on the processor. If you aren't doing something with every single trigger, you are just wasting processor time. What I mean is this... if you trigger off of 36 teeth of the wheel, the program has to be interrupted every time a tooth triggers the sensor. For what reason? The program should be written efficiently enough to provide "deterministic timing". That means it should have reliable and repeatable processing times. That "deterministic timing" can be used to your advantage in cases like this.

3,000hz to a 16,000,000hz processor is no burden. And you are not wasting processor time - you are gaining information as to current crank shaft position so you can fire the ignition at the correct angle before top dead center.

And don't forget, the missing tooth setup on the crank is for crank position only - if you want engine phase information, you need a missing tooth wheel on the camshaft By your logic, we should avoid any additional information as it would burden the processor. This simply isn't the case. That's like saying we should play Super Mario Brothers rather than Call of Duty so we don't burden our CPU.

As you experiment you will find that your attempts at "deterministic timing" will fail. It is physically impossible for a single trigger setup to time ignition as accurately as a 36 tooth -1 setup. It's like me asking you to mark 17 inches on an unmarked yard stick - you may get close, but you will never be as accurate as you would be if I handed you a yard stick with 36 evenly spaced marks.

Lastly, Ford, General Motors, Audi, Honda, Toyota, etc. all use some type of multi-tooth setup to derive engine position and phase information. To state they were just too lazy or not smart enough to engineer "deterministic timing" is bold statement... too bold for me to make, sir.

I agree we have different goals - I think you want to learn and experiment with EFI fundamentals and I wanted to fuel inject my golf cart. If/when you get your cart up and running, I look forward to seeing a video

Louis