Anyone worked with the 16196397 yet?

[RobertISaar]

good progress done sporadically throughout the day. noticed that I'm going to end up changing the main spark table as well.... luckily, it is already 17x17 and the MAP scaling is already sufficient(20-100 in 5kPa increments), but spark is 400-4800, 200 RPM increments from 400-2400 and 400 RPM increments above that. I'm going to add in a patch that changes the RPM scaling from 0-6400 in the same space, i'll just have the tables listed next to each other in the XDF with some notes in both to indicate which one should be used. currently making a spreadsheet to allow easily changing from the existing table to the new table scaling(just copy/paste instead of interpolating and extrapolating from existing values).

as-is, I have the code setup for the boost VE and spark tables ready to go from 100-300kPa in 12.5kPa increments, though I'm considering allowing it to go 100-200 in 6.25kPa increments for anyone who wants to use either a 2 or 3 BAR sensor, but doesn't plan on exceeding 200kPa.

also considering changing the existing Main VE table as well.... RPM scaling is fine here(0-6400 in 400RPM incs), but MAP is 15-50kPa in 5kPa increments, then 50-100 in 10kPa increments.... table would have to be relocated though, i'll need to see what kind of space I have to work with after the other stuff is finished.

[Xnke]

That's awesome. Honestly, 10kpA increments from 50-100 is fine. I use similar scales a lot in the Megasquirt world-unless you're running a cam that really doesn't make much vacuum then all your fine tuning is usually under 65kpA or so. Above that, 10 or even 15kpa per increment is perfectly usable, as long as the tables are being interpolated.

I sat down and took a look at re-learning what I'd need to know the other day-would have been january before I felt ready to tackle something like this!

The spark table sounds...odd. But, there really isn't much need to add or remove timing advance past 3000ish RPM in most engines, so I can see why it was done that way.

Whatever you come up with-I am 100% certain it will be perfectly usable. Making this PCM boost-capable opens up a huge window for the Camaro/Firebird folks who want to turbo their car, but don't want to do a complete OBD1 wiring swap. (also Beretta, as the manual trans PCM I have is from a 3100 powered beretta!)

[RobertISaar]

with nAst1, I have the fuel and spark tables run up to 8400 RPM.... currently in 200RPM increments from 2000-up(and 100 RPM from 400-2000), but I've had a few comments on it being excessive to the point of people not wanting to deal with that many cells, even if it has the potential for a better calibration. so, the future for it holds the same 400-2000 table, but going to 400RPM increments up to 8400.

I've never seen/heard of a VE or main spark table that wasn't interpolated.... that would be an extremely odd choice by the code engineer to do so. very few tables in GM code aren't interpolated and those that are tend to make sense or are at least non-critical.

in the stock calibration, spark still changes an appreciable amount even right up to the 4800 limit, and some use a RPM-derived sliding offset above that even, so I just want to put it all in one table. if you have significant fueling/spark changes above 6400.... well, code can always be revised.

I apparently need to get together with someone who is capable of fabricating turbo manifolds/SC intakes and drive systems but doesn't want to deal with the electrical side of things.... I can make an adapter harness in my sleep(or change the harness for a more permanent solution), but metal fab is outside my range of comfort unless a CNC mill is involved.



as for code progress, it's nearly finished. the E-side is completely taken care of, which has the bulk of the work necessary, now I just need to finish up a little bit on the T-side since I have to pass MAP information(both an emulated 1BAR signal for T-side usage and the raw 2/3BAR signal for the end-user) over SPI since there isn't enough space on the T-side for more emulation code. speaking of space, after all has been added on the E-side, I have two sections of free space, one is about 900 continuous bytes, the other is about 2800 continuous bytes.... a 17x17 VE table would take up 578(and free up its previous 442 byte area), so I have plenty of room to do that.

the only quirk I'm coming up with so far is that the barometric update function may require disabling/severe limiting(since baro updates happen with high throttle/low vacuum, when the blower does its magic).



I should have something posted tonight, I know someone on 60V6 was also looking for it, so it will end up there as well. MAF support was also requested, though I may wait to make sure this is working out for everybody first before adding in a separate patch for that.

[RobertISaar]

as near as I can tell, 5 bytes can be passed over SPI from E to T(where the main communications from PCM to laptop occur, though E can be communicated with using a wildly different ADX) without having to remove anything or otherwise cripple some function for any of the applications this PCM is used on. 4 of the bytes are continuous(currently used to transfer the E-side calibration part number to the T-side), 1 is on its own. I'm going to use one of the 2-byte blocks for this patch, leaving a 16-bit value and an 8-bit value able to be transferred in the future. the 16-bit value will likely be used for the MAF patch, while I have no plans for the 8-bit value.

finally on the home stretch of this patch, i'll run it through the disassembler to make sure nothing funny pops up and i'll call it a beta release. as such, I wouldn't recommend using it in a vehicle that has to make it to X location at Y time until any other quirks that might exist are discovered and fixed.

[RobertISaar]

what kind of plans do you have for a boost control/bypass valve or something of the sort? I'm trying to work out a way to allow baro updates, but there is no way I can fathom that would work without the PCM having direct control of the boost control solenoid and whenever the throttle is open enough for the bypass valve to close on its own, temporarily(or by default) keep/force the bypass valve open to get a baro read, then close it to allow boost to boost to build, rather than get sent back through to in front of the rotors. no idea how quickly the valves react though...

well, I can fathom another method, but it would require cracking open the PCM and reconfiguring the T-side channel 3 A/D circuit so that it could read a permanent, atmosphere exposed 1BAR MAP sensor. it isn't as fun as it sounds. or instead of reconfiguring channel 3, use channels 2 or 5, since as far as I can tell, they're unused. not much space in the T-side PROM though, so one would need to plan very far ahead to not write themselves into a wall.



in any case, here is what I've come up with. a small readme is included, which more or less reiterates the some stuff I've mentioned along the way, as well as some new info.

I highly recommend the rev3 v1.01 patch as well... it's mostly bugfixes to factory code, but it also adds a more defined method of controlling the highway fuel/lean cruise function, should it be desired.

https://www.dropbox.com/s/5jfa0iqz6s...Boost.zip?dl=0

after I pull this out of beta, it can end up in the thread for this PCM.

[Xnke]

Does the code have to do baro updates *while driving*? Just have it do the baro lookup on ECM-on, engine-off on startup, that seems to be effective enough for a LOT of other control computers-Megasquirt and Motec included.

I had initially planned on a full-pneumatic method for the boost bypass valve, that's what I use on the datto. It is "OK", but not great for street driving. It results in a non-intuitive engine response, which is...interesting. Roll on the throttle a normal amount and it makes 120-130kpa from 1500 to 3000RPM, but then once you're rolling a steady 3000RPM it vents the boost with a Whoosh-hiss, and you're driving on the very loud bypass. This gets irritating at highway cruise. (it's loud because the intake mods I did effectively remove all the sound baffling from the supercharger.) Toe in it slightly, it kicks the bypass valve closed and you're on boost, 155kpa at the current drive ratio. The blower is ported to be turned a LOT faster-target is 200kpa while keeping IAT's under 120F. It's balanced at a bad spot, as under cruise conditions the pneumatics tend to throw boost at you while holding a constant throttle position as the loading of the engine changes due to hills or even headwind/tailwind. I'll add an output the the MS2-Extra controlling that car at some point to drive the valve.

I am now considering using one of the EGR solenoid outputs, as it isn't looking like EGR is going to be a priority to keep-I wanted to keep it for the highway mileage advantage but it's easy enough to dispense with and just run a slightly different cam profile to obtain low-throttle EGR. IIRC the L67 uses a simple on-off method of boost control, so the EGR solenoid should have no problem with the L67-style boost control valve. This is the "preferred" method, as I can "lock out" the supercharger under highway cruise.

As far as the belt drive, that I won't be able to make progress on until I get the block back from the machine shop and get the heads dummied up with the complete camaro accessory drive in place. It is looking like I will have plenty of room to add a pair of idlers on a "pulley bridge" similar the the supercharged 4.6L ford engines. I'll have to do some finangling with the water neck, but since I am going to run the mechanical fan I was gonna have to do that anyway.

For the fabrication...I use a 4.5" angle grinder for a LOT of the fine detail work, it's amazing how good of a job can be done with one. I am likely gonna skin the top of the 3500 intake today, and look at what it will take to cram an intercooler down inside it.

[RobertISaar]

baro updates while running isn't too critical unless you're doing a pikes peak run since the O2 sensor should take care of fueling differences when not leaning too heavily into the throttle, which would also stay in-effect when PE kicks in. otherwise, need to shut the engine off to do a baro update should one be going up and down mountains. I would just bump the max RPM to allow baro updates low enough to where it can't possibly occur during boost. with a roots blower, that seems like it could be fairly low.

on this PCM, the EGR circuits are fully capable of PWM control at frequencies of 8, 16, 32, 64 or 128Hz(if I'm remembering correctly), though they're only ever used as digital outputs in a factory calibration. I have to open up a PCM of this style(on mine, the torx-head fasteners are corroded in place) and see if the E-side has an open A/D channel that is already connected to the PCM connector, otherwise i'll have to make it so and then the use of the 96+ linear EGR(or even the older EVRV setup) will be possible. that would open up 2 PWM capable outputs while retaining EGR.

I'm not sure how easy it would be, but I assume the boost solenoid could be played with via a PWM signal that would essentially allow setting a desired boost level. I get the feeling that a very narrow range of duty cycles would be usable though, considering how large the bypass valve is. wouldn't take too much valve angle to completely bleed off pressure under the blower.

[Xnke]

Ok. Still having good luck in Scan94/95 as far as data, but tunerpro is only very slightly better. Here's a look at what normally happens, as well as the one in a million shot of it *actually* working-I was suprised!

https://www.youtube.com/watch?edit=vd&v=2k2wm2K4mc0

[Xnke]

Spent several hours today working on this. Got logs and ADX/XDF/BIN/XDL off to Mark Mansur to see if it's a bug or a feature.

All day today, perfectly clean logs on first connection, but after a few connections and key-on-key-off cycles, the random data comes back. It's good enough to work around the random data, at this point.

A much more significant issue is that with the 2-bar patch in place, the MAP sensor no longer updates. It remains at the value that it starts at with the key-on, engine-off state right before cranking. Disconnecting the MAP sensor connector and substituting a potentiometer allows me to set any value of MAP I like, but it doesn't update until the engine cranks, then once the engine is cranked and starts the value never updates again until the engine stalls out. I have not modified the baro updates in this particular bin yet, but it looks like the ECM grabs a baro update on cranking and then never updates again until the engine stalls out.

Pretty much all the other data is fine-even the random error codes and DTC's don't set anymore. That's even more worrying as I have done nothing to fix them...they just fixed themselves. Meaning they can come back at any time and I STILL don't know what causes them...argh!

At this point, I can sub in a 1 bar sensor and drive the truck pretty nicely, and the 1 bar sensor and 1 bar code works exactly as you would expect it to. Not sure if it's an ADX issue or a code patch issue, so in the morning I will patch another stock bin, modify the bin for 2 bar sensor and no vats, and see if the patch function mangled the bin again-however the patch function claims this one is still good, unlike the past issue where it was pretty clear when it failed to patch.

More data in a few hours.