thanks for that info,Quote:
Originally Posted by UKOBD
although I am quite sure that it is compliant, I will go have a look...!
[HL]
for those whom are taking the Other in the poll,
please type in what "other" is..! :)[/HL]
Printable View
thanks for that info,Quote:
Originally Posted by UKOBD
although I am quite sure that it is compliant, I will go have a look...!
[HL]
for those whom are taking the Other in the poll,
please type in what "other" is..! :)[/HL]
there's a pin in
1, 2, 4, 5, 7, 11, 12 and 16
so, my vehicle should be OBD compliant.!
I have and use Auterra's Dyno scan. I love it because in addition to reading codes, resetting check engine lights and monitoring engine functions, it also functions as an engine dyno. I frequently do 3 runs, average them, then make my repairs or modifications and do 3 more runs. That way I can see how my repair/mod has effected power and torque. It's really cool! It will also do 0 -60 and 1/4 mile times, but I haven't used that yet, especially since it relies on the cars vehicle speed sensor and I don't know how accurate my car's speedo is.
I don't know if it works with your car or not. I do know the USB version is CAN compliant, but you should go to their website and check it out. They do respond in a timely fashion to emails.
I thought there was some kind of issue with ELM scan tools, which is why I didn't go with one in the first place, but I don't remember what the issue was. I think it was compatibility with certain model cars. You'll have to research it yourself.
Good luck.
one thing that I have forgot to mention is that I am going to write some software for it myself (or integrate it in some other software)
so there would have to be some libraries included, or the opportunity to read the incoming serial data received from the device...
Profozone,
sounds like a nice one, I will try to mail them and ask if they know if it will work with my car.!
Mongoose HomepageQuote:
Lukeyson: (or other) could you help me with a homepage of the Mangoose..?
I was wondering a little bit about the mengioned OBD Readers.
what is the std functions with OBD readers like ELM, OBDpro Mongoose..?
obviously it read the codes,
but does some of them have the posibility to write anything,
or any other extended features..?
and please, someone vote some more :)
thanks for the patience and help on this guys.!
Have anyone tried the MBD3200.?
and is it a good product, compared with the other once..?
Think of all of these scantools listed as just 'converters'. They simply convert USB / Serial to one of the supported OBD2 protocols.
All of the 'smarts' are then in the software you use, unlike many other 'handheld' tools where all of the 'smarts' about what information can be extracted are in the units themselves. PCMSCAN is a 'generic' piece of software, in that it can issue queries that have been made 'standard' by the EPA - standards that are defined by either the ISO in Europe or by SAE in the US. These two organisations have cooperated on this topic, and many ISO and SAE standards are identical for this purpose. The main standards in question are J1979 and J2190 - but if you can get hold of HS-3000/2006 from the SAE (and >cough< share it with me!) it will have pretty much all that you want in it already.
However, all of these scantools are capable of more. How much more depends on what you can learn about manufacturer specific configurations for your car.
While PCMScan can be used for 'standard' queries - generally to just the Powertrain Control Module - if you know what you are doing, you can get pretty much what you want out of any module. However, there are some tricks. And most of these tricks are hidden from general access so that manufacturer service centres are the only one's with full oem capabilities - effectively locking out independent service centres. (Go hunting for the 'Right to Repair' movement website and add your name to the list if there is one....)
When it comes to 'programming' modules, there is often more involved. Where a module just needs a certain Mode activated or a response to a security challenge, yes, all of these tools can be used. But in many cases flashing the Powertrain Control Module requires something else - like an applied voltage on a certain non-standard 'pin' on the OBD2 port for example.
In the Ford world, this is known as 'FEPS' - and is a pin that requires 18V to permit a flash upload or calibration change. None of the ELM based tool support this, and most of the Mongoose tools don't either. However, there is a Mongose CAN/VPW+FEPS tool that supports this - and in fact the more expensive brother of the Mongoose (the CarDAQ?) supports FEPS in addition to other manufacture flash requirements I believe.
The beauty of this is that J2534 (the standard that the Mongoose uses) was originally conceived to define an industry standard method for 'reflashing the PCM' to allow improvements in emissions, such that anyone can do it.
So there is some software for Fords at the Motorcraft website that you can buy, download, and subscribe to that gives you access to updated Ford calibrations. And you can use the Mongoose (or CarDAQ) tool to upload these calibrations to you car. Many other manufacturers are also following suite with J2534, such as GM and Subaru, and there may well be many other's that i'm not aware of (thanks to my Ford-only goggles!).
So for reflashing, at the moment the cheapest option is the Mongoose CAN/VPW+FEPS. If you're not reflashing, but need high speed and good J2534 compliance, any other Mongoose is oK (For me the Mongoose CAN/ISO is relevant). But for generic cheap scantool access at the expense of not having a tool that is as fast or supports J2534, go for anything supported by PCMSCAN in my opinion. But the ELM327, or any other ELM327 command compatible tool, is a good option.
Lukeyson
Lukeyson gives a good description of the landscape for devices that connect to the vehicle. I suppose that a rough breakdown in the ways these devices can be used might be:
1) sending and receiving messages to/from controllers on a vehicle's network(s) to do things like sense events and device states (e.g. OBD data, gear selection, etc.), and to actuate certain devices (e.g. door locks, mirrors, etc.)2) reprogramming or "reflashing" controller software or calibrations to improve performance, fuel economy, emissions, etc.
As Lukeyson says, not all devices do both (1) and (2). The J2534 spec allows for both capabilities (1) and (2), though I don't think all J2534 devices implement both capabilities. I don't believe devices like the ELM are capable of (2), but I may be wrong.
Overall, especially for (1), I'd generally recommend J2534-compliant devices (e.g. the Mongoose from http://www.drewtech.com, the ValueCAN {CAN-only} from http://www.intrepidcs.com, etc.) for reasons of performance, stability and programmability. The ELM is nice because of it's relative ease-of-use and support for all the common vehicle networks, but it has performance limitations (especially on CAN networks), cannot "do" multiple networks simultaneously (apparently), and limited filtering ability. And although the ELM is easier to use "manually" (i.e. typing commands in a serial-connected terminal emulator, such as hyperterm), the ELM is actually more clumsy to do robust programming against vs. against a J2534-compliant device (my opinion). The truth is, although it is nice to have a single device that supports all network types (such as the ELM), I think you would only benefit from that versatility if you used the device among multiple vehicles. But on any given vehicle, you typically would *not* have more than CAN and/or one other network (e.g. J1850VPW, J1850PWM, ISO9141, ISO14230, etc.) for which the Mongoose design is sufficient (i.e. CAN + one other network). For vehicles that have multiple CAN networks, you'd typically need multiple devices whether you used a Mongoose/ValueCAN-class device or an ELM-class device (although there are more high-end J2534-compliant devices which support multiple CAN networks, their cost is high-end as well).
I cite devices such as the Mongoose, ValueCAN and ELM above, but there are certainly other devices out there on the market (e.g. VMSpc, MBD3200SE as mentioned in this thread, etc.). I just don't have any experience with them, so I can't opine one way or the other.
As an aside, you might have seen in another post to this forum ("An easier way to write software that interacts with your vehicle"), which describes how the Cardix programming platform insulates you from these vehicle-connection hardware programming differences (among other benefits). Your application is only concerned with the data it wants, not how to talk to the vehicle connection device(s).
Lukeyson and Carlocutor thanks for the great explanation,
really helps alot.!
it sounds like the mongoose would be a great choice.