Software On ELM Street - OBD2 Software Development

[TazzI]

Software on ELM Street



Download the latest version from here (v0.0.1.6)


Licenses are FREE to forum contributors, please contact me for your unique (one time use) serial.
For everyone else, please contact me for pricing and availability!

ChangeLog
10/06/2015 - v0.0.1.5a
• Removed MX wifi (still work to be done!)
• Removed Freeze data from startup connection
• Rewritten ELM327 communication handler
• Added Transmission fault/PID reads to startup connection
• Rewritten Engine logging routines
• Added more supported Engine PIDs!
• Fixed a couple LS1 PID calculations
• Added TRANSMISSION Logging capabilities
• Added TRANSMISSION fault reading (No definitions added just yet)
• Added Save/Load and replay options
• Disabled seed/key (Not yet completed with new routines)

14/03/2015 - v0.0.1.4
• Added support for the amazing OBDLink MX WIFI - Complete custom connectionroutines down pack!
• MAJOR change to how ALL error catching is made in program
• Fixed issue with failing freeze frame causes error on other startup info
• Refined various routines
• More major changes to Freeze frame capture. Loops through different timeout values

07/03/2015 - v0.0.1.3
• New vehicles supported added: VZ LS2 V8, VE V6, VE V8
• Refined Freeze frame for CAN vehicles further.
• Begun adding Advanced Freeze frame screen (See freeze frame codes and data)
• New support for OBDLink MX tool (May be the newly recommended tool)
• Overall changes to application to reduce "False" antivirus reports (Norton has no issues)
• Clearing faults on both VPW and CAN vehicles implented

22/02/2015 - v0.0.1.2
• MAJOR update on LS1 fault code reading. Significant error in obtaining correct fault code. This has now been resolved!

22/02/2015 - v0.0.1.1
• CAN Freeze frame complete rework
• Repair minor bug with LS1 freeze frame
• Added LS1 PID's (Calculations still being added)
• Slight changes on serial/vin reading for LS1.

22/02/2015 - v0.0.1.0
• Fixed small mistake with new 500,000 baud update.
• Small changes to "auto detect" sequence, including delays and also timeout parameter to prevent hangning
• Completely redid fault code definitions for LS1 and VZ V6. All GM faults for these ecus have been added.
• Fault clearing routine completed, not yet added to the clear button (next release)
• Remodelled VIN and Serial receive routines. Should work on E38,E40 and other ecus now (Untested change!)

8/02/2015 - v0.0.0.9
• Added 500,000baud option for the fastest possible logging experience.
• Tweaks to cosmetics

4/02/2015 - v0.0.0.8
• Added icons to side navigation bars
• Complete reconstruction of side bar UI to prevent "flashing" controls
• Reworked "Auto Detect" function. Works very well and fast.
• Removed "Restore to defaults" on connection (caused more problems then helped)
• Removed "Disable Chatter" function in startup vehicle data reading to prevent warnings on dash
• Added more detailed error reporting
• Tweaks to the Engine Data reading
• Added other CAN protocols back in for "raw logging"
• Added GMLAN protocol (Standard ELM device does not work!)

9/01/2015 - v0.0.0.7
• Added Save/backup log for key searching routine
• Retry/Skip/Cancel messagebox applied to connection procedure to bypass any unknown faults
• Tweaked the 115200baud enable routine.. for greater stability
• Minor changes to Engine data logging routine
• Additional error captures for freeze frame section applied to narrow down unknown responses in both LS1 and VZ vehicles

[TazzI]

*The original first post above has been moved to below! Same conditions apply.






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

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!

[TazzI]

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.

[TazzI]

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!

[TazzI]

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

[TazzI]

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!

[TazzI]

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

[doubledip]

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

[TazzI]

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

[doubledip]

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