nAst1: Progress and Concepts Thread

[caffeine]

So you're saying you don't need to zero the dwell to cut spark?

[robertisaar]

ehh, that's one way... reducing dwell. it would make a weaker spark that might or might not light off the air/fuel charge, which wouldn't work very well for a limiter i would think. kind of like a rev limiter that simply dials back spark advance, it works well when you're making high amounts of power and have aerodynamic and road drag to counteract the engine, but when you don't have those loads to fight against, firing even 10* ATDC may not keep it in a range where you want it without throttling the engine.

[robertisaar]

and 94-97 LT1.

of the 128 pins, 34 appear to be unused. lots of application specific stuff here.

[caffeine]

Alright, got some logs with both issues. In both cases I ended the log shortly after the problem came up. I'll upload them tonight or tomorrow.

When I talk about the delay before fuel cut what I mean is the the timing is retarded at one point (AFR goes to 22:1), then a couple seconds later the fuel is cut. I just don't understand why GM would put a delay between the two events since the fuel cut has absolutely no effect on the engine braking after the timing is already retarded.

[robertisaar]

if i had to guess.... perceived smoothness. between the two states of "engine running at normal advance with fuel" and "engine in DFCO", if you insert a 3rd state "engine still fueling, but retarded timing", it would make the customer less aware of what is going on. with an engine as different as yours is compared to a 3.1.... i can see how the presence of an intermediate state and using the stock calibration values there wouldn't necessarily be effective at doing anything.

[caffeine]

Here's the log where it goes very rich at part throttle for a bit. At 5:43 it's at 10.xx AFR with 8.x% throttle.

In the DFCO log it's recorded at the very end of the log slowing down from highway speed.

3500T Odd Behaviour.zip

[robertisaar]

random rich event:

definitely not closed loop logic, BLM held, INT and closed loop correction reset to 128 due to AE, but bumped back to where they were before the event.
DTC33 is set? does that happen regularly? it was set before the engine was cranked.

when the event happened:
12% TPS, 1800RPM, MAP goes into the 80-85 range.... 21* of advance, BPW of around 2.6-2.8mSec.

other sections of the logs that appear normal(like at 29:08 in thee DFCO log) with 12%TPS, ~1800RPM, MAP shows as 60-65 range.... 29* of advance, BPW of around 2.1mSec.

the target AFR was 14.7 during the strange event, 15.2 during the normal section.

at section where ~1800 and 80ish MAP appears normal(30:2: 19% TPS, 21.5*, BPW around 2.7mSec.(15.2:1 AFR)



so, both when it's normal and acting oddly at 1800RPM/80MAP, BPW is 2.7ish with around 21* of advance. that rules out the outputs of the ECM(or at least the logic behind them) since it commands the same outputs for a given set of inputs. so, that runs down to a hardware problem of some sort; sensor, plugs, wires, ICM, coils, ECM, power/ground wiring, injectors, wideband sensor or controller....

essentially, it doesn't look like its your calibration or my code. the way the wideband signal looks when it happens, it doesn't look like a misfire, since that would show up as the signal shooting lean instead of dropping even richer. so i would look toward something causing fuel flow to increase randomly(injectors, regulator, possibly the MAP sensor/tubing, wideband sensor/controller).

can't investigate DFCO yet, have to head to town for a few hours.

[robertisaar]

for the DFCO event: at 35:00?

[jdv]

Hi any new progress?

[robertisaar]

no..... i kind of feel like dr frankenstein anymore, i'm beginning to regret my creation. there are some aspects of the modifications that i did early on that i don't want to leave as-is, but i don't want to spend the time to optimize it either.

i'm also working off and on with a completely fresh operating system, along with hardware mods/additions, that will contain no goofy workarounds or otherwise weird things that GM decided to impliment that basically did nothing but waste space/processing time. the core of this will also largely be copy/pasted for the 7730TCM project.

this is in no way stating that i will be leaving nAst1 as a dead-end...... i just have other projects that i'm working on in parallel.

i need to rebuild my testbench before i can do much more testing, i currently have some open connections that cause some faults that otherwise don't exist and make verifying code difficult.

[robertisaar]

exciting thought: instead of having to find and solder in a FMD2 and hope nothing else goes wrong with a modified PCM, i have another solution for cam phasing on the 3500/3900.... use the PCM to lookup and output a desired cam phase position, done entirely open loop, and have a small microcontroller grab desired position from the PCM, then use the micro to read the cam position sensor for closed loop control. according to GM; coolant temp, oil temp and oil pressure(there are probably more) are used to help control phasing, probably as open-loop corrections. i don't see coolant temp being nearly as important as oil temp/pressure for positioning, so i likely wouldn't mess with coolant temp at all.

choice of micro? the ATMEGA328 looks to fit this nearly perfectly:
2 external interrupt pins(crank and cam sensors) so tracking crank position and cam position relative to crank is doable(which covers the closed loop portion of control).
5 PWM outputs(1 would be needed for the cam phaser, everything else is ???).
6 A/D channels(2 for oil pressure and temp, 1 for reading what the PCM wants the phasing to be, the other 3 are ???).
UART comms(which could be used to communicate directly with the PCM, to a laptop or both).
5 digital I/O(could be used for pretty much any discrete signal, either as read or controlled).

so, quite a few open possibilities AND it takes a lot of load off of the PCM, especially since it would keep internal mods to a minimum. if there were more interrupt pins, the high-feature V6 engines would be possible to play with as well, with their 4 cam phasers...... i imagine i could do it all through a single interrupt pin with some multiplexing and reading 4 digital I/O pins to see which of the 4 cam sensors caused an interrupt, but that complicates things a bit, and would eat up 4 of the 5 free digi I/O..... then again, they're not doing anything else. the difference between being able to use it on a 3500/3900 and a HFV6 is 4 diodes and a software change....



anyways, just a thought(or two) for now.... i need to quit taking on so many other projects before finishing the ones i already have in progress.

[pocket-rocket]

That's a pretty slick idea. Sure gives more advantages to the VVT engines in their current form on OBD1, other than the current displacement, metallurgy and intake tract performance benefits.

Sent from my HTC One X using Tapatalk

[robertisaar]

yeah, turns out it doesn't take much to bring some of the better OBD1 PCMs up to being able to control nearly every engine on the market even now, with similar or sometimes better control than the factory PCM.

~$5 of hardware and a couple of hours spent setting up code? WELL worth it to me.

[robertisaar]

though now that i think about it........ if someone were to somehow adapt the HFV6(or any, really) cam phasers to the LQ1..... i would be quite amused with that as well. you could even account for chain and belt stretch to keep cam timing consistent.... or track belt stretch and set off an alarm when it exceeds whatever safety threshold you determine?

[brian89gp]

Cool idea, pretty much what GM did in the day with offloading certain functions or calculations into custom built chips.