Software On ELM Street - OBD2 Software Development

[Tazzi]

I think its all coded in and sorted. Well, the cable setup and connection setup that is for CAN 11/29bit and VPW.

The headers for CAN or VPW can be setup depending on which protocol you are selecting. If selecting auto, all headers must be filled out before proceeding. On auto, it will tell the elm to choose protocol automatically, it will then search for the protocol, and finally it will then set the correct header depending if it finds VPW or CAN 11/29bit.

If it finds a protocol that is not VPW or CAN, it will say what it found then fail due to a unknown/unsupported protocol found.

As for reading data... it should work on both VPW and CAN protocols right now. It can request data normally, and should get a response back, But I dont expect the responses to come out nicely in the engine section for rpm/temp calc as I havent incorporated the CAN responses for those since i have no idea on what the responses look like yet! Id assume they are the same as the VPW, just a different header which is what the ELM327 datasheet says.

Soo, if anyone could hook up a pcm to this.. that'd be great! First up is checking that the elm device connects up fine, and does all required settings/protocol and headers. If thats all good, next is to try a engine data read.
Also wouldnt bother with the VIN if using CAN, since the message received from CAN is formatted differently to that of VPW for the VIN.. which again.. I havent implemented..But will eventually!

[Tazzi]

Also figured out the whole "BUFFER FULL" issue and how to fix this.
This only occurs when doing ATMA (monitor all) command on a CAN vehicle. This is because there is more traffic over the CAN line coming to the elm quicker then the elm can spit it back out over serial connection. To minimise this problem, bumping the elm Baudrate up to 115200 will help.

But the best way of fixing this is by applying a filter and/or mask to the ELM so that it filters the incoming messages before sending over serial comms. This prevents the buffer full message as its only having to send a fraction of the original amount of traffic back to us. Im still trying to get a better understanding of the filter and mask, but will post up a little explanation once I have it done.

A little dirty hack can also be done if one needs to monitor all traffic, simply sending 'enter' and then ATMA after finding the buffer full message will just renew the chatter monitor process. A few frames might be missed but sure as hell better then continuously rewriting ATMA.

*Edit 1
So the Filter is pretty straight forward, but the mask is a bit confusing..
Header Filter : AT CF 00 00 00 94
Mask Filter : AT CM 00 00 1F FF
Setting the above header filter will only show messages 'from' 94 (source ID) eg. 10 2E 20 94 01 00
Where the green is data bytes, and the red is the other header bytes

Whereas the mask is a bit different, it does a boolean check on the header bits to determine whether to pick it up or not... Just not 100% sure how to apply this effectively, and will source out some well explained examples. Iv found all this easiest by breaking the 29bit header down into its bits.
Where the first 3 bits are the priority byte, next 13 are the Arbitration ID and the final 13 bits are the "sender" bits. This makes it easier to see what module is being addressed exactly, and who is addressing it.

**Edit 2
Cool, I think I get it now.. after staring at 1's and 0's for a while and scrolling through logs.
So the Filter is a quick way of rejecting message based directly on the header bytes. And the mask is a more flexible moderator of what gets rejected and accepted based on the bits.

So using the above example, converting to its bits (10 2E 20 94)
priority|Arbritary|Sender = 1 0 0 | 0 0 0 0 1 0 1 1 1 0 0 0 1 | 0 0 0 0 0 1 0 0 1 0 1 0 0

If I then want to set a Filter of 10 2E 20 00, meaning I want to see messages with 10 2E 20 and dont care about what the "sender" byte. If I then want to further refine my searching, I can set the mask..

Using a mask of 1F FF FF 00, will look like this: (Read = header, Green = Arbitrary, blue = senderID)
1 1 1 | 1 1 1 1 1 1 1 1 1 1 1 1 1 | 1 1 1 1 1 0 0 0 0 0 0 0 0
So what are these 0's and 1's? Any "0"'s mean "I dont care", whereas the 1's mean "The received frame MUST match our mask".
Therefore, the mask is saying the CAN priority must match, the priority and destination must match, but the last 8 bits (SenderID) do not matter.

So in this example, out mask and filter are essentially doing the same thing. Although this can be set up to show things between say: 10 2E 20 17 and 10 2E 20 1F. Which would display info from different modules to the ID "20" from the modules between the values of 17 and 1F

This is what I *THINK* is going on. It kinda makes sense, and follows what Iv found in logs, although this is only an early interpretation and will need to test this out and see if we get messages that correspond to out filter + mask to prevent buffer full problems and look for specific messages.

[Charlescrown]

Hmmm been away for a few days and looks like it's slowly progressing. I tried out a program the other day which is only OBD2 but has a 1/4 mile time program. Works great but in 80km zone and double demerit points ran a 23 second 1/4. Ha

[Tazzi]

Hmmm been away for a few days and looks like it's slowly progressing. I tried out a program the other day which is only OBD2 but has a 1/4 mile time program. Works great but in 80km zone and double demerit points ran a 23 second 1/4. Ha

Slowly but surely.. Have added a while bunch of code.. but have no idea if it works or not, will need to cut back on adding things until it can be tested a bit more and I know all the headers/protocol are being set happily ect. Otherwise I might build on bugs.

A quarter mile timer? haha thats pretty cool, wonder how to implement that.. could search for a trip meter of some sorts maybe.

[Tazzi]

Well Im in need to start tinkering with a bench setup soon. How much should a VZ V6 PCM go for? Same with a VZ V8 PCM?

Fleabay seems to show prices around $300. Bit excessive for something thats not a simple plug and play component without a scantool.

Theres a few vy/vz wrecks on gumtree that im keen to purge. Least that way I might be able to get a wiring harness with it.
Anyone have a rough pricing guide?

[VX L67 Getrag]

VZ V8 PCM's are expensive if your talking E38, I got 1 off ebay US for $100 inc. delivery but anywhere around here if they had them they wanted $300 or so!
For the E55 VZ alloytec I got them from a wrecker for $99 I think & they gave me 30 cm's of wiring connected to the PCM with 1 of them!

[Tazzi]

Nah not too concerned on the V8 PCMs, since they should be VPW like the VY V8's (I think.. lol Getting lost in it all now). And the V6 PCM's will be CAN and should have both 11bit and 29bit connection.

Finding it a bit of a mess that the BCM and PIM communicate over ALDL (scantool wise), but the PCM is on a different comms protocol, yet they all must be linked up to work! Why couldnt they make it simple and keep it all on the same comms! haha.

Will see what some of these wreckers are after and use that as a guide.

[antus]

its a matter of cost. the cheaper more basic devices all talk ALDL and can be swapped between cars. The pcms use the more modern protocols. there are devices that act as a bridge, but I dont know so much about that. I have a suspicion that 'GM Lan' on VEs is can + aldl, but I dont know for sure. The VZ LS1 are the 1mbyte pcms with the green connectors that can drive the electronic throttle and talk VPW. But the VZ 6.0 is the L76 and L98 and talk can. All the VZs still have ALDL for most other on board hardware.

[Tazzi]

Ah ok, from what VL400 has said, the ALDL pcm's are a mess in comparison to the OBD2 pcms in terms of communication and pulling a bin from it from ram. After a bit of reading up on that, looks like the most difficult part is having the right equipment, and writing a bootloader to execute in ram.. hat off to you ant for working that out!
Iv recently finished up reading on the VE's, they use swcan (33.33kb)... so its a bit of a weird rate, but the elm can be mangled into it using the right commands. VE's have both high and low can on both 29 and 11 but comms.. the amount of information that can be read/manipulated and written is just unbelievable. If the VE's predecessors are anything like it, then 29bit comms is more for "status" related stuff, and 11bit is for direct read/write to the modules which I would have thought would be used for software updates/changes ect.

I saw in the Tech2 something about 6.0L when looking at the ABS stuff, but couldnt see anything from the tech2 when clicking it. So the abs must communicate over CAN for the VZ 6.0L as well.

Now been 3weeks, no elm. 3rd time round. Fleabay=Useless. Buying from aliexpress, pick up 2-3 for the price of one here.. and for more $20, can get it sent express!

[delcowizzid]

stuff posted from china is in my hands withen a week anyway.1 time on free postage i had what i wanted in 3 days efficient little buggers them chinese