After doing some research and talking, the consensus is to develop an odb1 mask that will effectively run the odb1 ecm, without the bs or hassle of the current source. While we will still be decrypting the current bins, i believe we can get much more out of this ecm, including boosted tuning, and larger tables, more fine tuned tables etc.....

I will be setting up a site here in the next few weeks and posting our current source code up to this point. This is a call out to any open source programmers with assembly and motorola experience, who want to do a complete re-write on this ecm.

The goals of the project are:

1. Develop a completely royalty free code that is true open source, completely documented.
2. Allow the use of common GM odb1 ecm's with the open source mask.
3. Allow the use of different types of scantools to read the ecm, including 8192 ALDL, and perhaps other protocols as implemented.
4. Create a ECM that can be easily be connected to, monitored, programmed on the fly, and that can autocalibrate itself.
5. Give Jbody another option to the popular megasquirt package in odb1 as well as possibly a code port to support sudo odb2 type applications.
6. Allow for injection upgrades/ignition upgrades, sensor swaps.
7. Any other goals and purposes for which the hobby was created.

My idea is to implement a new source within the next 2 years, utilizing odb1 technologies to develop a top of the line ecm. This means that eventually we may see ecm/tuning packages for sale that include the ecm, connector hardware, licenced copy of tuner pro rt, all software support...

Anyone let me know if your willing to contribute to the project. I'm not sure if the GM ecm can make use of modular programming, but i do know that contriubtors could design subroutines for each ecm.

good idea! did you make a post on quad4forums as well? i think to make this work we should look at 1 piece of hardware and design support for a set of sensors off that. then add boost and such. I'd be willing to help.

be sure to have on your site :

1) the licence by which the source code can be released (GPL2?) and make them agree before d/l
2) methods of implementing such software (exact ecm type sensors etc)
3) the pinouts and voltages of the chosen ecm
4) some type of revision control (svn)

thats all i can think of right now. more tuning solutions are never a bad thing. g/l



Sven you totally quarterloafed your computer..

Please consider these issues:

1) Megasquirt will become less popular with JBO crowd as more tuning companies offer support for the OBDII ecm.
2) There is only (1) 3rd gen car using an OBDI ecm. If you continue to use OBDI, the majority of your market will be gen 2 cars.
3) The only J car requiring the moisture resistant OBDI ecm is the 95. All other OBDI J's use an in car ecm
4) The only J car using the P6 processor and OBDI is the 95.
6) The only J car with OBDI and an instrument cluster which is very dependent on the ECM is the 95.
7) The 95 J code will not communicate with later CAN instrument clusters, which are used around 98 or 99.

P4 code can be moved from ecm to ecm. Hardware functions, if present, are at the same address in most ECM's. The same may be true for the later ecm, but there's plenty more research to be done before this can be answered definitively.

IMO the answer is to use P4, readily available, or get to work on the OBDII code and strip it of unwanted sections. I'd venture to say that stripped OBDII code would tend to gather interest from non J areas as well. With a "portable" code you'd draw in racers and "hot street" guys as well as people looking to do engine swaps using a later engine / transmission package without spending big $$ on tuning software. And finally, you might even be able to start with something like F car code which is better known, and strip and adapt it to the J ecm. That would allow separate calibration / OS changes.

My $.02. I'll help with open source however it goes. Hopefully the magnitude of this project fails to escape enough people that the project will gain momentum.

-->Slow

slowolej wrote:Hopefully the magnitude of this project fails to escape enough people that the project will gain momentum.

very very true.. this is no small project even with a FULLY decoded bin.

a bin file from a later ecm might be useful. HPT supposedly allows for flashing/reading the OS. If I can get you one I will.



Sven you totally quarterloafed your computer..

Its nice to see some support.

All viewpoints and opinions will be of course included as part of the project. I plan on setting up a forum as well as url for the project. My thought on the p4 is that the 0D code is already ported to the 2.2 because of the S10, and the 2.3 would be a matter of figuring out fuel and timing for a slightly larger engine. I believe we could also make this ecm work on the 2.4.

The biggest reason for both open sourcing this project and developing a custom os has to do with eliminating ODB2 as it's only true function was government mandated to eliminate smog emissions. Since street/tuners while somewhat concerned with smog dont usually use a majority of the control code, we can strip most of it out and build a custom os designed for power/economy easily and cheaply.

The 6395 ecm may be one of the first ecm's in the project because it has a fully commented 0D code lisiting hardware addresses, but also realize that the 6295 p6 is a prime target for open source and dercryption because of it's relatively new and close link to new technology, and it's watertight case. I do realize that only the 95 3rd gen even requires water tight, but that does not mean that the electronics cannot be ported to other years.

Someone had mentioned something about instrument clusters. Will installing the p4 interfere with the cluster operation. I guess we may find out, but my fear is that on my swap i will either have to get an earlier cluster, or calibrate the 0D to my cluster.

I will post when the site is set up, this is no small undertaking but in the end will be worth it if it gives everyone an alternative.