Thoughts on OS improvements

They go by many names, P01, P59, VPW, '0411 etc . Circa 1999 to 2006. All VPW OBD2 PCMs.
Posts: 3
Joined: Tue Dec 03, 2019 3:58 am

Thoughts on OS improvements

Postby turbo_bu » Tue Dec 03, 2019 4:04 am

There are quite a few Tuner Pro XDF files out there for most of the 0411 OS's. These XDF files allow for a lot of tuning to be done to a standard OS. Even with all these capabilities there are a few limitations to running a stock ECM. I was trying to wrap my head around what would be needed based on engine configurations.


If you are running naturally aspirated, there are no significant limitations in the OS which would prevent you from running it. Yes, there is an airflow limit, but you can scale the tune to get around it. About the only limitation would be if you would require an alternate rev limiter to the stock fuel cut method.


If you are running boosted and/or NO2, then you would NEED a spark cut rev limiter.

NEED - spark based RPM rev limiter. If an OS was able limit RPM based on spark, then could add other features like a 2 step. One method would be to adjust the spark dwell time to command 0.0 msec. There already is a coarse table (B6001 in EFILive) for adjusting the spark dwell time. Reducing the dwell time to zero would effectively not charge the coil which would in turn eliminate the spark. The existing table has large RPM steps. Would need to be able to command it with a tighter RPM limit.


The two additional hurdles to running boosted are the max air flow limitation and the ability to measure the boost using a 2 or 3 bar MAP sensor. The airflow limit is 512 gram/sec. The other "limit" is the air flow tables only go up to 1.2 gram/cylinder (e.g. - spark table).

I have a theory on how to get around both of these issues by doing a creative scaling of your tune combined with the 2/3 bar MAP sensor. The main downfall is that both the MAP and airflow values would become relative. In other words, your ECM would show ~40 kPa when in reality the engine is really measuring ~100 kPa. But, by doing this hack, you would not hit any airflow limitations which in turn would allow you to more completely use the existing VE, AFR and spark tables. FWIW - Yes, this is basically a version of the old school 2 bar hack that has been done on the older ECM's.



One final need would be in creating a boost controller. This would require a lot of work! Not that adding in a spark based rev limiter is easy. But there is not anything in the existing code which could be easily modified for creating a boost controller. The other issue for a boost controller would be the add-on requests like boost per gear.

User avatar
Posts: 223
Joined: Fri Feb 02, 2018 3:13 pm

Re: Thoughts on OS improvements

Postby NSFW » Tue Dec 03, 2019 2:12 pm

I am really intrigued by the idea of (ab)using sensor scalings to achieve double or triple the MAP and MAF limits. It seems like a pretty straightforward way to do it. We could make corresponding changes to the XDF and data-logging configuration so that the units in the editor and logger would be accurate.

The only thing that worries me about this is that there might be other tables and constants in the PCM code that aren't in any XDFs yet and should be changed, and it would take a combination of trial-and-error, troubleshooting, and reverse-engineering to discover that stuff and figure out how to fix it. That wouldn't be easy, but it seems do-able, if people are willing to try it.

The limiting factor in all of this will just be people. All of this stuff is possible, the big question is who is going to put in the hours that it takes to make the changes.

The same compiler that we used to make the kernel for PCM Hammer can also be used to compile code that we can patch into the factory OS to do pretty much anything we want, so we can write the new code in C rather than assembly. So that will make writing the new code pretty straightforward as programming tasks go. The hard part will be reverse engineering enough of the factory firmware to figure out where the relevant code is in the ROM, and where the important variables are in RAM.

For me the holy grail is rev matched downshifts for throttle-by-wire cars like my Corvette. I have a little theory that the cruise control or PTO features of the factory firmware can be abused to make that happen. They are already capable of opening the throttle while the driver's foot is off the pedal, so... we'll see.
Please don't PM me with questions about tuning or flashing - start a thread instead. Thanks!

Posts: 3
Joined: Tue Dec 03, 2019 3:58 am

Re: Thoughts on OS improvements

Postby turbo_bu » Wed Dec 04, 2019 3:42 am

NSFW

Thanks for replying. I agree that getting people to help will be key to making improvements to the stock OS's. I am still amazed at all the great work that has gone into the lowly 0411 PCM over the past year or two by yourself and others. I was hoping by starting to list out the wants / needs of what is necessary to make these controllers more useful, that the next steps of making patches to the OS could start. Like yourself, I have seen some of the great work that was done on other ECM's/PCM's and was hoping that the 0411 could benefit as well.

It is good to hear that all of the outstanding work that you guys have accomplished was done with keeping it going in mind. I was hoping that whatever improvements that are developed could be somewhat easily implemented into the existing OS's. Or at least a small subset of "common" OS's. There are a few of the more common OS's which we could standardize on which would prevent from having to try and patch them all.

Unfortunately, this brings me to my biggest issue. I am not a programmer. I am 100% self taught on how to read assembly, how the binary files are layed out, how the tables work, and kind of where to find tables. But I am not an expert on making patches. I am hoping that others who know much more about how all this stuff works can help to create some of these needed improvements.

If you want to discuss abusing scalings, I am more than happy to talk about things to try. I am more of a "how to make it work" rather than worrying about making an XDF / logger so it works perfectly kind of guy. To me, as long as it works and works well, then I can live with some of the hang ups with regard to making it 100% polished and ready for production.

The rev matching feature would be very cool to implement. I am not sure how well the PTO function could accomplish this, but it would be the simplest thing to try without having to write a whole section of code.

Posts: 187
Joined: Sat Dec 15, 2018 7:38 am

Re: Thoughts on OS improvements

Postby Gampy » Wed Dec 04, 2019 6:01 am

One of you brainiacs needs to set down to a couple machines, IDA on one side, your favorite tool chain on the other and start from scratch ...

Then there is no 'abusing' needed!

I started work on this a couple weeks ago, then I woke up and reality set in, boy was I disappointed!

Posts: 3
Joined: Tue Dec 03, 2019 3:58 am

Re: Thoughts on OS improvements

Postby turbo_bu » Thu Dec 05, 2019 3:35 am

Gampy,

I agree that the 0411 will never replace an aftermarket stand alone system. BUT, I think that it can be made to do enough for what we all need. More importantly, for those who want / need the PCM to interface with the rest of the electronics in their rides, making improvements to the 0411 would be a huge help. That is why I am very hopeful that those who are smarter can help with making it a reality. I am willing to share what little I have figured out over the years if it helps somebody else who can make the magic happen in the code.

As you noted, the stock PCM isn't perfect, but it can do quite a few things.

User avatar
Posts: 223
Joined: Fri Feb 02, 2018 3:13 pm

Re: Thoughts on OS improvements

Postby NSFW » Sat Dec 07, 2019 5:30 pm

It's definitely tempting to just rip out as much as possible and start over with a pretty basic implementation of fueling and timing (plus startup, idle, maybe a little more). And it's not out of the question. But it would still be a pretty a big undertaking. The first step would be figuring out which bits of code to keep - bootstap, OBD2, input, output, probably a task scheduler, communication with the TAC module (for cars that have them) and the instrument cluster.

Then there's the question of how to interface the new fueling/timing/etc with the existing I/O code. Like once your new code calculates an injector pulse width, EOIT timing, and ignition timing, how do you convey that information to the existing code? It's do-able, I suspect there are just RAM variables that the existing "application" code writes to and existing "device driver" code reads from. But it could take a while to hunt that stuff down.

I can certainly see the appeal, but I lean toward just making small changes here and there to get the functionality that I want... I think that will be less work in the end. I could be wrong. :)
Please don't PM me with questions about tuning or flashing - start a thread instead. Thanks!

User avatar
Posts: 223
Joined: Fri Feb 02, 2018 3:13 pm

Re: Thoughts on OS improvements

Postby NSFW » Sat Dec 07, 2019 5:41 pm

There's enough free space in the P59 that it might be practical to put the new operating system in upper (unused) flash blocks, with just a couple of tweaks in the existing code to make it toggle between the stock code and the new stuff, based on an OBD2 message or a spare input pin. For example if you could find the task scheduler, perhaps you could make it call tasks in the stock code or tasks in the new code. Keep the stock tasks that read sensors and manipulate actuators (injectors, spark, etc), hijack the stuff that calculates fuel and spark, skip everything else...

It could take a lot of trial and error to figure out what needs to be kept and what can safely be skipped. And debugging could be pretty hard.

it's intriguing, but then again it's also intriguing to start from scratch with an Arduino. :) It's hard to say which approach would take more work.
Please don't PM me with questions about tuning or flashing - start a thread instead. Thanks!

Return to GM LS1 512Kbyte and 1Mbyte

Who is online

Users browsing this forum: No registered users and 3 guests