PT3/PT6 Tuning Software

[cloudasc]

I am very interested in this but being unable or willing to tune my own engine ( I can't take the risk of killing my engine trying to make it faster) but is there anyone that is dyno tuning your software or is it just if you can tune this is a great looking kit for them?

I believe in the keep is simple stupid (KISS) mentality. If there is a way to make the software usable to a greater audience, its very well possible I would impliment it. Right now the software is still in early development stages, but when it is released, it could be used on the street, or on the dyno is the goal. Unfortunately theres still alot of things that need to be figured out in regards to the programming of these ecu's, like figuring out a way to datalog. I eventually plan to attempt datalogging myself, but I do not have the required hardware, which hopefully a couple of the initial sales of the software will help fund. If I had access to enough sensor information from the ecu's, and with the help of several tuners, I might be able to impliment an "auto-tune" option, but that is not feasable at this time.

[cloudasc]

Spent the last 6+ hours working on the software. The licensing portion of the software is pretty close to being finished; the software is now reading my "special" license files without hiccups! I just need to include have it include one more piece of information, and it should be set.

I would say the licensing portion of the software is about 80% complete, all thats left is the challenge key information that locks it down to specific hardware id's (which by the way is successfully being generated by the software).

I also spent a little bit of time making a splash screen for the program.

The string of numbers and letters in the bottom left is an example of an installation id.

[cloudasc]

One sad thing I'm realizing, it may not be possible to datalog from these ecu's (using a stock bin) as our cars never came with an scs connector, so when it comes to datalogging, the code to run it will have to be added. Either that or figuring out how to turn on/use the cn2 port.

Does anyone know if any of the other chassis' in the different markets that use a pt3/pt6 might have a scs connector?

I may be stuck finishing what I can for the pt3/pt6 side of my code, and move onto the p12/p13 family as there's a lot more info on the matter.

There may be a hiccup with the datalogging the pt3/pt6, but that shouldn't interfere with integrating real time programming code into my software, just need to get an ostrich/demon, and start playing with / learning serial communication.

[GhostAccord]

Do the ECU's have the same CN2 port that all the other OBD1 ECU's use for datalogging?

If the board has an LED and the CN2 port you should be able to datalog. I would love to help more but I don't have a PT3, PT6 or P12 ECU here. I only have the OBD1 P13 - P0A and the usual Civc/integra ECUs.

[cloudasc]

Do the ECU's have the same CN2 port that all the other OBD1 ECU's use for datalogging?

If the board has an LED and the CN2 port you should be able to datalog. I would love to help more but I don't have a PT3, PT6 or P12 ECU here. I only have the OBD1 P13 - P0A and the usual Civc/integra ECUs.

Yes the ecu's have the standard 5 pin cn2 spot on the circuit board (although 4pins are only used).

---------------------------------------------------------
Contributed by sicknastyb17
There are two boards number. It looks like the older ecus with the led cel indicater on the board use the denshigiken 6101 board and the newer ecus use a denshigiken 1190.

The only difference I can see in board design it the led for the cel reading and the older 6101 use motorola ics with the oki m66911 processor the section of resistors to the side of the processor are number 320-329 and 340-341.

The newer boards do not have the led cel reader and use all toshiba ics with the same oki m66911 processor and the section of resistor next to the precessor are number 1-9 32-33.
-------------------------------------------------------------

My buddy Fuse with the engine simulator has already tried pulling information through the cn2 connector, but has been unsuccessful to get any information from it. He also tried rigging up the equivalent of an scs connector (pin D7 on the ecu), and nothing. I went through the helms manual for the ecu troubleshooting information, and there are no procedures listed to datalog through an scs. The best diagnostic item you can get your hands on is the test/intermediate harness (plugs in between the ecu and the cars harness, allowing you to probe different pins on the ecu).

[MRX]

Great job cloudasc! I'll help in anyway I can. The ignition table you have looks like it should be right. The stock accord calibration that I developed looks very similar to the table you're showing. Also, I have a Gude and Jet accord map that I can send you as well. You might be able to get some extra answers using the maps. Just PM me your email address and I'll get them over to you.

Subscribed!

[cloudasc]

^^ Thanks for sending me those basemaps, they will definately be useful as a reference when needed.

I just spent the last several hours trying to figure out / testing different formula's for the fuel maps, but to no avail. After some researching, I have some doubts as to the validity of the fuel map locations due to other ecu base's calculate their values totally differently, although the visible pattern suggests otherwise.

As you know I've been saying I would possibly branch over to the p13 codebase to try and help figure things out for the pt3/pt6, well earlier I loaded up a p13 rom into my software, and started taking a look at the structure of the rom, and the maps, and just like as posted on the pgmfi.org library, after I switched my 16bit viewer to "little endian", I managed to verify the locations of the rpm scales as noted on pgmfi.org. Now familiar with what to be looking for, I dug into one of the many pt3/pt6 roms I've aquired, and just after the last documented memory location (for the maps), I find this:



I've highlighted one of the rpm scales, its 20 wide (perfect for my 20 wide fuel & ignition maps), and theres another one right after it, identical. Can you say High & Low Cams!

The formula to calculate rpms is rpm = 1875000 / stored_value

So the scale is as follows:
500, 699, 849, 1000, 1300, 1500, 1799, 1998, 2226, 2500, 2701, 2995, 3498, 3997, 4496, 5000, 5498, 5990, 6510, 8012

The memory location is: 6E06 (4 Fuel, 4 Ignition, 2 Maf/Map Roms) and 6D04 (6 Fuel, 6 Ignition, 4 Maf/Map Roms)

Besides the obvious use of these scales to know what part of each map your "tuning", with this information it would be possible to tweak the scales to allow tighter/better tuning of the higher rpms, but in doing so would skew the default values (as their meant for the current/factory scales), so you would have to adjust EVERY value accordingly.

[djcaz_aom]

Great find!!! Can't wait to start tinkering with this!!!.

[MRX]

I want to get the software so I can take a look at the MAF Load tables. I think they might be the advanced settings like the IAT and ECT curves for fuel compensation.

[cloudasc]

^^ Well theres plenty of examples of the MAF tables for you to look at on the wiki. Just pull up the stock programming pages.

The maps were labeled as "maf load" from a previous person who worked on these ecu's. Even though our cars don't have a maf sensor, but map sensors. Yes it has bugged me from the day I first saw it

Whats interesting is theres two different types of roms, lets all them TypeA & TypeB.

TypeA has 6 Fuel, 6 Ignition, and 4 Maf/Map Load Maps.

TypeB has 4 Fuel, 4 Ignition, and 2 Maf/Map Load Maps.


I have yet to figure out why there are two roms with different quantity of maps, its not related to region, and its definately not related to transmission type, my best guess is TypeA is the original, and TypeB is an optimized version. Why there are so many maps, and what each map exactly correlates too is still a mystery, but my software can edit them.

My current task list:
1. Finish Licensing Mechanism (Challenge/Authentication)
2. *Completed. Finish Ignition Formula mode deconversions
3. *Completed. Add RPM Formula mode conversions/deconversions (copy and paste ignition formula code, and tweak the formula's for RPM).
4. Incorporate RPM scales into fuel & ignition maps
5. *Completed. Change the way the map viewer values are populated for the map, eg reverse load order, and/or switch columns for rows, because in Japan they read things differently; it will also make it so the layout is similiar or uniform to other tuning solutions.
5. Write map saving routine (file saving routine already written)
6. Release to Engine Simulators
7. Incorporate/Address Simulator Findings (loop steps 6 & 7 until deemed safe/accurate)
8. Release to Beta Testers for Real World Testing
9. Release to Public

[reklipz]

cloudasc, do you still need someone to help with interpreting the disassembly? I think I might be able to help with that if you need. I've got experience with both hardware and software; let me know!

[10thAnnivCB7]

This is big man. You have got to be very smart to come up with something like that. Anyways can't wait to download this

[cloudasc]

cloudasc, do you still need someone to help with interpreting the disassembly? I think I might be able to help with that if you need. I've got experience with both hardware and software; let me know!

Yes please!

On my wiki, is almost everything to get you started. Theres the viewer, the disassembler, and I've done individual disassembly dumps of every rom I've aquired. Just remember, the dumps that were run, do not interpret what would be raw data / tables, so theres a bunch of junk in the file, and calls that don't make much sense. It is on my to do list to have a feature of my software that can blank out sections of the file that are known tables/scales/etc so the disassembler dumps can be outputted much cleaner. Oh and if any of the links don't work for whatever reason, feel free to pm me.

This is big man. You have got to be very smart to come up with something like that. Anyways can't wait to download this

Well the formula for fuel is still not understood, I have a couple other idea's floating. I plan on releasing the software eventually, like I mentioned I have a few things I need to finish, but I haven't really had the time, because I am working more then 40 hours a week for my job, and I also have a 6 week old son.

[cloudasc]

Its been a while since I have been able to do anything with my software. I have spent the last several hours working on it. My view changer subroutine was getting rather large and over complex, so I broke it down into smaller subroutines. I have also added a view mode that uses the RPM formula on any 16-bit map. I also now have added a 16-bit hex editor to my software just to be able to apply the formula to an entire file. Below is a picture of my 16 bit hex editor in RPM formula mode.



Once again the ENDIAN switch comes into play to view this map. For the above picture, it is in "little endian" mode, as the BIG ENDIAN switch in the top right isn't selected. For more information on ENDIANESS, please click here.

Also I created a copy of my original map loader routine, and tweaked it so it loads the maps in reverse order. This way when the scales are applied to the maps, it will conform to our left-to-right reading standard for english speaking users. I might implement an accessability feature later that allows the use of either loader method. Anyways below is a picture of one ignition map with the ignition formula active reverse loaded.

[10thAnnivCB7]

You have got to be a genius. Good to see you're still working with it.