Software On ELM Street - OBD2 Software Development

[Tazzi]

Guess we will find out whether the bugs are still present. Picked up a "v1.5 elm327"... apparently. So will see if it does get random bytes. Will need to suss out a pcm for testing I guess! Otherwise Ill be persting everyone with something that I have no idea if it works! lol

Unless I can mimic the pcm... hmm... might need two cables for that. 1 for reading.. and one to monitor all chatter, manually search for a "request" frame and respond back as the pcm. Im sure the second device would then attempt to get a response to that frame... I *think* this can be cancelled by sending "/r" or something like that.

[Tazzi]

So.. some real basic coding:

Code: Select all

 Public Function DetectElmDeviceGetResponse(SentFrame As String)
        Dim ReceivedFrame As String = ""
        Dim Counts2Exit As Integer = 0
        Do 'do until exited
            Try
                If SerialPort1.BytesToRead >= 2 Then '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 received
                          
                        ElseIf ReceivedFrame.Contains("NO DATA") Then 'Elm says no response.. fail! Shouldnt happen since getting Elm info!
                            Return "Failed"
                        Else
                            Return ReceivedFrame 'hopefully our response
                        End If
                    End If
                End If
            Catch ex As TimeoutException 'if nothings available, timeout after 1 second, Elm should respond within 400ms
                Counts2Exit += 1
                If Counts2Exit = 3 Then 'fail after timeout 4times
                    SetRichTextBox_ThreadSafe("Timed Out!", RichTextBoxReceive)
                    Return "Failed"
                Else
                    SetRichTextBox_ThreadSafe("Timed out.. Searching again.." & Counts2Exit, RichTextBoxReceive)
                    'retry again.
                End If
            End Try
        Loop

    End Function

Currently have this to search for the ELM device response when connecting and sending "ATZ" to the device. It looks for the a response.. checking the buffer till something pops up. If it received the "ELM" Text, it means connection established!

Havent found really any other responses that the elm will put out apart from "Searching" and "No data".

Will need to put in a fail safe if buffer never gets anything.. easy enough.! Might just get it to attempt reading, then let it timeout a few times if nothing available before failing. Although the elm should timeout after 400ms.. so I doubt if that will be an issue.
Im avoiding using the "data-received" event as well.. just prefer doing it my way.

Should pretty much be able to apply this to do proper reads of trouble codes ect although only using this to confirm the elm cable at the moment. Pretty basic but will work for the moment.

[Tazzi]

Any brave sole want to try this out? All its doing is verifying that the comport being connected to is an elm device. Doesnt need to be connected in car.

Has no functionality apart from the above and clearing the buffer!

Taz.

[VX L67 Getrag]

Wish I had a car I could test it out on!

BUT AWESOME WORK!

[Tazzi]

Wish I had a car I could test it out on!

BUT AWESOME WORK!

Haha, doesnt need a car, all its doing is checking the cable is there lol. Literally does nothing but check the cable

Anyfeed back from anyone is good feedback, I cant actually test this since I dont have the cable. Bit confused on whether I need to search for the ">" character, and whether this is sent after AT commands or any command for that matter.

[delcowizzid]

nothing happens with mine says connecting to device but doesnt find anything

[Tazzi]

nothing happens with mine says connecting to device but doesnt find anything

Not sure then, ill have to wait till my cable pops up then, since its hard to know what exactly is going wrong.

Nothings happening cause it gets stuck in an infinite loop cause it isnt receiving anything. (I said I needed to change that before lol.. knew it would bite me in the ass).
The ELM pdf says to use a carriage return as the "end of line", thats what I set.. but think I need to investigate further. It should have picked up the "ELM327 Vxxx" with a "Environment.NewLine" at the end (carriage return).

Obviously not the case!!

Ill change that infinite loop so that it actually times out if nothing happens. Might have make a textbox that show shows everything in the buffer to get an idea on whats happening!

[Tazzi]

Ah found where it was going wrong.. oops. Was using vbnewline instead of vbCr (Carriage return).
Picked up the "ATZ" request from another obd software perfect after changing that. should pick up the response form the elm device fine now.
Will update later today.

*Edit
Attached the new copy. Should pick up the elm device and display that its connected and also version number.

[delcowizzid]

desktop PC no luck its had usb issues so may not be your fault and laptop sadly doesnt have .net v4

[Tazzi]

Went through the ELM pdf and wrote down the main commands that will be used, how to use them and how the elm will respond.

Looks like it always uses a carriage return as the end of line. And then the elm prints ">" to signify that elm is "idle".
Will be good practice to send off a command, get response then look for the ">" to notify the software that the elm is at idle and ready for next command.

But if the elm does get a response, it generally goes straight to idle anyways, so can be an added option to "check for idle".

Its all a matter of once you get it working correctly once, it should always work. Wont be requiring anything fancy to read trouble codes and PID's, and even if the buffer is full, its easy enough to empty buffer and resend.