In another thread, I proposed that we might want to make our own PCM and FICM (powertrain control module and fuel injection control module). This thread is about the idea of doing so and calling for people with the right skillsets. I can do the electronics.

First of all, why?

• We could reinstate pilot injection
• We could write our own tuning programs
• We would be taking control of our trucks.
• What we build might go on to be a platform that free's america's tuning community from the tyranny of the auto makers.

What's required? I expect that we could create a project with a moderate eden chip (intel compatible, cheap, doesn't require active cooling) and some ASIC's. Electronically, most issues are easily solvable and componentized. CAN bus interfaces are cheap off-the-shelf technology. Embedable motherboards with expansion ability are in the $120 range with 128M RAM and boot from compact flash.

The goal would be to create an open sourced system that would run a 6.0L powerstroke engine for about $500 in parts. As I said, I know how to do the electronics.

Now... I'll be the first to admit what I don't know. The most important output of the FICM (and calculated by the PCM) is the timing and size of the injections. Does the timing of the injections change? How often. What accuracy is required in the pulse that triggers the injector (microsecond, nanosecond)?

I assume, from what I've read, that we'll need to develop tables that relate "demand" to "output" based on several variables (rpm/boost/temp/previous output?). But before we design the hardware, I'd need someone to help me with the required (or desired) accuracy of each of these input and output quantities.

Once the hardware is developed, it comes down to producing the tables. We can't use Ford's tables (likely a copyright issue). I expect that we'd start by recording a lot of data from the stock computer and building a simulator (an electronic simulation of the engine). The simulator will be a lot of work ... but it's something that will save us a lot of time later ... and allow people to tune the unit to other engines vastly more rapidly. With a combination of simulator and real world work, I expect that tables of some quality can be generated.

At that point, people like superchips might step up with their own tables (likely for those who would like to pay) and hobbiests could tune their own vehicles (a great american tradition).

To be clear about what I'm proposing, then; I propose that we form a group that will produce an open source hardware and software application that will run a 6.0L PSD engine fully replacing the stock PCM and FICM. The plans, stock tuning and software for the project will be published on this site and free for anyone to download. Vendors will be permitted to offer the hardware/software/tuning for sale at any price they see fit so that people who aren't handy with a soldering iron can use the result. Vendors are also welcome to offer software and tuning of their own invention with more restrictive licences.

So... I'm asking for volenteers with expertise in making Diesel engines work. Expertise in software and microprogramming won't go amiss either. Many hands make light work. Think of it like linux: a few of us hackers can make something for the common good.

 

I have website and electronics skill. Contact me if u require any of my help...............

 

I'm an idiot but what about taking the module out of the truck and disecting the existing maps or tablets.
Then, single out stuff to leave alone and stuff to rewrite?

I mean, why rewrite software for stuff that is okay?

I still can't believe that an aftermarket module doesn't have the ability to reinstate th PI yet.

Seems like the 1st company to do it would pretty much have a lock on the market?

Hello Predator, Superchips, Edge, Banks, etc....

Then again, i am an idiot so what do i know?

 

The vast majority of chip/tuning is modifying the manufacturer's tables, changing bit flags, etc. Very little of it, it any in most cases, involves changes to executable code, which is why there were copyright lawsuits about chips early on.

The 1st company to do it from scratch would not have a lock on the market, they would be throwing away tons of money duplicating what Ford has already done. Much easier to take Ford's tunes, modify the tables and change some bit settings - but still harder than most would think.

 

Thats what i was trying to say but i do think that the 1st chip tuner that is quality AND can reactivate the PI will have a lock until the rest catch up.

 

If you can do what you propose you'll be rich! Sounds like quite the project, especially to a computer challenged person like myself.

 

To be frank, if the problem (as discussed elsewhere) with pilot injection is that the PCM and/or FICM is not powerful enough to perform PI, then the solution is a ground-up redesign.

You can't reuse FMC's code and/or tables without FMC's permission. That's why, for instance, the superchip programmer must require a certain revision of the ROM and not just upgrade it for you --- performing that upgrade would be a violation of copyright.

Would FMC give permission? I doubt it.

I don't know how many people in these forums have experience with opensource, but the idea is that for one company (superchips for instance) to take on the fabrication of a new PCM/FICM would be a gigantic burden. However, for the community of Ford truck owners to reengineer this part is possible. Let's take a look at the amount of work involved:

1. initial design and test mule specs. The goal of this phase is to build a test platform hardware example. This is likely to take about two man-days of effort and $1000 out-of-pocket for each participant. We would decide on a platform --- likely a specific eden board with a specific set of ASICs mounted on a mini-PCI card, an operating system, etc.
2. Design and implemntation of the primary application. The goal of this phase is to produce the basic application that montiors the inputs and produces the outputs. Tables are not complete at this point. This would include the ability to record input and output values in a log. Probably 4 to 8 man-weeks.
3. Fabrication of a test harness for the system whereby engine sensor data is duplicated to the new system. Outputs from the new system are not connected to the engine, but recorded as above. Probably 2 man-weeks ... likely requires someone with electrical and/or automotive engineer type qualifications to get right.
4. Design and implementation of the simulator. Given the recorded data, the simulator generates inputs and accepts outputs (and attemtps to calculate the effects thereof). This isn't an exact science, but given the test harness of (3) we should be able to minimize the risk of generating basic tables. Probably 4 to 8 man-weeks of programmer time with consultation with automotive guys.
5. Refine test harness of (3) to add the ability to switch from the FMC PCM/FICM to the new unit and back and forth. This prepares the way for real tests in (7) another 2 man-weeks.
6. Generate first-blush tables from first principles, examination of (3) data and seat-of-the-pants theories. Run tables against simulator. Probably 2 to 4 man-weeks of effort. Product is a set of tables that should at least run the truck.
7. place new unit in test harness. Probably should assemble the whole group for a week retreat somewhere where we can't hit anyone with our test truck. 1 week * number of people who show up. It would probably help to have examples of pilot injection programs on hand.

At that point, you're probably talking about the 1.0 release with an at-least-as-good-as-stock program. From there, for reasonable amounts of work, people like superchips and home tuners alike can work on modifying programs. With a surperior ability to record all the actions of the unit, tuning should become easier.

It's likely that we'll want to add extra sensors from stock. Some to facilitate tuning ... others to provide failsafe information (like an EGT sensor).

What I've detailed is about 6 man-months of work. A sizable commitment. However, if a dozen or so people chip in part time over the course of a year (with the usual innefficiency of open source projects), I expect that we'd be able to achieve 1.0 in a year.

 

I think the last thing the chip companies would want to do is reactivate a function that has, til now, been so problematic that Ford turned it off. The chip companies are selling a ton of units, more than they can produce, without messing with this type of potential problem....

 

That's the great thing about open source. If we want it, then we make it.

In times past, if you didn't like how your truck worked, you could replace parts until you were happy. You could tinker and adjust and spend a good afternoon making your truck better ... or just your own.

Like it or not, times have changed. A screwdriver and a steady hand adjusted the carburator in your 57 F150, but a modern engine requires a computer.

Chips, as good as they are, don't return control of your vehicle to you. If we want control of our vehicles, we'll have to take it by force ourselves.

 

My truck ran fine with p/i .
I think it was deactivated as a quick fix for some other problem with some trucks.

 

Wouldn't you think that the FICM would be the actual part we would need to deal with as far as PI goes? Or is it a command line in the ECM or PCM that has been disabled. I will do some research and contact my friend that works on my truck at the FORD Dealership and see if he has any suggestions. Also, will contact my Uncle who works for Ford and see what he can dig up on why and how PI was disabled and see if it is a command line in FICM or not...........

 

I'll be interested to hear the result of your research. Meanwhile, this is what I suspect:

The PCM is likely a common realtime embedded platform. FMC might make their own, but chances are they pull it somewhat off the shelf. That said, it's probably a low Mhz (8 or 16) processor. It's job is to manage all the engine data and instruct the FICM as to the desired amount of power. The PCM likely updates the FICM on a schedule. It might be 100 times per second and it might be 1000 times per second, but it's almost certainly discrete and cycle (rather than interrupt) based.

The FICM's job is slightly more complex. If you think about it, the FICM, at 4100 RPM is firing the injectors 16400 times per second for regular injection and 32800 times per second for pilot injection. Remember that PI was diabled above 1800 RPM? We'll come back to that.

The FICM will be closely tied to the CPS (Camshaft position sensor). It needs to dispense a pulse to the injector within some tolerance based on the CPS input and the power demand from the PCM.

Now consider the timing involved. At 4000 RPM, a piston completes a complete rotation in 250 us (microseconds). Lets make an assumption that we have to deliver our "shot" within 10 degrees of cranshaft rotation (huge ... I'm sure its more like one degree), then our FICM has to deliver a shot 4000 times a second with 7us accuracy (which would be .7us of accuracy if 1 degree is the margin of error).

That level of timing isn't available with a processor. That's why my design is already talking about ASICs. (These are programable logic chips on which you can easily design arbitrarily complex circuits).

The FICM needs twice as much "power" (complexity) to deal with pilot injection. It's likely that FMC turned off PI at 1800 RPM because it knew that it's FICM was inadequate to run PI at higher RPMs. Turns out it was inadequate to run it at lower RPMs reliably as well.

Now... back to the beginning. The PCM and the FICM are tightly integrated. Without more information, I can't tell you if reprogramming or replacing the FICM alone would make pilot injection work. Likely, the PCM program changed somewhat when PI was turned off in the FICM because the power parameters would change.

 

There are a lot of things to consider on this venture. Warranty. Say good bye with a linux like PCM and FICM. Liability. The first time someone pulls into traffic, the truck doesn't respond the way they think it should and they have an accident using the open source system. What then?

Technically it can be done. I don't think it is practical.

 

Well companies may not be able to avoid responsibility for their products, but individuals can. The licence agreement would stipulate in plain english that the software and hardware is experimental and that it was entirely the responsibility of the user to use it or not. I'm positive that if I posed this question to Eben Moglen (a leading opensource lawyer and council for the Free Software Foundation) that he could come up with the appropriate wording to be in sync with the appropriate legislation.

It's the same thing when some yahoo goes out and installes modifications on his engine. The risks are the same. If someone were to sell the package ... they'd have to get the right legal council and insurance... but the project itself should be able to adequate protect itself.

Consider that the results of our efforts will be some fairly complex to implement blueprints. These blueprints will be covered with appropriate warnings. Can someone sanely say that they could read all the technical information required to implement this solution without being able to read the disclaimers? Heh.

One point in most Open Source software licences is that "we grant you permission to copy this work provided that you don't hold us liable." ... meaning that were you to hold someone liable, you wouldn't have had permission to copy the work --- essentially the lawyers would make some money, but the copyright claim would suck back any money that could be gained by a liability claim. This is just my interpretation of the clause ... it might play out differently... but a heck of a pile of software and hardware is made this way every day. I'm sure we can surmount the legal issue.

 

Technikcally you could make them sign a waiver of all things that could go wrong and write up a disclamer to sign off on...........................