krohelm
-
Posts
83 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Events
Gallery
Blogs
Posts posted by krohelm
-
-
This would be great - also, can we get a JSON log file output? This would let me load all my log files into ElasticSearch and detect anomalies automatically!
-
I think maybe sensor ground might have some load going through it. Do you see a little step in the temp sensors at the same time?
No, temp sensors read steady throughout starting. Maybe it's just vacuum slightly turning the throttle plates? The TPS is very sensitive (needs to be, as 0.1% is significant) and it seems plausible that 50kpa vacuum could turn the blades slightly.
-
The ADC's on the G4+ analog inputs have 10bit resolution. This gives you about 1023 "steps" from zero to full scale. 0-100% in 0.1% increments is also about 1000 steps, so you are getting the full precision that the hardware is capable of. One thing that you need to check is the voltage range of your TP sensor. If for instance it is only giving you a 2.5V change from closed to WOT then you are only going to be using half of the available ADC resolution.
1/1000 of throttle position should be more than enough to get an Alpha-N tune running perfectly fine.
Just closing the loop on this - yes this is mostly problem-between-keyboard-and-chair.
The first problem here was a lack of a real "load" input into the modeled fuel algorithm. By switching from BAP load source to MAP load source, all of my low throttle problems disappeared. There was literally no reason not to use MAP for "load" and TPS for VE table and it works like a charm. By having variable load at idle, small TPS changes that are not measured are basically just small increases in load and result in additional fuel. It now only takes 1000rpm to do a slow take off, and easily pulls uphill into my driveway with small throttle opening. Single best drivability fix since the firing order fiasco
The second problem is that for some reason I cannot explain, my TPS drops after starting the engine. By setting it to 0.7-0.8% at rest with the engine off, it drops to 0% once started. It's a workaround but I'd really like to understand this better. I attached an image, but my log file is over the max attachment size of 5.4mb.
-
I would do it the same way we do itb GTR's. You need to set fuel load source to MAP, have MAP sensor connected to manifold, leave fuel table axis as TP. You then have compensation for the idle valve and boost when you add it later. You then use the openloop lambda table spanned with MAP/MGP to take care of the fact you want different AFRs at different boost pressures since TP is locked at 100.
Ahhhh I forgot I had my equation load source set to BAP. I did that initially to get it running in modeled mode, always intended to work out the MAP mode separately. If I remap on MAP it will probably work itself out and I can remove the AC compensation table. Thanks for digging in deeper, I'll work on remodeling my fueling (after stashing my current configuration away safely)!
edit: Yup, I spent about 45 minutes dialing in my idle in MAP fueling and it's much more solid now. I deleted the 4d fuel map and it reacts to change in load very quickly. This will be much easier to tune I think.
-
Yeah that makes total sense. Can I actually use MAP at idle and above 100kpa? I'm planning to add a supercharger and I expect to still need alpha-n at low rpms.
I really believe MAP/maf at idle is ideal. For the moment this 4d adder table is working OK, but it's quite a bit like traditional fueling. I expect to have problems with it when it's cold or when I'm up in the mountains.
Any recommendations for a good MAF sensor that works great with g4+? Ideally one that would utilize my last remaining digital input... I could ditch alpha-n entirely with a decent maf. I wonder how Toyota got it so smooth with TPS+MAP.
-
1.6 liter engine running at 900-1k rpm, if you turn AC on it kills it very quickly (log says <2.5 seconds). You have to give it more air and more fuel to maintain 900rpm (hence different VE at the same idle cell). If I had e-throttle idle it'd be a different story, as the map would contain the load cell. Or if I were MAP/MGP tuning it would also work ok. But alpha-n it's just an otherwise unaccounted for change in load which requires both air and fuel compensation, or physics compensate with reducing engine speed to 0. :-p This map is mine. Originally I referenced some details from another map but this doesn't resemble it at all anymore.
Idle ignition is fine, it's holding my idle steady while my IAC adjusts to suit the base 10 degrees btdc target. Without it, idle bounces around in an unseemly fashion.
I need to test this with more normal conditions, i.e., not in my garage, but this map with the 4d fuel table allows me to toggle AC on and off with almost no blip in rpms. It's pretty smooth now! I'll grab a log another day if you're interested!
-
Did some digging. Looks like there's an unexpected electrical shift when the engine is running. I'm not sure why or how, but the ground or 5v reference shifts and effectively sets the throttle position arbitrarily lower after it's started.
I worked around this by manually pulling the throttle to -0.8 to -1.0%% before clicking "OK" on the throttle calibration wizard for "release throttle." My throttle rests around 0.8 - 1% until I start the engine, at which point it droops over a few seconds to 0%. It's almost right, and the dead zone, while still noticeably problematic, does not result in an easily killed engine.
Fueling seems to be based on the actual fuel axis tenths-of-percents fuel, while the AN voltages have higher precision. Fueling should interpolate via the higher precision data source; 0 to 0.1% is a large step in my alpha-n, as is 0.3 and 0.7. But with no interpolation below 0.1% precision, it's pretty difficult to perfectly smoothly transition onto throttle at idle.
-
Thanks for the reply Ducie54! I wired up the "AC Request" digital input, but it's more of a "yo, I just engaged the AC clutch so you know - think fast" semantic from the factory.
I got it to idle without insta-death via a 4D fuel map adding 32.5% fuel to idle cells while DI-2 is on. Seems like there should be a better way to accomplish this same thing, as I see
G4+ ECU Tuning Functions > Fuel > Fuel Corrections > Idle Load Trims > Air Con Trim
in the help menu. However it appears to only show up with traditional fueling. I need it in modeled! Added a feature request: http://forums.linkecu.com/index.php?/topic/7099-ac-load-compensation-in-modeled-fueling/
-
VE is definitely way different with alpha-n at idle rpm and AC on vs off, and short of a full 4D fuel table I don't see a supported method of working around it.
G4+ ECU Tuning Functions > Fuel > Fuel Corrections > Idle Load Trims > Air Con Trim
amount of time in milliseconds added to the injector pulse width when the Air Conditioning clutch is engaged.
This is the right trim to use, but it's locked to injector millis and thereby traditional fueling. In modeled alpha-n:
- AC turns on increasing demand.
- Engine goes lean with stall compensation via IAC solenoid.
- Engine dies.
By adding 32.5% to my idle cells in a 4D fuel map I've worked around this, accomplishing stable lambda across AC state transitions; but this should be a supported use case.
Additional context: http://forums.linkecu.com/index.php?/topic/7096-idle-with-accessories/
-
The ecu is unaware of the slight pressure on the pedal, it should not help to use accel enrichment. :-( I had it on before actually but it didn't help.
Can you physicaly adjust your tps so that its ALMOST at 0.1 when at rest?
I'm a little reluctant to do this. I'm glad it occurred to you too; I tested my tps connection and it is varying resistance with the lightest of pressure, just as designed. If I can't get the software to understand it correctly I'll do it though!
Is there any way to adjust the deadzone? If it's saved in the pclr, which bytes hold the 0% value? I can hex edit it if I can only find it...
-
4age 20v engine, alpha-n: I'm having troubles stabilizing idle with headlights, fan, engine fan and AC (or even just AC). Any tips would be greatly appreciated, pclr is attached.
I've tried turning up my target idle speed to 1000rpm, increasing my base IAC position, feathering the throttle - it just dies due to unexpectedly high load at 0% throttle. Seems like MAP would be more ideal, but ITBs make it fairly impractical.
-
When I touch the accelerator pedal gently, e.g., to take off very slowly in a parking lot, my TP(Main) stays at 0 while my mixture goes catastrophically lean and my engine dies.
4age 20v engine, alpha-n, I've run the throttle adjustment routine cold and warm multiple times, it's always exactly the same. The dead zone at TP=0 is much too large for my throttle bodies. Can I fine-tune the throttle adjustment wizard's output? Is there something else I should try?
-
Can you share a PC log file, with pretty much everything logged (specifically interested in Lambda 1 Status, Error, Temp and rpm)? Idle is fine, just curious if you are having a similar issue as me and the log would help.
-
Default 250hz, what it popped up with. I noticed Motec uses 0hz to indicate on/off instead of pwm, is there something similar here? Could let me really simplify the table if so!
-
I have logs, definitely hold it consistently within 0.5% for significant stretches of time. AN Volt is a great idea to get this moving forward: If I can specify the Y axis in 0.01v increments and if that is the measurement granularity, there is no pwm interpolation window which is ideal. It'll be easy to set up and test tomorrow, thanks for the idea!
-
Just for visibility in case someone else is tempted to do this, TPS is not a great axis to use with this strategy, as the tables hold 1% granularity while the runtime value is in 0.1% increments. I manually verified on my on/off solenoid that it receives varied PWM in 0.1% increments while the throttle position is between 1% thresholds: It interpolates in 0.1% increments, which can be a real problem for a solenoid that requires DC. GP PWM is useful, but beware mixed granularity in both axes if using it for boolean logic! There are other runtime parameters that will work fine for this, though, if you don't need TPS, or if your TPS spends most of its time at 0 or 100, though you probably wouldn't care about this anyway if so.
This most likely disqualifies GP PWM for the example use case, given that it requires TPS & RPM, and cannot tolerate PWM to the switch.
-
@Davidv: I did both 1rpm interpolation and 1tps interpolation. I'm still a little concerned about TPS interpolation, as it's totally feasible to rest at (e.g.) 19.4% tps up a hill on the freeway and I don't want 40%pwm going through my solenoid as it's undefined behavior... and the PWM map only gives 1% TPS resolution. I'm not sure this is the right tool.
And I confirmed on the car, my solenoid whines when I slowly move the throttle past a 1% boundary (like between 9% and 10%) and "thunks" like normal when I drop past the threshold very quickly. Man, that logic table looks pretty appealing right about now...
Any other novel ideas to reflect this map? (Attached the map that almost works)
-
Hi Brad, I'm definitely aware of the mechanical function of the 4age 20v blacktop vvt solenoid and cam pulley. If you check out the map I put together above in red/green, there are not enough virtual aux conditions available in total to produce a full 3d map of the correct vvt on/off state across rpm and tps. That's why I feature requested a v-aux 3d map; this optimization problem is just more complex than 3 or 6 combined conditions via the provided switched cam output type in pclink.
Adam, can you confirm which values should be used to drive 0/100% duty cycle switch (no partial duty cycle) on the VVT Inlet Target Table & vvt solenoid output with no cam angle sensor input?
-
That makes sense and is in line with my understanding; I'm wondering if there's a way to use the Inlet Target Table in the manner described as for the general PWM output by clever table values and columns.
-
Crazy thought, what do the VVTi Inlet Target Table values mean when you don't have a cam angle sensor configured? The documentation says it is degrees of cam advance but that only relevant tables are enabled for configured inputs and outputs. A cam solenoid output is a pwm output, but its table is in degrees: I'm still down an oscilloscope or I'd measure it.
-
I think your over complicating things. Put it on a dyno, do a run with it off and a run with it on. Where the power lines cross is your switch point.
Thanks for your input: Check the table, I measured VE off and on over a wide range of throttle and rpm conditions. The correct setting for VVT varies by both throttle position and rpm based on logs composed of many thousands of data points. This is not a 0-60 concern (simple rule > 80% throttle), but a drivability & efficiency concern (best highway setting needs 3d map according to data).
I'll be using the pwm table for now, and will refine it on a dyno. Engines are complex, this is exactly as complicated as the data indicates. Anyway, this is a wishlist request, not a tuning help request; I've demonstrated a feature need, now we wait for others to corroborate.
-
How about wheelspeed/rpm for an electric exhaust branch?
Throttle position/rpm/gear to a shift light? With close ratios and an engine with hp drop before redline there's a correct point at which to shift that differs by the gear ratio spread.
This person's use case http://forums.linkecu.com/index.php?/topic/6653-user-configurable-maps/? (more complex but more general)
The lack of a map which provides a condition to other outputs crucially limits the utility of Virtual Aux. In the example case, luckily it can be worked around by abusing a PWM output rather than using the correct CAM-Switched output. I am not the most creative tuner out there, but surely there are a lot of uses for this!
-
Request:
Add at least one of the following features to PCLink and make available to the Monsoon ECU:
- An optional Table on the CAM-Switched function.
- A Virtual Aux boolean (on/off true/false) table.
Example use case:
Based on logged VE tuning with Toyota VVT ON or OFF, about 3.5 hrs of driving show maximum VE would be chosen as follows for RPM/TPS on my engine:
2250 2500 2750 3000 3500 4000 4500 5000 5500 6000 6500 7000 7500 8000 10 1 1 0 0 0 0 0 0 1 1 1 1 1 1 15 1 1 1 0 0 0 0 0 1 1 1 1 1 1 20 1 1 1 0 0 0 0 0 1 1 1 1 1 1 25 1 1 1 1 0 0 0 0 1 1 1 1 1 1 30 1 1 1 1 1 0 0 1 1 1 1 1 1 1 35 1 1 1 1 1 0 0 1 1 1 1 1 1 1 40 1 1 1 1 1 0 0 1 1 1 1 1 1 1 45 1 1 1 1 1 1 0 1 1 1 1 1 1 1 50 1 1 1 1 1 1 1 1 1 1 1 1 1 1 60 1 1 1 1 1 1 1 1 1 1 1 1 1 1 70 1 1 1 1 1 1 1 1 1 1 1 1 1 0 80 1 1 1 1 1 1 1 1 1 1 1 1 1 0 90 1 1 1 1 1 1 1 1 1 1 1 1 1 0 100 0 0 1 1 1 1 1 1 1 1 1 1 0 0 Alternatives considered:
- Boolean conditions.
- There are simply not enough conditions available between the aux output itself and all virtual aux channels to achieve the example. - GP PWM output.
- This is a hack; using a PWM output's table to switch 0/100% duty across 1 rpm. It works for a proof of concept and shows the ECU is physically capable of this functionality. - Using simple TP/RPM rule to define "rectangular" space for VVT.
- That mid-range is where my car sits on the local high speed highways. The rectangle rule ignores the OFF area and approximates a poor compromise. The VE difference in many of the cells is greater than 10%.
-
You could set your aux 4 to GP PWM
and then fill out with 0% or 100%
Might be a better way to do it but that would probably work.Would just need to be wary of where it's trying to interpolate between 0% and 100% you might need to set some custom rows very close together.
e.g. one row at 2999rpm 0% and one row at 3000rpm 100% so it's only interpolating across 1rpm instead of 500 or 1000.
That's a good idea, I might give this a try on the short term. This would let me start getting comfortable with 1 fuel table like you advised.
Otherwise you could use your normal set of conditions and do the same things above for a virtual aux instead, that acts as one of the trigger conditions.
I wanted to use a virtual aux for the table, but I don't see one that gives a table.
Basically, the feature I'm missing in PCLink is one of:
- An optional Table on the CAM-Switched function.
- A Virtual Aux boolean (on/off true/false) table.
Will post in WishList for this, I shouldn't need to use a PWM output to get an auxiliary map :-). Thank you for your insight Davidv, this will move me forward!
Any other novel ideas to reflect this map? (Attached the map that almost works)
Support Tablet/Laptop mode switching without crash
in WishList
Posted
I have a Lenovo Yoga I use for logging while on the road. If I lay it down flat, Windows tries to switch to Tablet Mode, which causes PCLink to crash. Also, it seems returning from Tablet Mode to Laptop Mode causes it to crash usually too. This is pretty disruptive!
As a mitigation, could we get a periodic log file auto-save so I only lose the last, say, 1 minute of logs when PCLink crashes?