Open source GM OBD2 flash tool using a ELM327 device

[Tazzi]

Im not going to be infront of the work computer this arvo, but will push my changes up tomorrow. Least there will be an example for reading/writing with J2534 using VPW protocol.

And GM does have a similar thing, they call it dynamic PIDs.. or DPID for short.

You load up a bunch of parameters you want to view in one line of data, and it keeps being broadcasted back for as long as you send the tester present message.

[NSFW]

Would it help to have the app call something like device.SetFilter(...) before it calls device.Receive(...) ?

...

Definitely need to have a set mask and filter before doing anything. For J2534, its basically enforced to do that before being able to send or receive anything.

Thinking about this a little more... the SetFilter method might really belong in the IPort interface.

MockDevice.SendRequest looks like this...

Code: Select all

this.Port.Send(message.GetBytes());

byte[] response = new byte[100];
this.Port.Receive(response, 0, 100);

...so would it make sense to have something like "this.Port.SetFilter(...)" in between the calls to Send and Receive?

[antus]

Yes jaymes adx implements dpid i believe. And priority 1 and 2 data by way of a macro so slow moving stuff like clt dont waste as much bus time. Jayme also found a 4x speed increase logging at vpw 4x... but it loads up the pc pretty hard - the ecu responds fast!

[Tazzi]

Thinking about this a little more... the SetFilter method might really belong in the IPort interface.

MockDevice.SendRequest looks like this...

Code: Select all

this.Port.Send(message.GetBytes());

byte[] response = new byte[100];
this.Port.Receive(response, 0, 100);

...so would it make sense to have something like "this.Port.SetFilter(...)" in between the calls to Send and Receive?

For J2534, we technically dont need to worry about serial ports in any way, its all handled by the manufactures DLL. Whether the connection via direct usb, network, port, wifi or bluetooth, we dont have to actual concern ourselves with the connection type, the DLL does the searching and work for us.

Heres an example of reading/writing to the network, including opening protocol and filters:

Code: Select all

//Open protocol connection: Protocol,speed,connection options,obd2 pin
MyError = MyScantool.ConnectToProtocol(MyModuleData.Protocol, MyModuleData.BaudRate, ConnectFlag.NONE, MyModuleData.Pinout);

//Even though protocol is currently open.. nothing can be sent/received yet!

//Define mask and filter ie: 0xFFFFFF,0x6CF110,0,0,Pass
MyError =MyScantool.SetFilter(ParameterData.Mask,ParameterData.Filter, ParameterData.Flow, TxFlag.NONE, ParameterData.FilterType);

//Data can now be sent/received after mask/filter has been set

//eg. 6C,10,F1,3C,01. DLL requires defined timeout value for failing to write message to network. Final bool is my own implementation to clear read/write buffers
 MyError = MyScantool.WriteMessage(RequestFrame, TxFlag.NONE, MyModuleData.Timeout, False);

//Rxmsg is type PassThruMsg, which is a J2534 message, Holds ALL information including pointers. Timeout and filter are my own variables.
MyError = MyScantool.ReadMessage(Rxmsg, MyModuleData.Timeout, ParameterData.Filter);

//Reads actual data allocated in memory from saved intptr in J2534 message.
byte[] RecBytes = Rxmsg.getbytes();

//Once found the data we want (If not continuously reading), then close protocol. This does not close connection to scantool.
MyError = MyScantool.CloseProtocol();

The MyScantool object is basically what you have defined as the J2534port. And MyError is of type J2534Err, which is the predefined error responses that J2534 can actually have.

Yes jaymes adx implements dpid i believe. And priority 1 and 2 data by way of a macro so slow moving stuff like clt dont waste as much bus time. Jayme also found a 4x speed increase logging at vpw 4x... but it loads up the pc pretty hard - the ecu responds fast!

Ah yes I think thats right.
Would need to put in a framerate buffer to only display live up to 24-30frames/s, but still read all in the background.

[NSFW]

I realize that the word "Port" isn't entirely accurate in this context, and I'm open to renaming that interface and classes to something else. What it really represents is the operating system API that talks to the external device. Some devices use a serial port for that, and the app's StandardPort class is basically just a thin wrapper around the serial port API. The J2543Port class will be be a wrapper around the J2534 API.

Maybe the Port stuff should be renamed to DeviceApi, or something like that? So instead of IPort / StandardPort / J2534Port we'd have IDeviceApi, SerialPortDeviceApi, J2534DeviceApi... Let me know what you think.

Does MyScantool.ConnectToProtocol function need to be called before every WriteMessage/ReadMessage operation? If so, then ConnectToProtocol and CloseProtocol would need to be added to both J2534Port.Send and J2534Port.Receive.

Or, if it would be sufficient to just call ConnectToProtocol once, then it could go into the J2534Port.OpenAsync method. If putting it into OpenAsync will work, then I can add a Close method that gets called when the app is closed or when the user changes devices, and CloseProtocol can be called from the new Close method.

If ConnectToProtocol only needs to be called once, in OpenAsync, then would it suffice to put call SetFilter in the OpenAsync method as well?

Or does SetFilter need to be called prior to each call to MyScantool.WriteMessage? If so, it would need to be called from both J2534Port.Send and J2534Port.Receive.
Or does SetFilter just need to be called prior to each call to MyScantool.ReadMessage? If so, then it would just need to be called from the J2534Port.Recieve method.


There's also the possiblity that the J2534 class just don't translate to the existing IPort interface, in which case I just need to rethink the design a bit. If that's the case, just put all of the calls to MyScantool methods into a Device class for now, and don't bother using the IPort.Send / IPort.Receive methods at all.

[pgbpro2.0@gmail.com]

can you add pgbpro20 as a contributor to the git repo?

let me know what git workflow you'd like to use. In my line of work where we have just a few contributors we tend to commit directly to master when the software is at this kinda phase, then we do feature branches after release. But let me know if you're planning on something different.

I wanted to get Antus's opinion on something - I guess he's looked into writing to J2534 before but mentioned that it was difficult. I looked at the API (which is here: https://tunertools.com/prodimages/DrewT ... _API-1.pdf ) and it looks reasonably straightforward in that the functionality is as you might expect
I.E. PassThruConnect, PassThruReadMsgs, PassThruWriteMsgs, PassThruStartPeriodicMsg and many other features that look like they would come in handy. As a bonus, without having to write any custom firmware J2534 devices support 41.6 kbit/sec AND can accommodate 4,128 byte frames. The hardware is available anywhere @ $119 shipped. Seems like a slam dunk, which almost certainly means I'm missing something.

So my question is, what is the difficulty in writing to J2534?

[NSFW]

I think you mean J2534 rather than J2537? The PDF you linked to is certainly all about J2534, and J2537 doesn't appear anywhere in it...

J2534 is what Tazzi and I are talking about. I think it has a lot of promise. At this point we're exploring a lot of options, and we'll see which one(s) work best.

Which hardware are you thinking of, specifically?

[NSFW]

I'll add you to the git project.

I've just been checking into the main branch directly, but that was when I was working on the app by myself... probably time to move away from that model now. Antus and I were talking about workflow in PMs, and he proposed that we each create a personal branch and integrate from those into the main branch. I like that idea, and I'll start using that approach myself.

[Tazzi]

So my question is, what is the difficulty in writing to J2537?

Not hard
Just got to follow the recommend structure so it actually works. Which is what the example coding above is demonstrating for setting up the connection and reading from the comms line.

I realize that the word "Port" isn't entirely accurate in this context, and I'm open to renaming that interface and classes to something else. What it really represents is the operating system API that talks to the external device. Some devices use a serial port for that, and the app's StandardPort class is basically just a thin wrapper around the serial port API. The J2543Port class will be be a wrapper around the J2534 API.

Maybe the Port stuff should be renamed to DeviceApi, or something like that? So instead of IPort / StandardPort / J2534Port we'd have IDeviceApi, SerialPortDeviceApi, J2534DeviceApi... Let me know what you think.

API, I prefer that alot. Universal for any device that way. Im in the habit of associating port with serial ports

Does MyScantool.ConnectToProtocol function need to be called before every WriteMessage/ReadMessage operation? If so, then ConnectToProtocol and CloseProtocol would need to be added to both J2534Port.Send and J2534Port.Receive.

Or, if it would be sufficient to just call ConnectToProtocol once, then it could go into the J2534Port.OpenAsync method. If putting it into OpenAsync will work, then I can add a Close method that gets called when the app is closed or when the user changes devices, and CloseProtocol can be called from the new Close method.

If ConnectToProtocol only needs to be called once, in OpenAsync, then would it suffice to put call SetFilter in the OpenAsync method as well?

Or does SetFilter need to be called prior to each call to MyScantool.WriteMessage? If so, it would need to be called from both J2534Port.Send and J2534Port.Receive.
Or does SetFilter just need to be called prior to each call to MyScantool.ReadMessage? If so, then it would just need to be called from the J2534Port.Recieve method.


There's also the possiblity that the J2534 class just don't translate to the existing IPort interface, in which case I just need to rethink the design a bit. If that's the case, just put all of the calls to MyScantool methods into a Device class for now, and don't bother using the IPort.Send / IPort.Receive methods at all.

The ConnectToProtocol only needs be sent once. It could be done right at the beginning of connect to the actual scantool it self if you knew you were only going to connect to the VPW protocol.
You could then also do the set filter/mask, and only ever have to send that once if you know you are only ever going to use that filter (Can easily add/remove filters).

After that, you can send/receive as many times as wanted, no other setup commands are required.

You never need to close the connection or change the filter technically. The reason I close the protocol is because different modules/vehicles use a different protocol, filters ect so its a neat and tidy way to clean up resources between connecting to different modules. For example, on a Holden VX LS1 V8, it uses VPW for the engine computer, but then ALDL for the rest of the car

Ok, Ill throw everything into the J2534port, have the working implementation, can then move stuff around and see what additional commands are needed and available.

[Tazzi]

I'll add you to the git project.

I've just been checking into the main branch directly, but that was when I was working on the app by myself... probably time to move away from that model now. Antus and I were talking about workflow in PMs, and he proposed that we each create a personal branch and integrate from those into the main branch. I like that idea, and I'll start using that approach myself.

Im not that familiar with git to make a branch, so may need guidance on that before pushing to the repo