Re: LS1 Boost OS - Development
Posted: Tue Apr 18, 2023 11:06 pm
7603 supports both.
Electronic Fuel Injection - Developement & Tuning
https://pcmhacking.net/forums/
can do either.Cincinnatus wrote:Does the 7603 OS support dbc or only dbw throttle control?
They're more rare in yards now, but the early Silverado/Sierra hybrids also have useable DBC/DBW P59 PCMs. I use one on my DBC car . The early Hybrids used a separate motor controller, so the PCMs are not connected to the EV system.RADustin wrote:can do either.Cincinnatus wrote:Does the 7603 OS support dbc or only dbw throttle control?
It's more important your hardware can support DBC. Look for a service number from a van. It'll have IAC components and discrete AC logic control.
first of all nice to see that someone actually did something with the seed i planted several years ago with in ECU launch control and spark cut functions. good work!bubba2533 wrote:Thanks!Broke4speed wrote:People need to get on the Patreon...V4 is kick ass .
For anyone wondering here is the feature list for V4:Now to start thinking about V5
- Selectable N/A, 2 bar, 4 bar VE Table
- Boost Spark Adder
- Open Loop Boost Control
- Wideband Closed Loop Fueling
- Wideband Scaling
- Wideband Fault Delay Time
- Launch Control (Soft & Hard Limit)
- Timed Launch Spark Adder
- Flat Foot Shit
- Spark Cut Engine Speed Limiter (Soft & Hard Limit)
- Desired Air/Fuel Ratio
- Gen 4 MAF Calibration Table
- Disable MAF Fueling (Speed Density)
- Over-Boost Spark Cut
vwnut8392 wrote:after looking at disassembly of your V3.4 i have a couple suggestions. why are the constants/tables after your code? this would make the user have to do full write of the ECU every time with PCMhammer. why not move them into the calibration area instead so than just the calibration alone can be written a lot faster when making adjustments/tuning the variables. with the VE table for speed density i really dont see a need to have individual tables for each MAP sensor size. could just rescale the MAP pressure axis instead for 1 table and save some room. also the original VE table is plenty sufficient in size so its pressure axis could be rescaled to suit each MAP sensor. Im sure there are tables and constants that can be disabled or re-purposed in the calibration area to make room for all of the additions. like instead of having a high octane and low octane ignition maps why not make the ECU just read the high only and reuse the low octane ignition map for a VE table if you want larger axis's for more resolution?
also it it is very possible to auto calculate the MAP pressure axis automatically based on bit pair in the BIN file. like pick input 0 that would work for 2BAR MAP sensor. 1=3BAR MAP sensor and 2 for 4BAR MAP sensor and after that your axis displays properly for that sensor. i dont have time to elaborate on the specifics on how to completely do it but it can be done. with a method like this implemented you only need 1 VE table that does everything and eating up less code space.
another idea would be to make the user pick what MAP sensor is being used in your patch program and it inputs the right axis for that sensor on all of your tables.
also the choice of units of measure in the XDF would be nice as well. to make most if not all of your pressure based axis's and pressure based constants to read in PSI relative to atmospheric pressure like us americans like to use you can just modify the current equation like this.just put the current equation in brackets than multiply by *0.14503773800722-14.6959494 and it will display perfectly in PSI relative to atmospheric pressure and stay 1 to 1 with the old equation. for example if your at 0 in PSI relative it would be exactly 101.32500411216033 KPA.Code: Select all
(YOUR CURRENT EQUATION)*0.14503773800722-14.6959494
your on to something here but it just needs to be refined more.
lastly i changed the OS ID back to stock in one of your patched BIN files and HPtuners has no problem with it after that. works totally fine.
Thanks kur4o! That pretty much sums up my thoughts on flashing, parameter space, and using HPTuners.kur4o wrote: I will try to get you some answers without being affiliated with the boost OS in any way.
You need full flash only once to update the checksum addresses. After that it is partial flash with only the segments that needs changing, usually the stock cal segment and the new patch segment.
With almost half the chip blank you are not really concerned about space, so no need to shrink anything to fit, you can even fit almost a second OS there. Program will write only the new segment, and trying to fit that much data in existing calibration area is not worth it. That`s why the 512kb pcm just drop out of the box, not enough space for all the goodies.
Hp tuners can work but if the checksum areas are changed you are looking for troubles.
For scaling and code optimization only bubba can give you more info.
It would be quite a bit of work on my part to reverse engineer the OS, modify the custom code to patch correctly, and update the XDF. And if there isn't a fully developed XDF for that OS it may be difficult to tune.Knackersjewels wrote:How hard would it be to convert to an AUS OS?
Although I guess it probably doesn't matter, I can run a silverado OS and retune