Thoughts on OS improvements

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
turbo_bu
Posts: 55
Joined: Tue Dec 03, 2019 3:58 am

Thoughts on OS improvements

Post by turbo_bu »

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
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: Thoughts on OS improvements

Post by NSFW »

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 technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
turbo_bu
Posts: 55
Joined: Tue Dec 03, 2019 3:58 am

Re: Thoughts on OS improvements

Post by turbo_bu »

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.
User avatar
Gampy
Posts: 2330
Joined: Sat Dec 15, 2018 7:38 am

Re: Thoughts on OS improvements

Post by Gampy »

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!
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
turbo_bu
Posts: 55
Joined: Tue Dec 03, 2019 3:58 am

Re: Thoughts on OS improvements

Post by turbo_bu »

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
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: Thoughts on OS improvements

Post by NSFW »

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 technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: Thoughts on OS improvements

Post by NSFW »

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 technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
turbo_bu
Posts: 55
Joined: Tue Dec 03, 2019 3:58 am

Re: Thoughts on OS improvements

Post by turbo_bu »

Starting over would be an incredibly daunting task to say the least. I guess that why I was hoping to come up with a short list of things that could be done first to make this PCM more useful to most tuners out there. Having a free flash tool goes a long way to enabling more people to use the 0411 for their projects. Making some improvements to the stock code would help make the 0411 even more useful for the different kinds of engines that are being tuned.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: Thoughts on OS improvements

Post by antus »

Debugging is hard. Its not like a pc where you can get a stack trace or core dump and open it in a debugger and see where and why the crash occurred. We do get a BDM (background debug interface) on the hardware, but I dont think that you can pause the whole platform, only the CPU. If someone wants to try it and prove me wrong please do. A lot of these features have been developed in aftermarket OS. We absolutely should not rip off that code but it can give us some pointers as to where our implementation needs to hook the factory code and where to look in the factory code.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
ShorTuning
Posts: 55
Joined: Thu Dec 13, 2018 4:42 pm
cars: 2002 Camaro
2002 Formula
Location: On the Dyno
Contact:

Re: Thoughts on OS improvements

Post by ShorTuning »

I have started mapping out the EGR parameters thinking that I could use the 0-5v input as a target for a boost controller. If someone want's to play around with the paremeters I have mapped out you are more than welcome to give it a go. Some of the scalers and table axis aren't defined either so it's a work in progress still. Descriptions should be accurate for those that are defined.

This XDF is for the 2004 12587603 OS which is compatible with C5, Trucks, Vans, SUV's.
Attachments
P59 (12587603) EGR Boost.xdf
(45.92 KiB) Downloaded 235 times
Post Reply