LS1 Boost OS - Development

[Broke4speed]

7603 supports both.

[RADustin]

Does the 7603 OS support dbc or only dbw throttle control?

can do either.

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.

[bubba2533]

Good point!

I always forget that. I only look for PCM’s in the junkyard that are DBC so it can do both.

[Broke4speed]

Does the 7603 OS support dbc or only dbw throttle control?

can do either.

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.

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.

[vwnut8392]

People need to get on the Patreon...V4 is kick ass .

Thanks!

For anyone wondering here is the feature list for V4:

• 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

Now to start thinking about V5

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!

just a suggestion but if you do this for the P01 ECU's that dont have wideband you could have a form of boost acceleration fueling that when the ECU cross exceeds a certain boost pressure the lambda control is forced off and the ECU does all of its fueling from the VE table. i know this strategy works because i've done it in old audi motronic ECU's. once again just as suggestion and something to add to your list of stuff. i would suggest hijacking a spare ADC from like a downstream oxygen sensor for external wideband input to give the P01 that feature but you'll pull your hair our trying to support all the different variations of wideband controllers on the market. trust me, i went through that mess in the german car world already.

another thing you might want to consider is a configurable dwell time variable for all of the spark cut related functions. 0 is extremely aggressive and gets even more aggressive when timing retard is added. you can soften spark cut functions by setting dwell to 0.1, 0.2, etc. i've blown a muffler or 2 apart with the launch control but i like it extremely aggressive.

[bubba2533]

Someone just asked about tuning for nitrous, so I'm looking to see if others would also be interested in that.

I started a post on my Patreon to get ideas for features and/or what nitrous product/controller could be replaced with a few simple features.
https://www.patreon.com/posts/intereste ... =join_link

I haven't used nitrous myself, but I'm not against adding support for it (even though I called it Boost OS lol).

[bubba2533]

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.

Code: Select all

(YOUR CURRENT EQUATION)*0.14503773800722-14.6959494

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.

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.

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.

Thanks kur4o! That pretty much sums up my thoughts on flashing, parameter space, and using HPTuners.

As for the units, it's really a TunerPro issue because it only allows 1 set of units to be displayed. I'm really surprised there isn't at least 2 units that can be configured for a parameter (for example kPa and psi). I'm not sure if that feature was requested, but I've submitted a couple feature requests on the TunerPro.net Forum so I might create one for that to show that there is interest in it.

As for having the user select the map sensor when patching...I did think about doing that, but purposely didn't incorporate it. I wanted to keep the patch tool very simple and make sure it would accomplish the job I wanted it to do. For the most part I think it was a huge success and it's done exactly what I wanted it to do which I think is pretty good for my first C application I've ever created from scratch. I don't really think adding that functionality would help much since you still need to open TunerPro to make changes and create a base tune, so I probably will keep it as is.

I do appreciate the feedback, but I feel like I have already thought of many of these questions, but just didn't document all of the reasons behind them or they are buried way back in this thread.

[antus]

Yeah the CRC32 of the flash segements was designed as an optimization, but not specifically for this purpose. But it works beautifully. It'll never erase and write a flash sector it doesnt need to, so a full OS flash for a cal change in another part of the chip isnt a full chip erase and write, and notably wont touch the boot sector either. Its a major point of difference between pcmhammer and the commercial products that do a chip erase including boot then write it back, which opens up risk of brick if something goes wrong while the boot sector is not intact.

[Knackersjewels]

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

[bubba2533]

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

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.