Posted: Tue Feb 23, 2010 5:47 pm
Its 50ms which would be 20hz. I can try it in "burst mode" which supposedly just goes at the highest rate the port can support.
LOL you mean like this:loxxrider wrote:I feel like the car actually looks better with the front bumper off haha. I dunno, something about it just totally ruins the flow of the rest of the car. With it off its a really good canvas for something beautiful. .
I really dont think you are getting 20hz out of it, if you can log to a file and there is a time ref from the laptop then you can gauge the rate it is actually logging at.loxxrider wrote:ok i tried burst mode and I guess I dont know how to use it. It didn't log anything.
Anyway, this time the car backfired pretty hard up around the same RPM range as I mentioned above. My roommate was in my apartment and heard it with all the windows closed. The main road is like 250 yards away.
The power goes away for a split second (you can feel the car miss) and then it pops a split second after.
Well keep in mind this is second gear pull, not third. Definitely not doubting you though. There is a seconds thing in the log. You can see it where the cursor is. The only thing I used to see when the ECU actually did reset was the time would jump a few ms.TheArchitect wrote:I really dont think you are getting 20hz out of it, if you can log to a file and there is a time ref from the laptop then you can gauge the rate it is actually logging at.loxxrider wrote:ok i tried burst mode and I guess I dont know how to use it. It didn't log anything.
Anyway, this time the car backfired pretty hard up around the same RPM range as I mentioned above. My roommate was in my apartment and heard it with all the windows closed. The main road is like 250 yards away.
The power goes away for a split second (you can feel the car miss) and then it pops a split second after.
Back when we were trying to find a difficult bug "the glitch" on the 034 ECU, I determined that somehow the ECU was resetting. Since it happened every other blue moon I had to add a "seconds since ECU reset" object to the GUI that allowed me to determine that a reset had occurred (since I couldnt be there for the many hours it took to manifest the problem).
This said, is there an item such as "powered seconds" or equiv that comes from the ECU (not from the laptops time) that will tell you that the ECU has reset in such an event?
In the case of the 034 ECU, that parameter and many other important diagnostic info is put into the log file. Stuff you wouldn't normally even what to know about, but allows someone a better window into the CPU after the fact.
Not sure of the relevance to what gear its in, if you have a file logged and it has a timestamp, just count the number on entrees in say 10 secs and divide by 10 for the avg samples per second.loxxrider wrote:Well keep in mind this is second gear pull, not third. Definitely not doubting you though. There is a seconds thing in the log. You can see it where the cursor is. The only thing I used to see when the ECU actually did reset was the time would jump a few ms.TheArchitect wrote:I really dont think you are getting 20hz out of it, if you can log to a file and there is a time ref from the laptop then you can gauge the rate it is actually logging at.loxxrider wrote:ok i tried burst mode and I guess I dont know how to use it. It didn't log anything.
Anyway, this time the car backfired pretty hard up around the same RPM range as I mentioned above. My roommate was in my apartment and heard it with all the windows closed. The main road is like 250 yards away.
The power goes away for a split second (you can feel the car miss) and then it pops a split second after.
Back when we were trying to find a difficult bug "the glitch" on the 034 ECU, I determined that somehow the ECU was resetting. Since it happened every other blue moon I had to add a "seconds since ECU reset" object to the GUI that allowed me to determine that a reset had occurred (since I couldnt be there for the many hours it took to manifest the problem).
This said, is there an item such as "powered seconds" or equiv that comes from the ECU (not from the laptops time) that will tell you that the ECU has reset in such an event?
In the case of the 034 ECU, that parameter and many other important diagnostic info is put into the log file. Stuff you wouldn't normally even what to know about, but allows someone a better window into the CPU after the fact.
Only if it can actually log at that rate.loxxrider wrote:btw when I move the cursor along, it moves about 8 ticks per second aka 8 hz I guess?
There is an option to bump it up. Like I said before, its at 50ms right now. I guess I could move it down to go faster. Maybe 25ms.
Dielectric grease is always good, if its already started arcing down the plug, the boot will never be the same even with the grease.loxxrider wrote:anyone ever try NGK BCP7ES plugs?
I'm going to try plugs first and maybe some dielectric grease.
Kevin did some fuel tuning and we also decided to bump dwell to 4ms just for the hell of it.
I used to love the BKR7's on my 1.8t with garrett turbo. Noone seems to like them on these. They are also highly used on high horsepower boosted hondas a lot.pitten wrote:I tried curing my own misfire problem with a set of new NGK BKR7E plugs, yes the cheap ones. The F5DPOR I pulled out actually didn't look too bad, except for cylinder 1&2 being sooty, and the NGKs at least didn't make it worse. Misfire persists, but there are more than enough possible culprits left to be checked. I'm not sure how much slack in the distributor gear can be tolerated for proper triggering. You think it's an ignition juice issue?
Thats voltage related dwell compensation, its what allows the coil to fire off the engine when the motor is cranking.loxxrider wrote:It has dwell @14v which is at 4 right now and it also has a setting for dwell added at 6v which is .52 (ms)
I'll back the dwell down. I'm just trying this out to see if its an issue.
Understood, thanks. I want to get off of this shitty megatune and into the VEMStune which is much better. I dont know if they have a load based dwell map like you are talking about, but I'm sure its possible.TheArchitect wrote:Thats voltage related dwell compensation, its what allows the coil to fire off the engine when the motor is cranking.loxxrider wrote:It has dwell @14v which is at 4 right now and it also has a setting for dwell added at 6v which is .52 (ms)
I'll back the dwell down. I'm just trying this out to see if its an issue.
What you really need is a map that allows you to configure the manifold pressure and or RPM and have a dwell setpoint that allows you to increase the dwell time as a function of load, since its under load when ignition energy needs increased to prevent a spark out.
I'd try the 4ms dwell time to see if the problem goes away.
If it does, I'm not sure what you can do to be able to keep the coils cool at light load and still be able to run the higher dwell time under high load as needed. This would require a variable dwell time proportional to VE/load.
You can increase the dwell to prevent the misfire but like I said you will be hurting your coils in the long run.
What you are seeing is the lean spike caused by the misfire. Everywhere other than that spike is just fine. A little fuel was added here and there, but leaving it as it was would have been just fine.jcarrick wrote:I'm not an expert on reading those logs yet, but from the graph it looks like you may be running a bit lean