VPW - RS232, no hardware required

Hi All,

Geat forums :D Cool board!
Hope I can finally give back something useful to the DIY community.

I have developed a piece of software that reads the SAE-J1850 VPW signal directly into a PC com port - no hardware needed.
Maybe some voltage regulation and filtering but no "intelligent" hardware is required.

I have pulled trouble codes using the software - it works but it needs to be made more stable.

I anyone is interested - the source code is 100% free and available here:
http://www.blacky.co.nz/free (called VPW)
Or use the batauto mirror if geocities spits the dummy.

The software will not run under WinNT or Win2k due to not being able to access the serial port hardware.
It is very unstable under Win95/98 due to Window's interrupts.
It is a little unstable under DOS due to DOS interrupts.

If anyone wants to work with me to clean up the timer routines and in preventing the interrupts - then this could be turned into a 100% free solution for pulling OBD-II trouble codes on a DOS PC. No need for expensive hardware.

I'll make the code available and if the members of this board can get it to work properly then I will add the code to pull the trouble codes. I would like to see any software that uses this software driver be made freely available.

Even if can be made stable I would not recommend using it for anything other than pulling trouble codes (with engine off) because it does not implement bit arbitration and therfore it screws up other messages on the BUS.

Any DOS programmers want to try and get it working properly?

Any electronics experts know if plugging the classII data line into your PC serial port can cause electrical problems?
If so what's the bets way to match the voltage levels required?
(I've plugged them together a number of times and not suffered any problems but maybe I was just lucky)

The VPW spec says classII data line:
Input: Low voltage is -1.0 to 2.2V, High voltage is 2.8 to 6.25V
Output: Low voltage is 0 to 1.2V, High voltage is 3.8 to 5.25V

Regards
Paul

the voltages are within acceptable serial limits
You could isolate them with optical or digital devices pretty easily.
The serial port transmits a '1' as -3 to -25 volts and a '0' as +3 to +25 volts where as a parallel port transmits a '0' as 0v and a '1' as 5v.

I can see what you mean with timing issues.. However extremely good idea to play with..
now i gotta find my borland cd..weee....

hey ls1...
Do you have any documentation on the VPW protocol? I'm especially curious about the downloading and uploading of the program. I also want to know how it talks in general for diagnostic purposes.

-Dusty-

Here's some low level info on the J1850-VPW protocol - it won't help much except if you are desigining an interface cable.
http://developer.intel.com/design/in...0_wp.pdf<br />
As for how to upload/download and request diagnostic info the HS3000 book from SAE will tell you most of what you need to know.

And GM has a whole lot of &quot;manufacturer enhanced&quot; information that is not available to the &quot;puiblic&quot;.

Regards
Paul

well.. thats a very interesting document.. I'll just cram it into the mess that is now my brain.. lol
I already found one useful thing from it..

does anybody have that hs3000 book in pdf? I found it once but the file was so corrupted i could only read a small part...

but x-mas is coming up.. lol

The book (HS3000) is good, in that it tells you everything about the SAE standards - but......

GM sometimes does not stick to those standards - you'll still need to do lots of &quot;hacking&quot; to figure out what the heck the GM implementation of OBD-II is sometimes doing.

&lt;Rant&gt;
Wherever the SAE spec says &quot;manufacturer's should do xyz&quot; - GM usually does not do xyz.

Wherever the SAE spec says &quot;Manufacturer specific data may be included&quot; - GM usually includes some specific data.

Wherever the SAE spec says &quot;the following values are reserved for manufacturer defined values/results&quot; - then GM uses those manufacturer defined values and results.

It seems that only where SAE/CARB legislated diagnostic standards apply, that GM actually complies. And usuually not 100% compliance either.
&lt;/Rant&gt;

While your ranting on what GM should or should not do with enhanced functions which are outside of SAE it should also be noted that vendors making PCM scanners that are to comply to SAE/EPA do not.

Good example is efilive, put a RS232 monitor inline to the cable and spy on ISO layer 2 and you'll see OBD-II data slamming away in data block mode which is for GM flash movement and then the scanner vendor bitching about GM while hogging the class B bus preventing other nodes in the car from doing their job.

If your really wanting to help, put efilve source code into public domain so others can see how you code, or is it your here to learn and then market a programmer against LS1edit ?

Its about time you quit blaming GM for your lack of understanding in your backward engineering for we resent telling us what we should or should not do.

Quote:

---

Originally Posted by fastz06

While your ranting on what GM should or should not do with enhanced functions which are outside of SAE it should also be noted that vendors making PCM scanners that are to comply to SAE/EPA do not.

---

EFILiveV5 is not designed to be an emissions compliant scan tool. We have never claimed that EFILiveV5 complies with SAE/EPA requirements. It is not an emissions testing tool. If you want an emissions testing tool buy an emissions testing scanner.
I am not ranting about enhanced functions - I am stating facts that GM does not implement the SAE recommended practices for some of its functions that fall WITHIN the SAE specification.

Here's a quick list off the top of my head (by no means complete):
VIN number retrieval is not supported via J1979 mode $09 - uses J2190 mode $3C instead.
Scan tool data rates ($00-$04 not supported - uses $14 and $24 instead)
J2190 mode $18 not supported uses mode $19 instead.

Quote:

---

Originally Posted by fastz06

Good example is efilive, put a RS232 monitor inline to the cable and spy on ISO layer 2 and you'll see OBD-II data slamming away in data block mode which is for GM flash movement and then the scanner vendor bitching about GM while hogging the class B bus preventing other nodes in the car from doing their job.

---

That's just plain wrong - I do not know where you get your information from but EFILive never uses block transfers. (I assume by block transfers you mean J2190 modes: $34 to $37).
EFILiveV5 uses a block read (SAE J2190 mode $3C) to retrieve the VIN only because GM does not support J1979 mode $09 which is the SAE specification for retrieving VIN.

All data logging is done using J2190 mode $22 or J1979 mode $01 which is the SEA recommended mode for &quot;Request Diagnostic Data&quot;. If using that mode is somehow &quot;incorrect&quot; then the GM implementation differs from the SAE recommendations - which is my point exactly. I do not believe using mode $22 is incorrect - GM themselves use that mode to retrieve diagnostic data.

Did you know that during high speed data logging, EFILiveV5 only sends ONE message onto the bus every 4.5 seconds? How that can be called &quot;slamming&quot; or &quot;hogging&quot; (technical terms I presume) I cannot imagine.

Can you post a log of the RS-232 monitored data and highlight any &quot;Block transfer&quot; modes that are normally used for flash movement? I know you won't find any because I wrote the code and I know there is no way that those commands are used by EFILiveV5. But I am interested to know why you believe that EFILiveV5 uses these &quot;block transfers&quot;. So document the data you monitor from the RS232 line and highlight what you think is a &quot;block transfer&quot; and maybe I will understand what you mean.

Quote:

---

Originally Posted by fastz06

If your really wanting to help, put efilve source code into public domain so others can see how you code, or is it your here to learn and then market a programmer against LS1edit ?

---

Personally I would love to put the code in public domain. If it was just mine I would. There are many people involved who have invested time and money and expect some return for their investment.

I could not care less about making an editor. The only reason we developed EFILiveV5 was because we needed a fast scan tool. We thought about building an editor but when we found out about LS1Edit we saw no reason to - why reinvent the wheel? - we don't have time.

If I just wanted to suck info from this board - do you think I would be posting here - I would have just lurked like others do. You could not be more wrong about my intentions.

Quote:

---

Originally Posted by fastz06

Its about time you quit blaming GM for your lack of understanding in your backward engineering for we resent telling us what we should or should not do.

---

I am not telling anyone what they should or should not do.
And I am certainly not blaming GM for anything. I am merely stating facts (ok so I enclosed the text in &lt;RANT&gt; quotes) about GM's implementation of the OBD-II spec.

If EFILiveV5 is doing something the wrong way - and you can explain exactly how and where and why it is wrong - then I will certainly investigate and fix the problem. But posting vague (and incorrect) statements is, well just pointless.

Lighten up a little - this board is for sharing of information. I explained in the &quot;Lounge&quot; that I am not here to take but to give - sheesh check out the first comment in the first post in this thread.

By the way who is the &quot;we&quot; for whom you claim resentment? (Your writing/grammar style is similar to someone else I know - maybe you know him too :)
Anonimity is usually reserved for those who have a hidden agenda.

Regards
Paul

FYI,--a small clarification:

&quot;Block&quot; reads are usually used to read the VIN number. This is a specific command that GM uses to get what is called &quot;Block Data&quot;. It uses a normal OBD2 command packet structure and retrieves 1 to 6 bytes of data for each request made.

The &quot;block mode transfer&quot; is entirely different, and is what GM uses during programming and uploading of the PCM. It is a slightly different OBD2 protocol, and allows transferring a large uninterrupted &quot;blocks&quot; (typically 1K to 4K) of data in a single &quot;packet&quot;. Because there is less overhead in sending one large block than say 1000 small packets, the transfer is much faster overall.

Couple block-transfer mode with 4X speed (41.6K baud) and programming of larger ECMs (say an LS1 at 512K bytes) only takes 2 minutes rather than 10 minutes.

It all depends on how you write the upload and download code - or if you 'borrow' GM's code for this.

Gary

You guys (ls1tools, Rufus) obviously know more about this than I do.

I have been trying to find a way to get a dump of the Flash from a GM PCM and then reflash it through the OBD2 interface.

You both are talking about block mode transfers which &quot;GM uses during programming and uploading of the PCM&quot;. Do either of you know how to use this mode of communication and the commands to program or upload to the PCM?

I currently am programming a scanner for use with AutoTap v2 and would love to add these functions.

It may not be possible to download/upload the flash using the AT V2 interface. The code in the PCM sends/receives about 1000 bytes per frame - the AT V2 interface is only capable of sending/receiving a maximum of 32 bytes per frame.
You may need to design your own hardware which is capable of those block sizes - or reprogram the upload/download routines in the PCM to accept smaller frames.

couldn't you change the loader program to accept different sizes? Since you would pretty much have to write your own loader program anyway at that point it would seem..

The Autotap interface I have seen has the right hardware present, but the firmware probably does not support these extended modes of operation. If you want to learn more, go to the Motorola website and get the documentation on the MC68HC58 J1850 DLC controller chip. (you will have to search for it - it is well hidden). Mot also has numerous app notes on OBD2.

You could take a autotap interface and remove the PIC micro and replace it with your own, and write the code to support the extended functions. If this was placed in the 'public domain' there are perhaps others who would contribute to defining and writing the interface firmware - but it is not simple - and it must be absolutely reliable (unless you enjoy disassembling and reflashing LS1 boxes...)

Than might be the simplest way to get started.

Gary

&quot;Any electronics experts know if plugging the classII data line into your PC serial port can cause electrical problems? &quot;

Hmm, this looks interesting. Smells like strobing to me... :D

DTR pin state (0 = -12V, 1 = +12V)
RTS pin state (0 = -12V, 1 = +12V)

Value DTR RTS
sent state state

0 -12V -12V
1 +12V -12V
2 -12V +12V
3 +12V +12V

The standard I/O port addresses for different COM ports are following (in some systems are are some different one used sometimes):

Serial Typical I/O Memory location (in DOS) where
port address I/O address in use can be read

COM1 3F8h 0040:0000
COM2 2F8h 0040:0002
COM4 378h 0040:0004
COM4 278h 0040:0006

Here's the voltages you can draw from the port:

1488 positive +9..11V +5V @ 6.5 mA 98 mW
1488 negative -9..11V -5V @ 6.5 mA 78 mW *
MAX232 positive +7.5V..8V +5V @ 5 mA 75 mW
MAX232 negative -7.5..8V -5V @ 3.5 mA 42 mW *
EIA-562 positive +3.7..5V +4.5V @ 1.5 mA none
EIA-562 negative -3.7..5V -4.5V @ 1.5 mA none

Beware some new laptops and desktops that only accept +/- 5v on the serial port

that help any?

Guys,

How does the MC68HC58 data link controller lock onto an ECM's VIN number/ECM?

1. I'm using a tuning software program with a J1850 GM Class 2 contoller board that locks to the ECM. Is there a product available for me to alter this?

2. I assume somehow the tuning software flashes the EEPROM? Is there a way I can read it and alter it as I choose?

Thanks in advance,
Frank

Frank, what you are trying to do sounds illegal.

Are your intentions within the limits of the EULA for your product?

What product is it?

You will not find a solution to alter the contents of the MC68HC58.

Please proceed carefully.

Keith,

Just trying to understand the technolgy and how it works. I would like to build my own products someday and hope that folks like you can help me understand how this works. I'm mostly a gear head and enjoy messing with my cars/motorcycles. My 1st SERT package I bought didn't work on my motorcycle and I can't seem to get a refund so I had to buy another package and wasn't happy at all. I have two motorcycles and two SERT packages. One works and the other doesn't.

Based on your input then I guess I'm out $400.00 unless you know where I can purchase just the interface?

Frank

No interface exists that I know of that will allow you to alter the contents of that chip, sorry.

If you want to get into the DYI scene, I'd recomend picking up an ELM setup and start playing with that. It's a great starter setup.