Inexpensive Opensource Flashing(Read is 100% working)
01-15-2019, 02:25 AM
#401
You guys make my day. I am a mechanical engineer (MSME and PE), design prototype engines, test and calibrate them in our engine dynamometer facilities and run a business tuning LS cars with HPTuners. I know my missing link is programming/coding. I have a minimal amount of knowledge, and have our EE's to leverage at work, but have started getting into Arduino a month ago before I read this thread. I will start using what you have and provide feedback when I can. I am taking some programming courses now for my own growth. Shoot me a PM, maybe I can help. I would like to push this with you guys. thanks in advance and keep up the R&D!
01-15-2019, 02:52 PM
#403
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.
01-15-2019, 10:41 PM
#405
01-16-2019, 05:25 PM
#407
Staging Lane
iTrader: (3)
Join Date: Oct 2007
Location: Burlington, NC
Posts: 56
Likes: 0
Received 0 Likes
on
0 Posts
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?
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?
Last edited by windsma; 01-16-2019 at 05:45 PM.
01-17-2019, 01:31 AM
#408
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!"
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!"
Last edited by NSFW; 01-17-2019 at 02:09 AM.
01-23-2019, 04:25 PM
#409
I'm pretty sure PE and/or BE works for everybody in the LS world.
But, coming from a platform were the fuel table and timing table both have RPM along one side and load across the other side, they both seem like unnecessary complications.
If you want more fuel at X RPM and Y grams, you should be able to just tweak that cell in the fuel table, same as you would for spark advance.
But, coming from a platform were the fuel table and timing table both have RPM along one side and load across the other side, they both seem like unnecessary complications.
If you want more fuel at X RPM and Y grams, you should be able to just tweak that cell in the fuel table, same as you would for spark advance.
In the Subaru world, we'd just change the airflow axis so that it goes as high as we need it to... but we were lucky that Subaru's operating system makes that really easy. The table axis itself is just a simple table, so you can put whatever numbers in it that you want. And each fueling/timing/whatever table has its own axis sub-tables, so you can change the axis of one table without affecting any others. Of course you have to rescale the contents of the table when you do that, but rescaling is not something you do very often.
But, for GM.... it looks like if I change the airflow scaling for the timing table, that will also require rescaling a few other tables, and I don't even know what those tables are for yet, so this isn't something I could actually do any time soon.
But, for GM.... it looks like if I change the airflow scaling for the timing table, that will also require rescaling a few other tables, and I don't even know what those tables are for yet, so this isn't something I could actually do any time soon.
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.
01-24-2019, 12:01 AM
#410
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.
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.
Last edited by NSFW; 01-24-2019 at 12:32 AM.
01-24-2019, 01:24 PM
#411
TECH Enthusiast
Thread Starter
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.
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.
01-24-2019, 02:01 PM
#412
TECH Enthusiast
Thread Starter
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.
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.
01-24-2019, 04:00 PM
#415
Teching In
Join Date: Jul 2018
Location: Fort Collins, Colorado
Posts: 22
Likes: 0
Received 0 Likes
on
0 Posts
01-24-2019, 04:00 PM
#416
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.
01-24-2019, 06:09 PM
#417
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.
01-24-2019, 11:13 PM
#419
TECH Enthusiast
Thread Starter
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
Spoiler!
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.
Spoiler!
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
01-24-2019, 11:38 PM
#420
