We're pretty close to being done, but you might want to sync up with PeteS160 about turning one of his Arduino add-ons into a boost controller.

 

Quick change to the XDF definition for the VE table and it gets you what most are used to seeing:

 

Applying that same formula to the 603 beta xdf my 3 bar P59 shows the correct VE table now. So if i can find the boost enrichment stuff i could at least likely modify the XDF and test tuning/read/write with the app on my own car. Might be fine as is as long as I don't want to modify that table anyway.

 

PM me your email. I have an EFI live COS .bin that has separate VE tables for boost and off-boost manifold pressure zones

edit: for the 7603 OS

 

II think you may have sent me stuff already, at least some 603 xdfs. Id love to be able to tinker with what I already have if I can get it set up, especially the flex fuel delay and timer stuff that is available in the xdf but not in hptuners.

 

oh thats right. lemme know how that goes...building another turbo car as we speak

 

look at these xdfs.....
just look at it''
http://www.gearhead-efi.com/Fuel-Inj...ed-is-TunerPro

anyone know if the allpro cable works real time in TunerproRT?

 

Release #4 is ready for testing!

https://github.com/LegacyNsfw/PcmHacks/releases/tag/2019.01.16.02

The biggest improvement in this release is that the app will prevent you from writing if the operating system in the PCM doesn't match the operating system in the file you have selected.

If you run it while connected to the internet, it will check github for a new release. Ordinarily it will just say "Thank you for using PCM Hammer" when it starts up, but when have a new release that will change to something like "Hey, we have a new release!"

 

Currently the SD model is based off MAP for load source because it is the table that defines the airflow being consumed by the engine. So if you made the axis load based on airflow you'd get a chasing your tail approach where if you increased the VE table it would also increase the load thus moving you up the table. So ultimately the table is best left as a MAP sourced axis however rescaling it for higher MAP values in the axis would be needed for the boosted guys.

The timing table axis is the one I'm interested in. It would be **** if we could actually rescale the g/cyl axis to be able to take advantage of the real airflow values without scaling. Currently on any boosted applications I scale injectors by 50% which then cuts the airflow model in half. So what used to be 1.2g/cyl is now 0.6g/cyl meaning the table is now good up to 2.4g/cyl. This is rough on some of the auto transmission guy's though because it also cuts delivered engine tq in half which then cuts line pressure etc down. So it's all a work around in some way or another.

 

I'm not sure which table (or tables) you're talking about in that first paragraph. For speed-density, a VE table has RPM on one axis and MAP on the other, by definition. So if that's what you're talking about then we absolutely agree. For the fueling and timing tables, there's RPM on one axis but I don't think it matters whether the other axis is MAP or load.

That said, the existing spark table in my C5's OS uses RPM and load, so I want a fuel table that uses the exactly the same RPM and load axes. I think that would actually be a very simple change, and there would be need for power enrichment or boost enrichment after that. However, there would be a need for a coolant-temperature-based fueling compensation, and I haven't looked into how to achieve that yet. I suspect there's a way to make the PE table for coolant compensation active at all times, though.

Before looking up the value in the timing table (or any other table that uses the same load axis) the OS does some math to rescale the raw load value into something that can be used for the table lookup. The simplest way to create a 3-bar version of my OS would be to change that scaling. Then the load axis for every table that uses the same input would range from 0.8-to-3.6 rather than the current 0.8-to-1.2. After that, the contents of all tables that use the modified load axis would of course need to be rescaled. There are a bunch...

All of these table names came from the XDF that cmaje (from pcmhacking.net) created for 12593358, and all non-alphabetic characters in the table names got converted to underscores:

SurfaceTable_25x29_Spark_Advance_Vs__Load_Vs__RPM_ _Open_Throt__Low_Oct
SurfaceTable_25x29_Spark_Advance_Vs__Load_Vs__RPM_ _Open_Throt__High_Oct
SurfaceTable_37x29_Cool_Comp_Spark_Advance_Vs__Loa d_Vs__Coolant_Temp
SurfaceTable_21x29_IAT_Spark_Advance_Correction_Vs __IAT_Vs__Load
SurfaceTable_17x29_Cat_Lightoff_Spark_Correction_V s__Engine_Run_Time_Vs__Load
SurfaceTable_25x29_Spark_Advance_Vs__Load_Vs__RPM_ _Open_Throt__High_Oct
SurfaceTable_25x29_Spark_Advance_Vs__Load_Vs__RPM_ _Open_Throt__Low_Oct

And probably also these:
SurfaceTable_13x29_Base_Spark_Adv__Vs__Load_Vs__RP M__Closed_Throt__In_P_N
SurfaceTable_13x29_Base_Spark_Adv__Vs__Load_Vs__RP M__Closed_Throt__In_Drive
SurfaceTable_13x29_EGR_Spark_Advance_Correction_Vs __Load_Vs__RPM
And another 13x29 RPM-and-Load table that I'm not sure what it's for, but all the cells are zero anyway.

Edit: I just went down a rabbit-hole about P1514 and predicted airflow, and found this in the HPT forum:
"If you are over 2.32 g/cyl you will get a 1514 no matter what you do to the 1514 table. "
So that would need to be fixed as well, and it's probably a hint that there are other details that will get in the way.
I still think this is do-able though.

 

This may not be the best place to address this but since I get at least 1 email or PM a week asking about this(and I just got 3 in the last 24 hours) I'm just going to go over this here since it's intended use is for the Pcm Hammer/Tuner Pro.

Q: Can I data log with Tuner Pro ?
A: Yes there are ADX files for data logging with.

Q: What tools work for Data Logging?
A: Currently your choices are the Allpro/Obdlink or the AVT-852

There are a couple of "Elm" ADX files floating around for Tuner Pro that offer basic logging capabilities but they are not great and we are aware of this. The ADX uses mode 1 pids, it does work but its far from ideal and doesn't have a very good refresh rate.
There is also an ADX that works with the AVT and uses dpid that is VERY fast but adding additional pids or altering the pids it uses is not easy.

There is currently not a logging option for J2534 tools, however if you have a J tool then it's likely you have some type of OEM software that may be suitable for logging with.

Now the question most people are asking me is... what about logging a wide band ?
Yes there are ways to bring wide band data into Tuner Pro but they are not simple, if your lucky enough to have an AVT 852 with the ADC input there is an ADX that works with some wide bands but not all of them. I do not have the information in front of me as to what wide bands specifically it will work with the way it's currently setup. The ADX can be modified to work with any analog wide band but that would require altering the way it scales the data from the ADC on the AVT interface.

Your other option is to use an existing pid in the Pcm such as EGR and feed your wide band data in that way but it's not going to do any fancy scaling or conversion for you unless you go in and rewrite the ADX to accommodate the range of your wide band.

Creating better ADX options for logging with are on the list of things todo but it's a big list and this isn't something that's a high priority right now.

The 'Elm" command set in general isn't well suited for high speed logging and isn't capable of working with dpid in an effective manner. They also do not provide a solution for wide band logging unless you have removed sensors from your vehicle so you have an open place in the PCM and a corresponding data pid that's active in the OS. Just having an open place to feed the data in isn't enough, you have to be able to read that data from the PCM so the input your using needs to be active. This would be like adding a flex fuel sensor to your pcm and wondering why it's not doing anything.....the OS on the PCM isn't looking for data from it so it's just along for the ride. Getting wide band data in though the pcm is the same thing.

 

To continue in regards to my previous post.....

I have been talking with Envyous Customs about possible joint development of a low cost tool that's similar to the Allpro but that would be able to compete with the AVT 852/J2534 tools performance wise AND that would be able to address logging external sensors similar to how Hp Tuners and Efi Live do. This would be something for people that are looking for more then just basic flashing, if your just after turning off Vats, tweaking trans settings etc then the Allpro/Obdlink is still the tool you'd be interested in. This would be something for people looking for a more complete tool who plan to do actual tuning on their vehicle and will need high speed data logging, wide band data and other external sensors data for builds involving a turbo or NOS where you need to know exactly what is happening to keep the engine from going BOOM

We already created a "Proof of Concept" just to see if this was even feasible and it most defiantly is, cost wise it looks like it'd be somewhere between an Allpro USB and the Vx Nano.

Performance wise the test version we created was 3 seconds faster for flashing then the AVT 852 and 1 second slower then the AVT for reading. Right now were looking at ADC's to see how many channels we could log while still streaming data from the PCM with dpid in Tuner Pro. It's possible we could add serial input from wide bands but since no 2 companies wide bands have the same serial data format it'd run into the same issues that Hp and EFI do when trying to use a wide band....while several may work there is one that just works way better and pressures people into buying what works best rather then using what they have or what brand they want to use.

The question is..... how many people would actual have an interest in something like this? Right now it's really just idea were playing with but if there's interest it's something we could start refining and get things rolling for on an actual design.

 

take my mother effing money right now!

 

Id be interested. I currently use hptuners but would love to have options.

 

Pete, I would be very interested. I'm even open to paying up front and waiting for delivery if it helps.

 

Is there an alternative to Tuner Pro? I have installed it twice on my Windoze7 laptop and when i try to run it i get an error message and it slows the laptop down so much i have to do a system restore to recover.

 

What error message are you getting? Post up a screenshot. TunerPro is something I have used for my OBD1 stuff for a while so I might be able to help.

 

 

This is one of the design concepts we've looked at for something like this. Its far from "Nice looking" but..... it was assembled using recycled parts I had on hand and came out a lot better looking then I was expecting. And yes..... this was a working version not just a plastic shell.

We've done some testing in the Pcm Hammer with it as well and for being something we kind of threw together over the course of a couple of nights it was rather impressive.


Again....this is just something we're talking about still. Nothing has been decided.....while what we threw together just for some testing may sound like it could be ready for use in just a couple of days its not that simple. We were conducting tests in a controlled environment where there were no possible issues to deal with like noise, voltage fluctuations, bad connections or anything else that would present a potential issue when used in a vehicle. It was sticky a "could we do it" and if so "how would it compare" type of thing.

But I do see a couple of comments that make me think there might be enough interest to justify the time and money it would take to build something like this that was of commercial quality