Welcome Anonymous !

Everything you need to modify your ride
 

GM Technical Document Discussion

OBD2 Software Development

A place to discuss the technical documents for GM vehicles such as Holden, Chevrolet, Opel, Vauxhall, Buick, Cadilac and Daewoo
Forum rules
To gain access to the Invite Only forum you must be invited by a member of that forum. That member will PM the mods or admins (NOT you) saying that they nominate you for access. THEY will be responsible for your actions. If you don't post and just leech info, you will BOTH be removed. Dont send a PM to the moderators or admins asking for access, you really dont want to see the result. If you submit information, you may simply be invited :)

Postby TazzI » Sat Sep 21, 2013 7:40 pm

*Note, Before I go any further, any software,postings,findings or information that I find and you use is at your own risk! This is all experimental software that will more then likely have bugs.

So Iv seen alot of threads and comments about finding good OBD2 software to use with an elm.. and well... So far the options are very limited! Alot of the current programs either a) cost money for a useless software or b)are free/cheap but dont work correctly.

Then finding an application that will present the manufacture specific codes is even harder to find, let alone finding one for Holden!

So the aim here is to develop a basic application to read holden commodores fault codes, including history and present codes. As well as identifying the cable and current details.

Some reading material for the OBD2 protocol:
http://www.fastfieros.com/tech/vpw_comm ... otocol.htm

And the ELM327 datasheet:
http://elmelectronics.com/DSheets/ELM327DS.pdf

So the first plan of action is making something successfully send a message to the elm327 device to check that the cable is present, and that communication is working.
Next will be to set the required conditions such as turning on headers,turn off echo,remove null bytes ect.
And lucky last, applying the above to successfully send a request eg 01 04 which is a mode 1 request for PID section 4.

For fault codes, we will be investigating mode 3 and 7. I *think* 3 is current codes and 7 are history.. (not 100% sure).

First up, connecting to the elm device, and checking that it is present.
The elm connection requirements are: baud rate to 38400, set to 8 bits, no parity bits,1 stop bit and set it to the correct line end mode (single carriage return character).

So thats easy enough to setup! Now we want to actually check that we have connected to an elm device, So now we will want to send "ATZ" which is the command to "reset" the ELM device, and the ELM devce will send over serial "ELM327 v1.5" (whatever version), which will end in a carriage return that software can pickup as the end or message.
The ELM will also spit out ">" after all commands, this signifies that device is idle and ready for a request.. so will need to add a function in to check for this after receiving a message to check that is the end of the potential message/s.

Currently, I am using this code to request info from the elm device to check if device is present:
Code: Select all
Public Function DetectElmDeviceGetResponse(SentFrame As String)
        Dim ReceivedFrame As String = ""
        Dim Counts2Exit As Integer = 0
        Do 'do until exited
            Try
                'if there is something there.. read it!
                ReceivedFrame = SerialPort1.ReadLine 'Read Message!
                If ReceivedFrame <> SentFrame Then 'check if recieved frame matches sent.. ignore if so
                    If ReceivedFrame.Contains("SEARCHING...") Then 'ignore.. move onto next
                        'ignore this
                    ElseIf ReceivedFrame.Contains("NO DATA") Then 'ELM says no response.. fail! Shouldnt happen since gtting Elm info!
                        Return "Failed"
                    Else
                        Return ReceivedFrame 'hopefully out response
                    End If
                End If
            Catch ex As TimeoutException 'if nothings available, timout after 1 second.
                Counts2Exit += 1
                If Counts2Exit = 4 Then 'fail after timeout 4times
                    SetRichTextBox_ThreadSafe("Timed Out!", RichTextBoxReceive)
                    Return "Failed"
                Else
                    SetRichTextBox_ThreadSafe("Timed out.. Searching again.." & Counts2Exit, RichTextBoxReceive)
                End If
            End Try
        Loop
    End Function


The above code doesnt have any implementation to check for the elm device at idle (">"), and currently isnt picking up the elm device. I am hopefully getting a cable in the next couple days so I can properly debug the application to check why its missing the frame, although using a "elm327 emulator" works with the above code.
User avatar
TazzI
Module Guru
 
Posts: 572
Images: 2
Joined: Thu Dec 22, 2011 8:02 pm
Has thanked: 11 times
Been thanked: 31 times

Postby TazzI » Sun Sep 22, 2013 1:07 pm

Have implemented a "check elm is idle" function to run after every request. Seems to work fine.

Application also works fine using various elm emulators and also a fake elm that Iv developed as well to run along with the program.

Unfortunately it hasnt worked with a "real" cable yet as tested by someone else. Im unsure why though.. not sure if it was because of a different elm interface? or if cables dodgy? Or possibly application doesnt work correctly on WinXP due to the .net 4 framework requirements.
Running program in a virtual machine should let me know if thats the case.

ELM cable is on the way anyways, be nice to make some progress without it though!
User avatar
TazzI
Module Guru
 
Posts: 572
Images: 2
Joined: Thu Dec 22, 2011 8:02 pm
Has thanked: 11 times
Been thanked: 31 times

Postby TazzI » Mon Sep 23, 2013 12:47 am

Some progress has been made!! Woop woop.
Will successfully Connect to an elm device, will display its version, and will also grab the input voltage.
Note that elm must be plugged into car or have voltage into the obd plug.

Sooo whats next?
Setting up the correct headers, removing echo, turn off linefeed and then begin sending frames for engine rpm,temp ect. And of course, get the trouble codes.. which shouldnt be an issue.

Also have a "semi working" fake elm that im using to test my program and others. And also have a fake pcm that im slowly building which will be used to reverse engineer the tech2... going to be a bit harder as the elm likes to have responses each time.. but I think that can be worked around. All else fails, will need two ELM cables to reverse, one to monitor traffic and the other to write data back.
User avatar
TazzI
Module Guru
 
Posts: 572
Images: 2
Joined: Thu Dec 22, 2011 8:02 pm
Has thanked: 11 times
Been thanked: 31 times

Postby TazzI » Mon Sep 23, 2013 12:51 pm

Done a quick test with the elm emulator... looks like all is working!
[10:39:09:713] Attempting to Connect to Comport...
[10:39:09:715] Searching for Device...
[10:39:09:777] ELM Device Successfully Found!
[10:39:09:778] Checking ELM Status..
[10:39:09:778] ELM is Idle
[10:39:09:779] Disabling Echo...
[10:39:09:808] Echo Disabled Successfully!
[10:39:09:809] Checking ELM Status..
[10:39:09:810] ELM is Idle
[10:39:09:810] Disabling LineFeed...
[10:39:09:840] LineFeed Disabled Successfully!
[10:39:09:841] Checking ELM Status..
[10:39:09:841] ELM is Idle
[10:39:09:842] Enabling Headers...
[10:39:09:873] Headers Enabled Successfully!
[10:39:09:873] Checking ELM Status..
[10:39:09:874] ELM is Idle
[10:39:09:875] Setting Headers...
[10:39:09:904] Custom Headers Set: 686AF1
[10:39:09:905] Checking ELM Status..
[10:39:09:906] ELM is Idle
[10:39:09:906] Checking Input Voltage..
[10:39:09:937] Voltage Found!
[10:39:09:938] Checking ELM Status..
[10:39:09:938] ELM is Idle

Hoping to hear back some good results that this works with a proper cable. If so, everything is set and ready for custom frames to be sent! :D
User avatar
TazzI
Module Guru
 
Posts: 572
Images: 2
Joined: Thu Dec 22, 2011 8:02 pm
Has thanked: 11 times
Been thanked: 31 times

Postby TazzI » Tue Sep 24, 2013 5:37 pm

Looks like some manufactures of elm devices or the clone elm327 manufactures must of been lazy with how "accurate" they made the device. Or other developers just have different requirements for connection.

Iv updated the program with more baud rates including 115200 and 57600 to be tested out with cables that are not connecting at the standardized rate of 38400 as stated in the elm327 datasheet. If that works.. it should be all smooth sailing from here on.


A bit of reading up has given me some insight to why many users get the "BUFFER FULL" message when attempting to use there cable and other software. Basically, it looks like the old elm cables just didnt have enough memory to hold all the incoming messages when there is alot of traffic over the comms. But the New elm cables (legit ones) have a bigger buffer and also parse the information different preventing such an error from occuring. But if the cable has veen brought of fleabay,, its more then likely an older type elm cable with the version number hacked.. thus will probably get the infamous buffer full message.

Something I found reading around:
If you need to use elm, then remember that the data rate of the can bus is likely at 500 kbs and the comms back to the pc is 115.2 kbps. So when the data throughput on CAN is high the link back to the pc is a bottleneck that results in the can buffer not able to be serviced fast enough. Thus buffer overflow.


We are not using the CAN line, although the concept is the same. Generally this error will occur when sending "ATMA" which stands for 'monitor all data', this listens and displays all the data currently in car. I think a simple solution to the buffer full is to simply catch the error (Buffer Full), then reset the device and continue listening... problem solved. :lol:
It may not capture every last piece of data.. but at least it wont be stopping every few seconds and require manually resetting.

Iv emailed the developers to see if there isnt any advanced commands or such to clear/empty the elm buffer manually, not expecting any good news but worth a try
User avatar
TazzI
Module Guru
 
Posts: 572
Images: 2
Joined: Thu Dec 22, 2011 8:02 pm
Has thanked: 11 times
Been thanked: 31 times

Postby TazzI » Wed Sep 25, 2013 11:28 am

Iv read around in some support threads and seems sending ATS0 will help with preventing buffer full issues. This stops the elm from adding spaces between each pair of characters thus using less memory and also allowing for quicker responses thus preventing buffer from over flowing.

Iv also added in a side navigation bar since it was becoming too cluttered with different bits and pieces.

Attached is current version of obd2 logger. So far I have heard that it successfully connects to the elm cable at baud 38400, and does all required setting up. Although have had no luck with getting any engine data.. not sure if that is because the pcm isnt responding or not.. hopefully figure that out soon!
Progress hasnt been too bad consindering I dont have a cable my self lol, be good if I had a fully functioning logger before mine rocks up!

Taz.

*Note, Use at your own risk! Application only uses "read only" requests, Recommended for anyone with bench setups or wants to see this update quicker!
Image
You do not have the required permissions to view the files attached to this post.
User avatar
TazzI
Module Guru
 
Posts: 572
Images: 2
Joined: Thu Dec 22, 2011 8:02 pm
Has thanked: 11 times
Been thanked: 31 times

Postby TazzI » Wed Sep 25, 2013 4:21 pm

I got a heads up that the elm327 cable must be plugged into the diagnostic port with ignition on for the cable to respond and work. The user having trouble connecting is now connecting with no issues! Hopefully they can pull engine data next
User avatar
TazzI
Module Guru
 
Posts: 572
Images: 2
Joined: Thu Dec 22, 2011 8:02 pm
Has thanked: 11 times
Been thanked: 31 times

Postby doubledip » Wed Sep 25, 2013 5:41 pm

tried the software on connection the ignition voltage is found but after that the ignition check doesn't find anything nor the vin
You do not have the required permissions to view the files attached to this post.
doubledip
Major Contributor
 
Posts: 250
Joined: Sun Mar 04, 2012 9:40 pm
Has thanked: 26 times
Been thanked: 18 times

Postby TazzI » Wed Sep 25, 2013 6:11 pm

doubledip wrote:tried the software on connection the ignition voltage is found but after that the ignition check doesn't find anything nor the vin

Cheers Double,
Good to see it set the protocol and all that fine.

Yeah I wouldnt bother with the vin yet. Its coded in although I have no examples to go off of on what the response will be like for holdens hence it fails because it doesnt match what I "thought" would happen! BUT.. "Could not get vin" is a good sign as it means it found something.. so it did work...I think.. otherwise it would have timedout lol.

Its the engine data read that I need to get working first, once I have a working simple read, everything else can be put together and based off that.

Did you try clicking "read" in the engine data section? Itll do simple PID request of 010C for engine RPM and 0105 for coolant temp
User avatar
TazzI
Module Guru
 
Posts: 572
Images: 2
Joined: Thu Dec 22, 2011 8:02 pm
Has thanked: 11 times
Been thanked: 31 times

Postby doubledip » Wed Sep 25, 2013 7:18 pm

yes I did and it didn't work... what ecu are you basing this off... this was just off a E38.. which is can ;)

are you using a LS1 or try with a Memcal based pcm with uart
doubledip
Major Contributor
 
Posts: 250
Joined: Sun Mar 04, 2012 9:40 pm
Has thanked: 26 times
Been thanked: 18 times

Next

Return to GM Technical Document Discussion

  • View new posts
  • View unanswered posts
  • Who is online
  • In total there is 1 user online :: 0 registered, 0 hidden and 1 guest (based on users active over the past 5 minutes)
  • Most users ever online was 128 on Tue Apr 17, 2012 7:57 pm
  • Users browsing this forum: No registered users and 1 guest