What approach are you using for data logging? I am a noobin ECU tuning and logging but it is not clear what the easiest most efficientway to setup for data logging and tuning. The only thing I have decided onalready and have purchased is an EMU, so that is the only constraint at thispoint.

1) I am not sure if I want to use Greddy software for logging. Any advantagesor limitation on the Greddy software? I am considering the Innovate LM2 setupfor their logworks software, but not sure if this is much better. Any otheroptions I should consider?

2) I know I need a wideband O2 sensor for logging and I know there is apotential to hook it up to the EMU. Is there an advantage to buying one thatcan replace my stock narrowband sensor? I am thinking going PLX for thisreason, but are there other wideband sensors that could be setup to replace mystock O2 sensor? Would this be better to integrate with the EMU? I am not surehow to hook it up with this approach but I will figure it out if this is thebest way to go.

I will eventually make it to be dyno tuned if I can find someone in thenortheast that is good at tuning the EMU. My setup will most likely changethroughout the year and prefer to start with very conservative tuningadjustments and primarily take advantage of vtec lowering and rev limitincrease. I just don't want to buy components and/or software that may or maynot work well together if I knew more in this area. I am afraid that as I gothrough the learning curve I may have approached it differently after spendingmoney and time with trial and error. If anyone could share their experience Iwould appreciate it.

 

Well, even a medium-end (Haltech S500, AEM, etc) standalone connected as a piggyback that directly controls fuel, spark, and vtec point as allowed by the new rules is a big help for our cars. Given that is what the piggyback rule now explicitly allows, I would hope the STAC has the foresight not to do a takeback if people take advantage of the rule as written. It does limit some of the more exotic features of the Motecs and whatnot, since additional sensors are not allowed...

 

The Greddy software is a little clunky for data logging, but I consider it to be a much better solution than using the Innovate OBD2 logger. One of the problems with the OBD2 logger is the sample rate. OBD2 loggers are limited to communication rate of the port they are connected to. The logger only monitors what is relayed to it by the stock ECU and never actually sees a sensor signal. I'm not sure what OBD2 protocol the '04 to '05 AP2 uses, but the AP1 uses a rather slow ISO 9141 protocol. The maximum sample rate you will see is ~3 Hz when logging 2 data channels. As you log more, the sample rate for each channel will decrease.

The Greddy logger on the other hand, can log all of the data channels at 50 Hz. The EMU monitors the sensor signals and doesn't communicate through the OBD2 port, so it is not limited by the communication protocol. At 50 Hz, you can characterize a signal much more accurately than you can if you're only logging at 2 or 3 Hz.

Integrating the wideband O2 signal with the EMU is the best way to go, in my opinion. This will allow you to see, log, and review the AFR along with all of the signals in real time and on the same screen. The logger does not have any data manipulation tools, so you'll need to export the data to a text file and import it to a program like Excel or Matlab. I detailed my approach to connecting the wideband signal a page or two ago and used a CDROM audio connector to plug into the EMU.

I haven't been able to figure out how to get the rev limit feature to work with the S2k setup. Maybe someone else can speak up if they have been able to get this functionality to work. If you have an AP2, I'd recommend getting an AP1 ECU and using the EMU to actually decrease the rev limiter to the RPM you want.

 

If this is the harbinger for adopting more flexible and robust tuning solutions, let's be more lawyerly about this sentence: Any standard OBD communications port functionality must remain.

To answer this question, what is the role of the ECU's communication with the obd port? Reporting? The rule doesn't state what has to be reported...if anything, but that it has to be able to.

 

Yeah, it's a little odd that the notion of emissions compliance has been discarded yet the OBD port must remain functional (scope of functionality not defined). Seems a little like the 25lb seat rule. It's a way to enforce an intent with out directly addressing the intent. What ever works I guess.

 

Heres the email I got back today on the rules...


Ok, thanks for the clarification. So the vehicle’s OBDII port won’t work as designed under your proposed scenario. I think I get it now and I’ll forward your comments to the committee.There is no specific go/no-go test that has been specified for compliance checks for any of our rules, much less this one. The rules just state what the restrictions/requirements are. It’s like having a speed limit sign that doesn’t tell you how the police will monitor it. Any method can be used. The STAC will consider your request at its next call, which is in about 4 weeks. Then it goes to the SEB. Until such time, I would recommend the most conservative read of the rules so you don’t end up wasting money/time on something that may end up being deemed non-compiant.

Again, thanks for writing in.
--Andy



I wish they would clearify all of this. I want a badass ecu!

 

So who even tunes emanagenent? I've read so many post about how no one wants to tune with it and some guy name gil was the main person but he retired or something.

 

Don't get me wrong, I'd love to see a good solution that levels the tuning playing field for early s2ks. I was referring more to the discussion about custom machining to shoehorn a standalone into the stock ECU case. It's plausible that the hardware-inside-case rule was intended to allow chipping of a factory ECU, not all-out replacing the guts. I could be wrong - I'm just playing devil's advocate.
That rule seems pretty clear-cut to me. The OBDII port's function is to allow codes to be read and cleared with any device that follows OBDII protocol. As long as it can still read and clear any code generated by the ECU, it complies. Whether or not you program your ECU to not generate certain codes is immaterial; all that matters is that the port can communicate the data when it exists.

 

Ok so I got an email back from my tuner who is working on a solution with the Aem, and I have a couple of questions. He says he can do it but is asking if it matters if it throws a cel does it matter and does it matter if any codes get stored. From what I have read so far as long as the port works and te code can be cleared we would be ok??? Anyone have further insight on this???

 

From my understanding, it does not matter if a code exists or if a code is stored. I believe the requirement is that the ability to read & clear codes through the vehicles standard OBDII port is there. I could be wrong.

But now my question becomes ...what cel codes is his(your tuner friend) solution throwing?
This sounds like a similar issue to what Evans is experiencing where his piggyback(haltech PS500/1000) solution randomly throws codes, and it's not the same code everytime, nor is there a pattern with the codes as far as when or how often or every so xx miles, so it's hard to troubleshoot what's going on.