88-91 Ford 5.0 302 usage?

[afnid]

Hello, I have read quite a few threads here both recently and over the last few months.

I am transplanting a newer efi engine (1990) into a vintage (1965) mustang. This is a pretty common transplant for vintage mustangs and broncos. Despite the new efi upgrade, the technology is still 25 years old. The system at least is maf vs speed-density. The engine will remain pretty much stock, and mileage is a priority over performance.

Here is a pretty decent schematic:



The reason I am here is:

- I have added an electronic power steering, and in order to control it correctly I need to tap into the VSS.

- There is other instrumentation in the ecu I want access to without adding redundant sensors.

- Other options I see so far are more proprietary and probably on par price-wise.

I have implemented the epas, and cooling fan control with an arduino, but want to do other engine monitoring functions. Looks like I could migrate that functionality to the Jaguar, or interface to it for the sensor data.

Assumptions so far:

- The Jaguar hardware looks to be the most viable, having already gone through several revs.

- Besides the board/case, I have to come up with some kind of connector and wire/solder the system together.

- I will also need a programmer, but it sounds like all the tools can be used from my linux/mac systems.

- Sounds like the capabilities exist, it just has never been done with this engine, or at least not discussed.

And the questions:

- I have an extra wiring harness, so what connector? Some things have been removed, like the egr system, and sounds like the Jaguar may have the barometric sensor integrated. So what is the path to the point of turning the key on a new system? Are there other sensors I should get, upgrade, or delete? Probably wide-band o2 sensors?

- I am not afraid of a little coding or tweaking to get this running right, but it isn't clear to me if this just involves simple integration, forging new ground, or pushing the hardware/software limits? I don't see nearly as many 8 cylinder engines in the vehicle list.

- Once I have ignition, how much tuning will it take to make this run well, and how quickly will it go from first start to being somewhat stable? Should I expect to be able to achieve the same or better mileage and performance in that priority, or will I be continuously chasing the unobtainable?

In summary, how do I get there from here and what is the level of effort and risk?

[Fred]

Welcome! :-) Apologies for the delay in authorising your post.

The reason I am here is:

- I have added an electronic power steering, and in order to control it correctly I need to tap into the VSS.

- There is other instrumentation in the ecu I want access to without adding redundant sensors.

- Other options I see so far are more proprietary and probably on par price-wise.

Presumably you also want to run your engine on FreeEMS? It's implicit in some of the statements, but there is so much written, it's easy to gloss over and/or forget.

Assumptions so far:

- The Jaguar hardware looks to be the most viable, having already gone through several revs. Yes. It's hard work, but 0.7-alpha is a solid board revision, far in excess of anything else in the DIY arena, including MS3"pro" IMO.

- Besides the board/case, I have to come up with some kind of connector and wire/solder the system together. Yes. Perhaps a gutted OEM case and reuse the loom untouched? This has pros and cons.

- I will also need a programmer, but it sounds like all the tools can be used from my linux/mac systems. Not necessarily. You could get an SMD-done kit from Andy and it'll require no special tools at all.

- Sounds like the capabilities exist, it just has never been done with this engine, or at least not discussed. Capability to do what exactly? No engines are special, really. Just subtle variations in requirements.

And:

And the questions:

- I have an extra wiring harness, so what connector? Some things have been removed, like the egr system, and sounds like the Jaguar may have the barometric sensor integrated. So what is the path to the point of turning the key on a new system? Are there other sensors I should get, upgrade, or delete? Probably wide-band o2 sensors?PIP/SPOUT stuff may be too crappy to bother with. Upgrading to a crank wheel could be a better plan. Wideband is a very-nice-to-have and silly-to-not-use-one, but not essential and won't help you get it started in the first place. The path is one of documentation, discussion, and transparency, so you're right on track to succeed :-)

- I am not afraid of a little coding or tweaking to get this running right, but it isn't clear to me if this just involves simple integration, forging new ground, or pushing the hardware/software limits? The main limitation is 6 output channels, however those without their heads up their arses find good success with this limitation on 8 cylinder engines. Other limitations are mostly software and hardware which can evolve over time to improve the experience.

- I don't see nearly as many 8 cylinder engines in the vehicle list. This is mostly an attitude problem, and a problem with poorly founded bigoted biases. See above for the only thing that affects 8s slightly. 10 is possible too. 12 requires 2 boxes to control, and is thus not feasible right now without undue hassle.

- Once I have ignition, how much tuning will it take to make this run well, and how quickly will it go from first start to being somewhat stable? Should I expect to be able to achieve the same or better mileage and performance in that priority, or will I be continuously chasing the unobtainable? You can tune forever and still make improvements years later. It's a matter of stopping when you're satisfied with the quality of the outcome. Nothing's perfect, OEMs included, so more power and more economy are usually possible. It may take some time to get there, though. When I did the hotel, I swapped to EFI from carb in a weekend, and drove to work (roughly) on Monday, improved it with a few sessions here and there and daily use wasn't much of an issue. See this video: https://www.youtube.com/watch?v=sY4xLbN0fec

In summary, how do I get there from here and what is the level of effort and risk? Effort is substantial with any DIY effort, but particularly FreeEMS for various reasons some of which will be mitigated later. Risk can be zero if you use the OEM connector and loom as is or tweaked in a compatible-with-stock way.

Answers bold and blue.

The things to realise are:

• Nothing is finished.
• Everything is usable.
• Lots of stuff is painful.
• You will have to sink time into it to get the best result. Though this goes for any from-scratch effort with a standalone. And no, base maps don't really help at all.

Some links:

• V8 running decently despite an inappropriate hardware setup for the performance level: https://www.youtube.com/watch?v=961alKym_B8
• Tester, not user: viewtopic.php?f=41&t=1699
• What irritates me: viewtopic.php?f=41&t=2452
• Channel limits: viewtopic.php?f=54&t=1084 Go for dizzy + semi-seq, or wasted spark + banked batch.

I hope that helps clear some things up :-)

Fred.

[afnid]

I have been climbing a very steep learning curve since my original post a week ago. Thanks for the detailed response Fred.

One thing I have on my side is that this is/was a very popular engine for performance upgrades and there is extensive information available about how the existing system works. I found a detailed reverse-engineering document that had all the factory tables dumped from the prom and a lot of information about how it works. I have spent a few days on a program to simulate the function of the current ecu to get a deeper understanding. Got the freeems firmware built, initially had issues with string.h. Ran the open log viewer, which wasn't very interesting without any actual logs. And still haven't been able to build emstudio on linux, haven't located what package might contain qt4 moc, the build served doesn't exist anymore, and the published instructions are obsolete.

So yes, I am looking at the viability of using freeems/jaguar and the smd kit looks like a good start and I see he also sells a programmer. Is this the best board to also use for development/experimenting or is there something better? I found out there are break-out boxes made with this connector, so I could initially setup a passive connection to work out any issues.

Several of your adjectives for sefi didn't really address the technical issues/reasons. At this point I know that the current eec-iv is sequential and I have yet to find anybody recommending a switch away from that in the mustang/eec forums. Can't find anything about oem's going back to non-sequential. I see only the latest ms 3 supports sequential. Is sequential that much harder? Seems like it is just an accuracy/bandwidth issue with 8 events that are scheduled in under 10ms at wot? Do you have a good reference that explains the pros/cons?

The Jaguar has 8 injector outputs so I assume this is not a hardware limit. I see a separate interrupt for each injector task in the firwware, is the current 6 outputs a hard limit on the number of timer interrupts available? I only see 4 periodic interrupt timers in the cpu doc, so you must be using something different? Couldn't a single interrupt schedule more than one sequential injector? Whats the mediocre performance issue with XGATE? Sounds like XGATE would just run in a spin-lock and would schedule off of clock ticks? Seems like the jitter would be in the low 2 digit micro second range?

I looked into oem crank-sensors and there is one on the later model explorers, but it opens up a bunch of other issues trying to retrofit that. Seems like the cam sensor would be better since it would give you tdc. After looking at this for a couple days I came to the realization that when you adjust static timing, your adjusting the injectors with it, so that is probably not a benefit, but the static timing could be factored in, or set to some base and only adjusted in the firmware. What are the disadvantages of using the pip/return signals for engine timing and spark control?

The other thing I was wondering is that there is not a MAP sensor, the one shown on that chart is from a different year, maybe the older speed density system. These engines use a fuel return based system with a pressure regulator to keep the relative pressure between the fuel and intake constant. Not sure if that requires any changes?

So sensor wise, not sure if a map is required, but was thinking about adding a fuel pressure sensor which would achieve the same thing. The 91+ systems incorporated a knock sensor. Wide-band o2, and maybe direct control of multiple coils would bring some benefits, and there are better maf sensors. But none of these are critical path.

There are thousands of these older ford 302 engines out there running around with 25 year old computers. I am not trying to start an argument about sequential, nor do I feel bigoted for asking, but I need to know the benefits of the alternative, and where the limitation is.

Damn, another long post, and pretty quiet around here..

[Fred]

Great post, will reply in the morning. Bed time now :-)

[Fred]

It's nearly midnight here, and I've not gotten around to replying. I don't know what sort of hours you keep, but if you PM me your mobile number (I assume you're in North America), I'll give you a bell on my way home from work tomorrow (assuming that's not too late for you). Or even over breakfast in about 7 hours or so. I'll try to smash out a reply to the above post at some point, but it might be quicker to just talk about everything and clear things up in real time. I'll remove the restrictions on you so you can PM, right now.

[afnid]

Fred, thanks for the call and answering many of my questions.

I really like what russecu did using the arm processor. I see some parallels since I was looking at that board today and have quite a bit of the oem eec simulated with a java program. I am dumping my dictionary and tables to a lowly uno where I have been playing with scheduling from a single timer interrupt.

I proved to myself that sequential on as many cylinders (as you have ram for uno!) is very doable, and would be very accurate with a little more speed. I calculate a 64us jitter equates to 3.84 degrees at 10k rpm, and even the uno can probably cut that in half without killing the main loop, then scale that up 10x+ for a stm32f4!

I have a couple of months before I will even have the car running, but I already have a later model intake that will surely upset the current eec. Plenty of time to play and learn.

[Fred]

You're most welcome.

It's a little premature without actually measuring, but 6us jitter is a pretty low standard to aim for IMO. FreeEMS is currently sitting on 0.8us and I don't plan to allow it to be much worse than that, or it becomes all but useless with large injectors and on bike engines (up to 20k with good precision mandatory, note high RPM increases your min injector sizing, too).

I'd be interested to see what you achieved with the little uno, and how :-)

Fred.

[afnid]

I can agree with that, I looked at a 4 degree swing worse case was pretty small relative to the 100 degree swings in the acceleration enrichment table. So I have played with this a whole lot more and the trade-off is between isr vs main loop. I ported all the efi code I was playing with so far which is pretty complete with 6 lookup tables and 20 functions, so I have plenty for the main loop to do.

At 27k rpm I can run one cylinder with 0us jitter measured in software, but the i/o causes the main loop time to go from 5 ms at 1000 rpm to just under 10ms. Maybe the serial i/o is disabling interrupts, because at some point i start getting a few late events between my 3 second status updates. The signals are pretty clean on the scope, but I need to rtfm to see if it reflects the code. I can run 5 cylinders (20 i/o events) reliable at only about 5000 rpm. Only 5 because I would have to strip out all the error checking in order to free up enough memory to get back to 8. I ordered a mega for more testing, and to see how much faster it is with all the data in sram. 2k of ram is the biggest limiting factor other than cpu speed so far.

It was better on the main loop to use some precise delays to spin off ticks if the next event is close enough instead of sleeping than to try to increase the interrupt frequency. I am simulating a decoder input from the same timer isr and the scheduler relies on the decoder for the tdc reference and cycle us. The strategy from the main loop lays out the schedule by cycle percent (64k pts/cam cycle) and I calculate the schedule event times as needed based on the current decoder stats so even though it takes several ms to come up with a new schedule, the current schedule will be scaled to the intermediate rpm. Not sure if that all makes sense without seeing it.

Given the above a new schedule would be available every 5 rpm but I still am not reading any inputs, but also not caching any calculations either, and the table lookups from program memory have to be a huge portion of the time. I recall reading the oem computer could compute the strategy in 2.5ms, which would be pretty good for 25 years old. Not set on making the arduino viable, but it is a good test just because resources are so constrained. I ordered a smt32f4 demo board ($15) to play with. I think this scheduler would work well with a co-processor like the xgate. I setup an account on github and will post at least the embedded code within a couple days, maybe after I get it running on the arm.

How often do you recalculate a new strategy?

[Fred]

As often as there is new data. I think I understand your "scaled schedule" however that doesn't transport well to any architecture I'd use as they work totally differently to that. LOL @ the 2k of ram, that's 2 of our main real-time tunable tables :-D

[afnid]

I didn't explain that well at all then. It was a way to accurately represent the event angle to keep timing consistent across rpm changes across cycles and within. That is exactly in line with the end-goal. It also allowed me to calculate the final event times with 0 floating point and 0 division operations. I would not call a low-level implementation detail an architecture nor should one dictate the other.

Your "often as there is new data" isn't correct. It is a little hard to read how your code executes at run-time, but you appear to be tasking different loops with different pieces with a periodic 3ms sleep. I am sure you have some hysteresis to filter out insignificant input changes. The reality is lots of stuff is changing, and there is a significant delay to get that into the scheduling .. as it should be.

I am surprised that with all the interrupts your using you don't get more interrupt queuing, which seems to be the principal cause of jitter. Once queued, your longest isr execution time sets the worse case scenario for following interrupts. Events can queue at nearly any rpm just from changes in timing. In order to maintain 0.8 us, your longest isr execution time would have to be less than half that to allow for at least one event to get queued and some additional margin for cpu overhead and the critical code sections where you disable interrupts.

My original Arduino test was in a pristine environment, one timer isr, no contention, and no worries spinning off as many ticks as required in an isr. This was totally unworkable with multiple isr's.

I pushed my code to git and wrote up the details of what I have observed so far:

https://github.com/afnid/CoreEFI

The Timers.cpp file shows how I setup the timers for the 16 mhz avr, the 84 mhz due, and the stm32f407 if your still interested. The stm32f4 is giving me really good results, a big part of the increase is the fpu but even on non floating point is delivery 10x the performance over the Due at 2x the clock rate. I think the due is viable for a full sequential v8 up to 7k rpm, and the stm32f4 would be acceptable to 20k rpm.

The mega may work with 1 cylinder to a respectable rpm with some tuning, and may still perform better than the 25 year old oem system. Even with 8k of ram on the mega, I had to keep the table data in progmem, but since the tables I started with were from the old oem system, they are pretty small.

The hardest part of this has been dealing with the nuances of the timers and how they perform in different situations. I am using variable length timers, with a lead-in time that changes based on performance to try to always be on-time or early. Hours of fun playing with the different architectures.

I am still skeptical that a single core uni-processor is going to out perform an xgate solution until the cpu gets closer to the ghz range. The more interrupt handlers you have, the more queuing contention, and the more jitter.

Hard to justify buying a freescale dev board for $99 when the 407 is only $14. Is there a cheaper dev board available anywhere? Is there a particular one to buy?