LS1 Boost OS - Development

[Stokes1114]

Thanks for the quick response bubba. That's exactly what I did in my bin and it's only like 3psi so no big deal. Just making sure I understand it before pushing it. I'm still waiting on my ebc to get here

[Boostedforlife]

Switching to the p59 and a new 4 gen rods cuz I got boost happy. Seen 22 psi on stock motor and found the weak 3 gen rod. On the p01 the launch control seemed a little goofy sometimes it would hold right other times if would go passed the set rpm stall with a super load bang out the exhaust. But it's not a big deal cuz I'm swapping over anyway. Bur super excited for the next release. Wish I was smarter in the coding department to help but just know enough to be dangerous.

[Jonnyoptions]

How does closed loop via wideband work? Sounds really cool and am excited to try it!

[Jonnyoptions]

I did add an additional feature to the OS that's running in my vehicle. I figured out how to use the wide band O2 sensor that I have wired to my unused EGR input for closed loop fueling. Currently I have it so that closed loop is active only when the EQ ratio is 1.0 so when the open loop table goes to a cell that is different than 1.0 EQ it goes into open loop. I haven't tuned any of the closed loop parameters and when just driving around it corrects fairly well. I'm sure with some testing it could be even better.

I believe with some additional work I could also have closed loop active even when WOT.

[bubba2533]

Thanks for the quick response bubba. That's exactly what I did in my bin and it's only like 3psi so no big deal. Just making sure I understand it before pushing it. I'm still waiting on my ebc to get here

Awesome

Switching to the p59 and a new 4 gen rods cuz I got boost happy. Seen 22 psi on stock motor and found the weak 3 gen rod. On the p01 the launch control seemed a little goofy sometimes it would hold right other times if would go passed the set rpm stall with a super load bang out the exhaust. But it's not a big deal cuz I'm swapping over anyway. Bur super excited for the next release. Wish I was smarter in the coding department to help but just know enough to be dangerous.

Yeah, I've had a couple cases where the RPM's would pass the LC setpoint but it's only happened to me in neutral when testing the LC. I'm not sure what would cause it because the code is so simple. The only idea I have is there is some logic that filters the brake pedal switch that could be causing issues. I might have to do some more testing with it when I get my RTLS1 setup installed because the logging rate is so much better.

How does closed loop via wideband work? Sounds really cool and am excited to try it!

Yep, it just uses the factory narrow band code.

Another update is that I plan on removing the OS number change. With this amount of modification you really should know what you are doing so I don't feel like it's protecting anyone, and people have commented about changing back so that standard xdf's and commercial software will still work.

Along with that I'm going to move all the parameters into the unused region of the address space so there will be no overlap with other parameters. The only annoying part about that is for people using EFI Live it doesn't flash that portion of the address space when doing a calibration flash. I'm not sure if there is anything I can do about that. I don't know how HPTuners handles user defined parameters because I haven't paid for it. Hopefully with the 7603 xdf's that are out there now everyone will be able to use tunerpro for their tuning.

[bubba2533]

Ok, so I'm getting much closer on the next version. I've been porting over all of my code from google sheets (not really code lol) into an actual ASM format so that it can be easily changed.

Because of the amount of tuning parameters I can't fit them anywhere in the factory calibration section. By placing them in the upper address range it causes the OS checksum to be updated any time a parameter changes which is not ideal. I'm going to look into modifying the checksum range so that I can put all the parameters at the very end of the address space. At this point I think that is the only option that I have so hopefully it won't cause any issues.

[antus]

That could work. The sum routine in the OS shouldn't be hard to find and adjust and that's what earlier realtime tuning packages, eg 12P and prior to that Kalmaker do. The reason is different - they allow realtime edits in nvram, and the updated sum range means the sum can still validate the OS code without tripping on the calibration when there are changes at runtime, but the precedent is there and i'm not aware of it causing any problems. You could still sum half the OS segment that has the cal in it, just need to exclude your new calibration range.

[bubba2533]

I think I found the address (0x510) that determines the OS Checksum End which is a 4 byte value. I'll modify it so that the last block (0x20000) will be available for the new calibration parameters. This is a huge amount of space and would allow for as many tables as anyone would ever need. I may do a quick test to see how PCM Hammer handles that change.

The next challenge I am facing is finding an unused space in RAM for new variables. If I am able to find an empty area, I won't have to modify anything with the EGR code. I think this would be a little cleaner in my opinion.

[NSFW]

When I was doing Subaru stuff, I wrote a little utility that dumped the entire RAM to a file... Drove around for an hour or so, dumped RAM periodically, and eventually found a big unused space near the end.

It's not 100% deterministic, because it's hard to say whether some random undiscovered error handling routine will store a bunch of diagnostic data up there if something goes wrong, but it worked.

Anyway, I'll write something like that for the P01 / P59. Hopefully it will help us find some space that we can use.

Anyone know what the start and end addresses should be?

[NSFW]

Mode 34 supports 0xFF8000 - 0xFFC000. If that's also the memory range of the RAM chip, I should be able to dump the entire contents pretty quickly.

If the RAM chip covers more than 32k, then it might be worth finding the code that limits the mode 34 range, and then adjust the upper and lower bounds to allow mode 34 requests to cover the whole thing.