benetton

I have done many searches but cant find an answer, I want to use the PCMSCAN software, but trying to find out which obd2 adapter would work better on a subaru, PCMSCAN lists,
1- elm 327
2- Mobydic
3- autotap
4- mongoose

I want to know if there are any real difference in the refresh rate between any of these, I want to be able to use the gauges with the least amount of lagging.

I know there is deltadash but abit out of my price range.
and I have also see open port 1.2 but can't find if it will work with the PCMSCAN.

Thanks Brad

MP3Car.com

 

CADILLAC

did u try

__________________
California here I come!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
CarPutter worklog http://www.mp3car.com/vbulletin/show...d=1#post859361

benetton

yes I did!!, I also check scoobymods and nasioc

SanRemoRex

Not really familiar with PCMSCAN, don't know if it works with a serial interface or what, but I use the cable from my AccessPort (Diagnostic to Serial) with ECUexplorer. Great (and free!) software, has some really cool features built in (like starting/ending a datalog with the defrost button). Unfortunately, the interface is really nothing special. Again I dunno what PCMSCAN has going for it (although I believe it does integrate well into the popular FEs, where I doubt ECUexplorer will), but that might give you a couple things to look into. Also, ECUexplorer uses the Suby-specific SSM profile as well as OBD-II, allowing it to read additional sensors, and at faster rates.

I personally plan to exit RR and use ECUexplorer separately when I'm at races, once I switch over to the Pandora.

__________________
MY04 Subaru WRX, San Remo Red,
Mac Mini carputer (Macindash) nearly complete. Current capabilities: Media playback, touchscreen interface, dual OS via VPC, iGuidance navigation. Future plans: Video capture, OBD-II interface, more racing stuff.

Podaman

Hi TunerTools, question for ya:

I just received the Tactrix OpenPort 1.2 USB interface for my Subaru 2006 WRX. I installed the XP drivers and set the virtual com port to COM 4. I tried TARI Racing Software's free DL1 Subaru diagnostic application as a test and it worked fine. I would drive around and my friend could watch the live data change on his laptop.

However, I used PCMSCAN next and couldn't get it to work. I tried connecting with all of the listed connector types (ELM, T16, Autotap, J2534, mOByDic) and none of them would allow me to connect. Maybe I'm missing a simple configuration step? Which of these PCMSCAN supported connector types are closest to the OpenPort 1.2 since I can't select the exact connector from the list?


One thing I noticed: the Tactrix website says the OpenPort 1.2 is an ISO 9141-2 compatible OBDII interface... while the PCMSCAN website says the supported protocol is ISO-9141... without a -2. I wonder if that makes a difference.

joeyoravec

ISO9141 is the specification for vehicle and the -2 just refers to a particular section of the document. What you're experiencing is a driver problem.

The Tactrix cable is interesting; it is a simple, low-cost voltage converter and implements everything with windows serial driver. Since it doesn't use a standard API, it's only compatible with software written specifically for that cable (ie. the Subaru software you mentioned). It's a proprietary cable and unfortunately you're stuck since PCMScan doesn't support it.

Podaman

NP TunerTools, I'm just glad there's a place like this I can go to when I'm stuck and have questions.


It looks like on the Drew Tech website in the "Matrix of Drew Tech Customers and Product Uses" Subaru is listed as a target customer.

Could you confirm, joeyoravec, that Subaru's don't work with the Mongoose via the J2534 pass-thru standard? I'm not too worried about reprogramming the ECU. I have the OpenPort 1.2 for that now . Will the Mongoose ever support reprogramming Subaru ECUs?

If it's true that Subaru's still don't support J2534 then I guess I'll go with the ElmScan 5 to use with PCMSCAN. I'm curious though... what kind of update intervals do you get monitoring, say, a single parameter, like RPM, over the slower ElmScan 5 serial speed connection? Sub 100ms? I'd imagine the faster Mongoose with it's full-speed USB 2.0 connection can handle thousands of updates a second.

joeyoravec

I can't confirm it because it's not true. But I'll clarify what I think he meant to say:

Similar to the generic driver that lets all printers work together, the SAE (in document J2534) defines a generic driver that lets laptop-to-vehicle PassThru interface cables work together. In this way the low-cost Mongoose cable works perfectly fine with Subarus. You can read and clear codes, pull live parameters, etc. At a basic OBD-II scantool level things are quite simple, always compatible, and the main difference you'll see between tools is speed.

Lloyd's point is that all automakers are required by law to provide reprogramming software to update the factory calibration, but Subaru is on the "naughty" list for failing to provide this software. Subaru assures me that they're working on software and it should be available soon. The older Subarus require a more complex flash tool because they need an extra voltage to enter programming mode. The newer models got rid of that requirement and the Mongoose could probably flash fine. I'll do the testing as soon as something's available.

MP3Car.com

 

Podaman

Great info joey, thanks.

I've read countless times how you and TunerTools swear by the increased speed of the Mongoose. I know USB is much faster than serial, there's no question about that, but...

Do you have any real-world update interval numbers to compare the Mongoose with the serially-connected scantool competition? (besides the generic max theoretical full-speed USB 2.0 12 mbps bandwidth statistic)

Or perhaps a visual description of the real-time virtual dashboard performance difference? (If any)

Surely there must be some comparison benchmarks to demonstrate the advantage of the superior USB connected Mongoose besides the marketing phrases "increased speed" and "high performance".

I would just like a little more convincing (warm fuzzy) before I shell out 200 bucks on a 5' connector. I'm sure you can see where I'm coming from . Maybe this info is already lieing around somewhere and I just missed it somehow... if that's the case, my bad.

Thanks!

joeyoravec

It all depends on the software. On PCMScan in particular the difference isn't huge because he uses a fairly slow technique for requesting data. Aside from the obvious benefit of having a standard cable, the speed does help. It's possible to sniff the bus and not drop a single packet. Can't say that for other low-cost cables.

I'm working on a plug-in library right now that software vendors can use to get the rapid packet datalogging (typical ford/chevy approx 150-200 frames/sec). And now I'm logging off the forum so I can actually get this programming done and push the library into the marketplace. Keep in mind that I design this cable at an electronics manufacturer, but this library should help the software vendors catch up with technology. There should be some great stuff available within the next several months.

benetton

podoman

There is also another piece of software call ecuedit, it also works with the access port 1.2 you can monitor data and even reflash you ecu
here's a link(also free)

http://www.scoobypedia.co.uk/index.p...ourECUROMImage

Attached Images

  

Podaman

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).

joeyoravec

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.

Podaman

Thanks for the info joey!


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.


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?


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!

joeyoravec

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.


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.


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!

MP3Car.com