Printable View
I've instaled a couple dozen Custom OS's on the low side. Now ever since I upgraded to 7.3 and the new cal's the Eight I've tried since :damnit1: have failed to start. All the vehicles have failed to start because they were flooded.
See the script attached... Currently I haven't been able to get a vehicle to start using a #3 version of the custom OS. Wondering why...
I had the same problem and B3647 was in the wrong units. My car would not even start. I had 14.7 in there and should of been 1.0. I am also using OS 3.
Bill
Good guess BowlingSS, but thats not it. I'm hoping that the cal files were corrupted during the download process. I've got another tune to do today so I'll find out.
http://home.comcast.net/~dennisg2/ws...0/site1031.jpg
Good luck. Hope you find it soon.
Bill
:grd:
move table b3604 to all 14.7 It should fix that rich start up issue.
Now I don't feel as bad knowing I am not the only one that had a no start V7.3 custom OS issue!
Still don't know what it was as Jesse bailed me out with another file!:thankyou2:
Howard
Did this fix the problem?
I took this from a running stock tune. Left the values alone as it started without the custom OS. With the custom OS it was a non starter. I think I tried this already but I'll give it a go today and report my results http://home.comcast.net/~dennisg2/ws...0/site1034.jpg
I see your point MN C5, if you have a tune that started fine before, then I doubt it has anything to do with "normal" tables that haven't been changed. I would look more into the additional OS tables as well as maybe something different about the coding that is causing the trouble. I would say that if it started fine previously and you copied it over to the new OS identically, then it has to be in the Custom Calibrations.
May not be. For what it's worth, I noticed that when switching from Mass Air to Speed Density, the VE table has to be changed considerably-- even if there are no other changes. Can't speak for Custom OS3, I've been playing with OS2. I did a straight conversion from stock to Custom OS and the car ran the same. Switched from MAF to SD, and had to completely redo the VE table to richen things up.Quote:
Originally Posted by Black02SS
If it was done before wihtout a maf and started fine, put the Custom OS in and it doesn't, then its in the OS. 90% of us don't know what a MAF is. ;)Quote:
Originally Posted by dfe1
Yes, we do know about MAFs, :bash: but my point is that after switching to a Custom OS and making no other changes, the car ran just like it did with the original OS (according to data logs). When I switched to SD, with no other changes, the LTFTs jumped a bunch. There is obviously a difference in the way the system processes the VE table in SD versus Mass Air mode. Nothing that can't be corrected with a little tuning, but tuning does have to be done.
This is what I am saying, some of us don't have a MAF on the car anymore. I personally noticed that when I went from my "tuned stock" tune and changed it over to OSV3, my startups were a lot worse. I have had to fiddle with them to get straight. I don't think, if nothing in the OS has been touched, we shouldn't have to do this. Nothing should change on the car side if the tune is the same as the one you put in before, except you have a few more tables now.Quote:
Originally Posted by dfe1
I don't agree. I don't mean to imply that this is the gospel, but in my experience, the LSx engine control system is not a "pure" Mass Air system. It's more of an interpretive system that uses both predicted and measured air flow to determine fuel and spark control. When actual air flow data is eliminated from the equation, the system obviously has to rely fully on predicted air flow (VE table-driven). If I switch back and forth between my Custom OS2 MAF and MAFless tunes, the car runs the same and LTFTs are really close, but the VE tables are completely different. My guess is that under normal circumstances, the MAF input is compared to predicted data and if it's within range, more reliance is placed on MAF than predicted data. I don't know this for certain, but I'd guess the arrangement is similar to the sliding scale used between the high and low octane fuel tables. Consider too that the spark tables are referenced to air flow readings. If there's no Mass Air Flow sensor in the system, how is spark controlled? Obviously, the system has to rely on computed air flow, based on load, (MAP) rpm and TPS voltageQuote:
Originally Posted by Black02SS
By comparison, a pure Mass Air system, such as the ones used on the 1986-89 Tuned Port cars, relies exclusively on MAF sensor data, and doesn't even have a VE table or a MAP sensor. The LT1 Mass Air systems do have a VE table and MAP sensor, but this appears to be strictly for back-up purposes in the event of a MAF sensor failure. Changes to the VE table seem to have no effect if the MAF is functioning properly.
Maybe it's me, but if the VE table is set up in SD mode plugging the MAF in should have essentially no effect on trims or anything else. If it does it would seem like the MAF table, B5001, is off and the trims are correcting for that. Now if something in the intake tract has changed so the flow the MAF sees is messed with, increased reversion or something that pushes the air to one side of the MAF there's no telling what might happen.
Ira
I think this thread got way off track. Here is what I am saying regarding the first post. If the car was dialed in Mafless with a stock tune, you transfered all your existing tables over to the custom os and it now it doesn't start the same way, where is the problem? Theoretically IMO it should start in the same manner as before.
FWIW I had this exact problem. It was well weird. It turned out that the .cal files for the custom os were not overwritten by the install and didnt match the .tun.
Maybe you should check that the cal files are in the right places.
This may be a stupid question but when you go a set a new custom OS tune for the first time;Other then loading in the custom .tun file that matches the current OS, does the .cal file also need to be dragged into the picture??
All I did to start the custom OS process was open up the appropriate custom 2/3Bar SD OS and flash it into the PCM, and then load back in a stock matching .bin file. Once you double check some of the "sane" values it theoretically should at least start....
:nixweiss:
Mine looked right, but it wasnt. You can check the cal version. Should be 7.74 now.
The OS needs to match the cal. I think the .tun is the binary file and the cal is the "filter" which interprets it correctly. If they dont match weird stuff can happen.
Anyone having fuel issues, please check the value of {B3601} "Air Fuel Ratio for Stoich". It should be 14.63
Some old *.cal files had an incorrect max limit of 1.0 which forced it to down to 1.0
If that has happened the PCM will attempt to command 1:1 AFR (way too rich) when it should be shooting for 14.63.
If that valus has changed, please change it back.
Unrelated, the {B0106} "Crank:Run Blend Ratio" may also get incorrectly altered to 1. It's stock value is 8.
Both of these two limits have been corrected in the latest *.cal files. But the *.tun file you are using may have been altered previously using a faulty version of the *.cal files.
Regards
Paul
:thankyou2:
Thanks...guys. http://home.comcast.net/~dennisg2/ws...0/site1035.gif
This was my problem, my {B3601} was set at 1, I had a excessive rich no start. If this happens to any of you, after you correct the problem, you have to hold the throttle wide open to clean it out to get it started. Otherwise, it won't start and you may think you still have a problem. (Unless the motor has sat for a while)Quote:
Originally Posted by Blacky
Question: my {3604} and {B3605} tables and maybe others are in Lambda, I use AFRs in my LM1 wide band, is this a problem? How do you change these tables to AFRs.
Thanks, Curt
Open FlashScan.
Edit - Properties (Alt+Enter)
Under Display you have the option in the middle section to switch between AFR, Lambda, and EQ
Got it Chad.Quote:
Originally Posted by Black02SS
Thanks, Curt
Not a problem.
I hate figuring out lamda readings. AFR is so much easier to absorb!Quote:
Originally Posted by Black02SS
Make sure you read the section in the latest Scan Tool manual about how delta fuel tables may not always be accurately displayed by EFILive as AFR.
Appendix-B, page 79.
(Thanks to BlackO2SS for asking the right questions and prompting me to write appendix-B).
Regards
Paul