Thread: PCMSCAN + Subaru, which adapter

Originally Posted by TunerTools

A little one I can give you (although Joey will have real numbers): When datalogging for playback and analysis, some of the readings simply aren't accurate without enough speed to capture in real time. My son just tried some logging on his car yesterday using the All-In-One and PCMSCAN and the rpms were never making it to the top of the curve as he was shifting... the play back made it look like he was shifting about 4800 when in fact he was shifting at closer to 6000. The poor serial connection just couldn't keep up.

Nice TunerTools, that's the exact kind of example I was looking for... and the results I was afraid of. In order to loose that much detail it must be only captureing a value every half-second or so... or worse.

However, in order to complete the loop, we'd need to test the same set-up with the Mongoose cable to see if it was the serial connection that was indeed causing the bottleneck. Or perhaps it was the software (PCMSCAN) that couldn't poll and record quick enough and a faster cable would hardly help at all.

Maybe someone with a Mongoose cable and PCMSCAN can provide some input to compare to your son's experience.


I'd say a device that can't keep up with a car's many rapidly changing dynamics, such as RPMs, can't be considered a truly accurate "real-time" analyzing tool. It would be better suited for discrete diagnostics (like engine alarms) or slow-changing parameters (like temperatures).

Originally Posted by Podaman

However, in order to complete the loop, we'd need to test the same set-up with the Mongoose cable to see if it was the serial connection that was indeed causing the bottleneck. Or perhaps it was the software (PCMSCAN) that couldn't poll and record quick enough and a faster cable would hardly help at all.

It'll be both, and an independent test would help. Ford and Chevy controllers limit the simple (slow) datalogging technique to about 30 parameters/sec, even if there's extra bandwidth available on the wire. There's a different mode where you say "send me these 3 parameters automatically, without polling". That mode is about 10 times faster. So there's one bottleneck with the serial port, and another huge bottleneck from the technique. You'll see some difference with a fast cable now, and then a huge difference later with a fast cable and some improved software.

Thanks for the info joey!

Originally Posted by joeyoravec

Ford and Chevy controllers limit the simple (slow) datalogging technique to about 30 parameters/sec, even if there's extra bandwidth available on the wire.

Do Subaru controllers (ECUs) have the same limit? So this limit is an issue with the car's controller, not the software or cable. So no matter how fast your software or cable are, the controller would be the bottleneck (as far as getting 10+ samples/sec for more than 3 parameters)?

I wonder if the limit is simply a protective feature intentionally programmed into the car's controller in order to keep it from being bogged down with monitoring requests and as a result becoming unable to preform it's intended engine-critical tasks.

Originally Posted by joeyoravec

There's a different mode where you say "send me these 3 parameters automatically, without polling". That mode is about 10 times faster.

Is this mode currently utilized by PCMSCAN?

Is this mode/technique specific to PCMSCAN? or the car's controller? or all OBD software?

Can software (PCMSCAN) simply be re-programmed to say "send me these 30 parameters automatically, without polling"? This would allow us to reach speeds that are 10 times faster for more than just 3 parameters. Or do car controllers have a hard limit on this and can not be overcome until newer cars update their ECUs and remove the restriction?

Originally Posted by joeyoravec

So there's one bottleneck with the serial port, and another huge bottleneck from the technique. You'll see some difference with a fast cable now, and then a huge difference later with a fast cable and some improved software.

So there are actually three different bottlenecks:

-Ford and Chevy controllers limit you to 30 parameters/sec
-Software (PCMSCAN in particular?) limits you to only 3 parameters at increased rate (as fast as possible, ~10 samples/sec?)
-Serial bandwidth sucks

So the advantage of a fast cable is obvious. But... I guess my overall question now would be,

with the Mongoose, is this limitation really only in the software? So with a patch that changes the polling technique we could request more than 3 parameters simultaneously at the speeds 10 times faster? Or does the problem lie in the car's ECU and it can not be overcome until car manufacturers update their controllers.

Currently, how many parameters can we monitor simulaneously at a high scan rate (10+ samples/sec) with the Mongoose, a 2006 Subaru ECU, and the current version of PCMSCAN?


Thanks!

Correct, the generic obd mode 1 requests often are quite slow. This may be for a number of reasons: busy with critical engine tasks, how tasks are handled internally, or even just lazy engineering! But this is fine because most automakers provide a technique for high-speed datalogging.

Originally Posted by Podaman

Can software (PCMSCAN) simply be re-programmed to say "send me these 30 parameters automatically, without polling"? This would allow us to reach speeds that are 10 times faster for more than just 3 parameters. Or do car controllers have a hard limit on this and can not be overcome until newer cars update their ECUs and remove the restriction?

Sure, the author of PCMScan can add support. It's not in there yet -- the technique is different for each automaker, so covering all makes/models is a ton of work. That's why I'm working on a plug-in so software vendors don't need to reinvent the wheel each time.

The exact performance and limits will vary. Yesterday on a 2003 Ford diesel (CAN), I was getting a two 5 byte repsonses every 8ms. You can pack multiple 1 or 2 byte parameters into a single response. Also you can have ~16 requests that will be served round-robin with the typical 8ms spacing. If it's not 100 degrees outside, I'll try my 03 Mustang today which uses a much slower engine controller.

Originally Posted by Podaman

with the Mongoose, is this limitation really only in the software? So with a patch that changes the polling technique we could request more than 3 parameters simultaneously at the speeds 10 times faster? Or does the problem lie in the car's ECU and it can not be overcome until car manufacturers update their controllers.

Technically it's not polled -- you setup a request and the controller spews data continuously. From what I've seen Ford and GM support this on all OBD controllers back to 1995. Life was easy because they maintained tight control over the engineering process. But your mileage may vary and you'll always find exceptions!

Thanks for the details joey.

Originally Posted by joeyoravec

If it's not 100 degrees outside, I'll try my 03 Mustang today which uses a much slower engine controller.

Have time to try it out yet?

Actually I tested an EEC-V controller on the workbench because it's way too hot outside. It was sending one 4-byte message every 5ms. Less overall throughput than the other one, but only slightly. I was surprised.

So you can use the Cobb acessport along with a laptop and then have no need for OBDII reader?

Maybe I should just buy an acessport instead of a obdII reader then...

I have a 03 wrx btw...

Originally Posted by joeyoravec

...the technique is different for each automaker, so covering all makes/models is a ton of work. That's why I'm working on a plug-in so software vendors don't need to reinvent the wheel each time.

How are the plug-in's goin, Joey? Play with a Subaru yet?

Sorry people for posting here but...
I also have a subaru. Forester/2000. I plan to install a car-PC in it and to read data from a OBD interface. I need help in chosing what i have to buy. i am not planing to modify anything to the ECU, just to read codes, etc. At most to clear error codes, but not nercessary actually...

Of course, i dont have the "cable" but i can work with both USB or standard COM port. What would you recomend me to buy?

many thanks