ilumo

Hey guys, like the topic says, does anyone here have their own OBD2 scanners? I've been looking at one from http://www.autoenginuity.com/products.html

It seems like a really good package for monitoring all the sensors realtime, graphing the data. It also allows bi directional support, so you can initiate tests, reset codes, etc.

For tuning, it would be nice, because you could hook it up to a Wideband o2 as well, monitoring the RPM vs speed vs intake Airtemp, vs Throttle position vs timeing advance, vs airflow etc... a lot of goodie stuff. And all of that stuff is avaliable in nice gauge/graph formats realtime and can be stored for later retrival, so you can decipher the data much easier.

its relatively cheap if you have a PDA, or a Laptop. People that have experience with this item or similar products, can you chime in about pros and cons, or maybe some better options? thanks

pimpjuice

I have the one from autotap. Its nice, but expensive if you want to buy the extra software (for extra parameters).

ilumo

Yes, ive heard of autotap before. Why is it that expensive anyway? What kind of advantages does it have over the scanner I mentioned? I know you can get that scanner for around 150$. Pretty cheap conpared to the ATap. hmm...

BigDogJonx

iTrader: (7)

I have the Harrison OBDII for my laptop and Palm Vx as well. I like it cause I cause use the Palm which is always in the car. With boost you always need it.

It does almost everything the Autoenginutity one you mention. Except 0-60 and all that stuff which I dont care for.

Dixit

BEJAY1

iTrader: (19)

Looks decent. What's their return policy? 2 reason's I ask -

1) I wonder if you'll actually get the SpeedTracer function to work at all. Auterra wouldn't fast sample at all and that's the same code as Nology I believe.

2) Of the 79 extended sensors how many are actually supported by the Nissan ECU? 12? 15? 20?

Also, have they only been around a year or so?

ilumo

Hey BEjay, I took the liberty of asking some questions for you, and here are some responses.:

What's their return policy? 2 reason's I ask -

>> Thirty day money back for the direct web purchases but not for eBay.
Listing costs and such prevent that.

1) I wonder if you'll actually get the SpeedTracer
function to work at all. Auterra wouldn't fast sample
at all and that's the same code as Nology I believe.

>> What do you mean Fast Mode? Gm and Ford have a first response mode;
Nissan doesn't from what I know. Nology buys from Auterra and relabels.
Our SpeedTracer is MUCH nicer. We took the time to validate our data.
We
do support more functionality too. However, we are both limited by the
fact that 4 Hz MUST happen from the RPM sensor. We do not work with
AWDs
or CVT transmissions either--yet!

2) Of the 79 extended sensors how many are actually
supported by the Nissan ECU? 12? 15? 20?

>> Typically the newer the model the more then sensor count. Nissan is
about 15 to 20.

BEJAY1

iTrader: (19)

Thanks for asking. So are you gonna get it? If not I'll order and try it out myself.

ilumo

Yes, I plan on getting it. Im just waiting for the right price for the pocket pc + PC version. I think thats around 200$ shipped for that version.

Morfeus17

I did see this site... And I'm pleased they have a pocket pc version to this program. I was able to download their 2.1 software, supprisingly... I already own a Ipaq 3630... All I need is a universial cable to convert the ipaq link to serial which compusa has for $30. Also I would need a Serial to ODB-II adapter which I saw selling for about $30. In the end it will cost you roughly $60-$65 to own your own scan-tool. It beats spending $200.

ilumo

Are you sure that the generic OBD2- Serial converter will work? he said something about some addition hardware for their adapter. Herse a quote when i asked him the differences between the adapters, and if they were interchangable.

The hardware is NOT compatible. The Palm
> requires
> > > RTS high. PocketPC
> > > requires DTR high. The PC doesn't care but
> > requires
> > > new cables. Get it
> > > packaged how you want to use it otherwise it
> won't
> > > work across
> > > platforms.

In additional to their hardware, you still have to get the serial cable for the IPAQs. I have a 2215, and I just ordered the adapter... only 25$. Now if the OBD2 -> serial erally would work, that would be SWEET. Do it, and let me know... or maybe il try

ilumo

edit:: What do you find a obd2->serial adapter... please giev me a link. thanks

Morfeus17

Here is the link on the serial to ODB-II connectors...

http://www.carsoftwares.com/OBDbrowser/cables.html

BEJAY1

iTrader: (19)

FYI, the Auterra/Nology OBD2->Serial cable doesn't work with AutoEnginuity sw. One of em's doing different pins/custom stuff.

ilumo

Yes... you are correct. Their software checks for specific signals coming from the integrated hardware. now if we knew their circuit design, it would be easy to mod the obd connector. But i dont feel like wasting my time on that, so i just ordered from them. I should get the package soon, and I will do some testing.

ilumo

well, I tried to do some testing ... And i think I just found out how SLOW our ECU reports. Check out the data logs.

------warming up ---------------
1:32:40, Coolant Temperature, 169, F,
1:32:40, Intake Man. Abs. Pres., 7.4, in.hg,
1:32:40, Intake Air Temp., 45, F,
1:32:41, Engine RPM, 800, r/min,
1:32:41, Coolant Temperature, 169, F,
1:32:41, Intake Man. Abs. Pres., 7.7, in.hg,
1:32:42, Intake Air Temp., 45, F,
1:32:42, Engine RPM, 687, r/min,
1:32:42, Coolant Temperature, 169, F,


-----coasting-----------------
1:35:16, Coolant Temperature, 185, F,
1:35:16, Intake Man. Abs. Pres., 17.4, in.hg,
1:35:16, Intake Air Temp., 41, F,
1:35:17, Engine RPM, 1925, r/min,
1:35:17, Calculated Load, 28, %,
1:35:17, Ign. Timing Adv. C1, 38.0, deg,
1:35:18, Abs. Throttle Pos., 4, %,
1:35:18, Vehicle Speed, 20, MPH,

1:35:18, Coolant Temperature, 185, F,
1:35:19, Intake Man. Abs. Pres., 4.7, in.hg,
1:35:19, Intake Air Temp., 41, F,
1:35:19, Engine RPM, 2000, r/min,
1:35:19, Calculated Load, 8, %,
1:35:20, Ign. Timing Adv. C1, 0.0, deg,
1:35:20, Abs. Throttle Pos., 0, %,
1:35:20, Vehicle Speed, 21, MPH,

1:35:21, Coolant Temperature, 185, F,

Notice it takes "2" Seconds to refresh each sensor? Wow... At this rate, I dont want to log more than a few sensors. When I tried only a few sensors, the results were much better, and refreshed a lot quicker. I guess I just want to complain on how long it takes a few of our sensors to respond. i will try to find out which one takes the longest. I have yet to test out the speed tracer function, but I will do that as soon as I get the basic logging functions down =]

JAY25

iTrader: (38)

More info on OBD II posts

http://forums.maxima.org/showthread....=OBD2+scanners

BEJAY1

iTrader: (19)

My software won't even allow recording of more than 5 params at a time so maybe it is the old slow CPU in the ECU. Actually I rarely need more than 4 at the same time.

Let us know if you can get the SpeedTracer function to perform.

Jime

iTrader: (10)

Its not our ECU thats slow.

The bottleneck is the OBDII reader. My Harrison model is similar in that the more you get it to report the slower it gets.

However, I have tried the Pocketlogger scanner that my Son has for his DSM on my Maxima and its super fast with any number of items being logged.

So its not our sensors, its our reader/interface causing the slowdown.

ilumo

I do not believe that it is the readers fault... because basically the reader transfers the data from point A the ECU, to point B the PC/palm.

What I believe is the bottleneck is either the code itself, OR the ECU/ sensors. I think its largely the SERIAL interface's fault. I believe the standard protocol is to send out the request for a sensor data, and then wait for a response before moving to the next request. You see how by doing this serially, it would lag the system down when you have a lot of sensors. Lets say it takes 20 ms for a RPM reply, 30 ms for a IAT reply, and 50 ms for a MAP... if you do those in series, you will end up waiting 100 ms for each sensor. now if we had some sort of PARALLEL interface, then you can send all those commands at once, and recieve that data without waiting on the other sensors. That is theory number 1.

Theory 2 is that their software algorithms are bad. using the same sensor refresh times as earlier, you know that the refresh time for the RPM is 20ms and the MAP is 50 ms. So theoritically, you can get 2 readings of the RPM for every 1 MAP reading. Now if you want to monitor the RPM and MAP, if your code was "smart", it would know that, and instead of retrieving 1 RPM, 1 MAP, 1 RPM, 1 MAP, it would do 2 RPM, 1 MAP, 2 RPM, 1 MAP... Because if it does it the former method, it would be wasting a lot of cycles. This theory would be dependant on the ECU speed and the algorithmn/coding.

WHat I think is its the serial interface... but your POCKETLOGGER makes me think question. Do you have any datalogged from the pocketlogger?

Anyone else with a different logger/ reader can you guys chime in. Im kind of disappointed with the speed of the logger...

Jime

iTrader: (10)

You can only get 6 samples per second on the Maxima so of course you are limited to those boundries regardlesss of what interface you have.

So if you are reading 6 sensors, its 1 per second, you can do the math if you are reading more or less.

ilumo

Where did you get the info that the Maixma's ECU operates at 6Hz? I figured ISO wold be from 2-10 Hz anyway. But right now, im getting "1" sample every "2" secs. 1/2 a hz. thats bad.

Jime

iTrader: (10)

I just remember it from when I was researching the OBDII sensors before I bought mine.

Here is the only list I can find right now. Nissan stuff is all in the same ballpark.

Anyway, my point is that if you are not getting 6 samples per second, your interface/reader is the bottleneck as I stated earlier.

OBDII Data Rates

Year Make Model Sample
Rate
1995 Eagle Talon TSI AWD 11
1995 Eagle Talon TSi FWD 11
1995 Mitsubishi Eclipse GSX 14
1996 Acura Integra GS-r 10
1996 Eagle Talon TSi AWD 11-12
1996 Kia Sephia 7
1996 Mitsubishi 3000GT VR4 9
1996 Mitsubishi Eclipse GSX 10-11
1996 Nissan 200SX 7
1996 Nissan pick-up 6
1996 Mitsubishi Eclipse GS 16
1996 Saab 900 Turbo 8
1997 Eagle Talon TSi AWD 11
1997 Mitsubishi 3000GT VR-4 7
1997 Mitsubishi Eclipse GS-T FWD 11
1997 Mitsubishi Eclipse GSX 11
1997 Mitsubishi Mirage LS 10-11
1997 Subaru Legacy 6
1997 Subaru Legacy 2.5GT 6
1998 Acura GS-R 9
1998 Acura NSX 6
1998 Mitsubishi Eclipse GS-T 19
1998 Mitsubishi Eclipse Spyder 16-17
1998 Volkswagon GTI VR6 6
1998 Mitsubishi Eclipse GSX 19-20
1999 Acura Integra GSR 11
1999 Mitsubishi Eclipse GS-T 17
1999 Mitsubishi Eclipse GSX 17-18
1999 Toyota Camry v6 9
1999 VW BUG 6
1999 Audi A4 1.8 6
1999 Toyota Corolla 14
2000 Honda Civic Si 10
2000 Honda CR-V EX 9
2000 Mitsubishi Eclipse GT 17
2000 Mitsubishi Galant GTZ 16-17
2000 Toyota Celica 7
2000 Toyota Celica GTS 8
2000 Toyota MR2 Spyder 12
2000 Audi S4 18-20
2000 Toyota Corolla 16
2001 Mazda Miata LS 11
2001 VW GTI 20
2002 Mitsubishi Montero Sport 11
2002 Nissan Sentra SE-R Spec V 6
2002 Nissan Sentra SER 6
2002 Subaru Impreza WRX 6
2002 Subaru Legacy H-6 6
2002 Hyundai Accent 6
2003 Mitsubishi Lancer EVO 19-20
2003 Mitsubishi Montero 20

ilumo

Heres a reply that i got from the engineer at Autoenginuity after questioning him about the refresh rates:

That's using Nissan's Consult is what those are. The OBDII standard
specifically lays down buad rates and interpacket delays which does
allow for 10 Hz. You can get faster with GM and Ford because they allow no
framing AND no spec'd interpacket delay. Vendors call that FastMode. Reliablity
is the issue then. Because it is non-standard you can run into GMCs that
don't support this "feature."

ISO vehicles don't support FastMode as far as we have found. I can't
verify these numbers you posted because I don't have a Consult. I do have all
of Nissans documentation now. We are making a Nissan enhanced version to
operate as a Consult would to access all vehicle sensors on Nissans protocols. I suspect that is a non-OBDII protocol reusing the OBDII electrical interface EXACTLY as Ford and GM did. If you break down the 10.4 kps into packers you'll find that the ISO procotol can do 20 Hz. Nobody has gotten that out of a vehicle yet because the bus isn't always idle. The ECU uses it too.

On the newer models the ECU clocks faster and the data rates are closer
to the maximum through put of the protocol. Out IT guy has a new Sentra
SE-R.
We see about 6 Hz on that like clock work. Very smooth refresh too. I
will try and look at this in the Nissan guides. The Nissan enhanced version
requires us to be experts but we aren't there yet. With your help I will be
before I start!
---------------

Thats strange though, because I tried this on the 2003 G35 as well, and it was still slow. HMMM. ANd jime, you said that your palm data logger was refreshing very quickly??

Jime

iTrader: (10)

I said it refreshed very quickly on the pocketlogger vs my Harrison OBDII reader. Thats because the pocketlogger gives user control over the OBDII communications, you cannot do that with any other interface I have seen.

Hooked to my PC, the Harrison logger will only log 1 reading per second regardless of how many sensors I read. That is the reader being the bottleneck as I said. Yours appears to act the same.

The PocketLOGGER was designed for performance tuning as stated below vs a generic OBDII scanning tool, hence it speed design.

PocketLOGGER Exclusive Feature:

Adjustable communication timing allowing capture rates above the standard 6 samples per second. By giving the user control over the OBDII communications, we were able to reliably extract data at the highest rate an ECU will support. By running 2 simple tests while connected to the car, PocketLOGGER will automatically find the fastest data rate that the ECU will support. In field testing, we have seen cars that won't support much more than the standard 6 samples per second, all the way to cars that will support 20 samples per second or more. Since PocketLOGGER is geared for performance tuning rather than a generic OBDII scan tool, we felt it was important to include this feature.


Now that my Son has a new AEM setup that refreshes at 200 times per sec I am going to confiscate his pocketlogger for myself.

DSMJim

Ahem.. Thats 300/second which is considered real time.

Your more than welcome to my Pocketlogger.. I'm sure we can get it to read 10-12/second like your 95 did. The thing about the pocket logger thats cool is having control over the OBD2 system how it reads. You can make adjustments to the interpacket delay and a few other tid-bits and get the reading up a whole lot higher. I could get 19/20 samples per second on my car easily.

If you wanna see more, www.digitaltuning.com. (no I am not affliliated with them at all, just a good piece) A big bonus is a really cool Java based viewer where you can overlay all the parameters and check out whats happening. I don't know if the other one has that or not, but I used it to no end and got my car dialed in pretty good with it. The logs are small and many guys post them online for more experienced people to look at and help newbies tune their cars. All and all, it works out for the DSM community very well.

Jime

iTrader: (10)

Brag, Brag, Brag.

You weren't supposed to be reading this, I hadn't even asked you about it yet. However, I hope we can work out a "deal".

btw it look as though those slicks you gave me are going to enter their 5th racing season on my new car since my other deal fell through. Having a grandpa baby them has helped their longevity.

slimer

iTrader: (13)

this is what im getting on this...

pocketlogger=good

regular obd2=slow

what about the lm-1 that stephen max has, any info on that?

DSMJim

Ok here is the deal. All you have to do is beat my car at the track.... on street tires. J/K...

Don't listen to this grandpa crap. He goes on like he's this old fart that doesn't know crap about cars and drives the speed limit all the time..

You have sprayed your car on the street as much if not more than I did on my VR6, and your anything but nice to slicks at the track Mr. Huge smokey burnouts and 1.7 60ft's... Nobody makes fun of you at the track for not being in our average age bracket espically after you run there's not much 95% of the people at the track can say (myself included). I remember Sean getting out of your car after a trip to the track saying to me "he sprayed it on the highway and damn is that thing fast" lol...

Jime

iTrader: (10)

I have only tried the OBDII Scan and Pocketlogger. I would assume (never do this)that the other obdII scanners are somewhat the same as the Harrison as far as speed but I hope I'm wrong.

Initially I got the OBDII Scan after trying out the Pocketlogger and figured it would be very similar except I had Palm and PC capabilties. Well I was wrong on that. The OBDII Scan is fine for reading all the same data etc it just isn't capable and wasn't designed to data log for performance tuning as far as speed goes, all the right stuff is there it just isn't fast enough to tune an S-AFC properly.

JAY25

iTrader: (38)

Hell you spray on the streets! why dont you share the fun by video taping it. I would like to see some of the faces of these youngsters after you spray them. Priceless!

ilumo

I am currently talking to the guys at autoenginuity. It seems to me that all the problems lie in the software. The adapter is basically a medium to transfer the signals... where the software will do all the decoding, number crunching, processing, etc. Im sure more people would purchase this if it was a functional scan tool AND a fast data logger in one. Having consult functions integrated would be awesome as well... we'll see what they say.