CANBUS PIDs

Correct. Further example values from my notes are: 0x0400=144.3 F, 0x0300=98.2 F, 0x200=52.2 F, 0x0100=6.1 F, 0x0000=-40.0 F. Sample values for the single byte MG1/MG2 temps are: 0x00=-58 F, 0x4C= 79 F, 0x51= 88 F, 0xFF= 401 F.

I have a little progress to report on the KWP bus data. I can monitor the Mongoose traffic with a Scantool.net ELM327 attached to the K line and set to 9600 baud with an ATIB96 command. I can't use the ELM to initiate a query as the bus init fails. The Gen2 OBDII connector also has TS & TC signals (Gen1 holdover?). And then there's the black wire connected to pin 8, and the yellow wire connected to pin 11. Neither are documented. No connection to the L line.

 

Response time? Re: CANBUS PIDs

I found it takes only ~0.05 second to get a reply from 7e2, even for the long multi frame messages, but it takes much longer 0.2 ~ 0.4 second to get a reply from 7e0 even though the reply is just a single line. Is this the way it is or is there something I could do to improve the response speed? Thanks!

 

I check on same log to see the delai between sending a request and the response.
Between this request and response my Tactrix Open port 2 receive passives frames.
Here is the number of passive received:

minimum 1 frame
maximum 36 frames
average 7 frames

In one second you recevive about 1600 passives frames.

Then average response to a sollicited pid is 7*1000/1600 = 5 ms
Same average delay for a call to 7E0, 7E2 and 7E3


I think you are using some Elm327 and Ftdi driver (virtual driver).
Ftdi driver send response to you program in two situations:
-his buffer is full (his buffer size is 4k) Or
-timeout.

May be this is why you have a huge delai.

 

Re: Response time? Re: CANBUS PIDs

Interesting observations. All I can offer is a few guesses. The first is that 7e2 is simply a faster device than 7e0. Or perhaps 7e0 has a higher workload, and the query is lower priority than its other work.

The values available from 7e0 are all relatively stable ones. The catalyst isn't going to change temperature much between sub-second queries. So maybe you should only query the slow device every few seconds. The RPM and torque values change more quickly.

Most CAN interfaces make it easy to issue a query and limit the replies to just the queried device. You could get better overall performance if you issued multiple queries, and sorted out the replies from a less filtered view of the CAN traffic. You could continue to process messages from a fast device even while a query is outstanding to a slower device.

The best performance is going to be from the use of passive messages. The Vass spreadsheet describes some of them, but I suspect that there are many more that we simply haven't identified. If the passive data is in exactly the same format as it is in queried messages, then it should be possible to match them up.

 

Very good observation. I hadn't thought about the FTDI as such a delay source. I wonder if you could program an ELM to handle multiple outstanding queries and do your own filtering of the replies. Or maybe just reduce the timeout value from whatever the default is.

 

Re: Response time? Re: CANBUS PIDs

planetaire and RobH, Thank you both for the quick reply!

How exactly does it receive passive frames in between request and response? I wonder if I could achieve the same by sending ELM327 commands like this:
ATCAF1
ATSH7E0
2133
ATCAF0
ATAR
ATMA

Wow that's like 10 times faster than the response I see: ~ 50 ms. I wish I had started with a Tactrix Open port 2.

Yes that's exactly what I am using. Which timeout were you referring to? The serial port timeout is programmable from 0 up in 100 ms steps. I tried 100 ms and 200 ms timeout and in both cases the delay of response from 7e2 is ~ 50 ms. So the serial port timeout doesn't seem to play a role here. Maybe there is another timeout I don't know about?

As mentioned above I need to learn how to do this with the ELM327 device. Do you have an example command sequence to share? Currently if I send requests too quickly then I can't even read back the echo and sometimes I get "STOPPED" message. For example the 7e0 is not always happy with 100 ms timeout, but OK with 200 ms timeout.

Yes my strategy is to read the passive messages and only send requests every few seconds.

Some more puzzling findings: I looked back the log and found if I selected 7e2, do some requests, then 7e0, then some more requests, then all replies happily came back in ~ 50 ms. But if I started by selecting 7e0, then do some requests, then the response time grew to more than 100 ms and became unreliable if timeout was set to 100 ms.

 

Re: Response time? Re: CANBUS PIDs

2009Prius.

Timeout and ftdi buffer size are explained in this pdf. (Frenchie find this last year)

CanUsb and Tactrix are able to send request and continue listening. Elm327 don't. It is impossible, it is explained in Elm327 doc :

But remember : I have nearly the same average delay for a call to 7E0, 7E2 and 7E3: average between 6 and 8 ms.

Tactrix use "direct pass thru" programming. I think it is why he is so quick and a little more difficult to program...

:wave:

 

Re: Response time? Re: CANBUS PIDs

Thank you for the quick reply again! Now I am seriously considering getting the Tactrix. Is there a PDF datasheet for it (similar to that for the ELM327) or do I need to look through the linked pages you sent above (Introduction to PassThru (J2534) Programming) to learn to program it? I assume C/C++ can do?

 

Before buying Tactrix, you can see full samples writen in vb6 from drewtech. You can also use C.

Before programming you have to get the J 2534 protocol (2004 or later) in order to send the good parameters.

 

Thank you! Is Drewtech related to Tactrix? In other words does the Drewtech API/DLL work with Tactrix Openport 2.0?

 

Warning on the Tactrix, I have one and it works great for TechStream over CAN, but has a timing error (we think) on the KWP bus, so it cannot reliably do everything. Also, the Micro SD logging function seems to be useless for Toyota.

 

Thank you! Do you think or have you asked the manufacturer whether the timing and logging problem can be fixed by firmware update or need hardware fix? Thanks!

 

No, I haven't contacted them. Feel free to if you like though! (not enough time for such things right now)

 

During run time you need op20pt32.dll
But i don't remember if the op20pt32.dll is in this drewtech package.

Thank you pEEf.
But Sd card is not used when you connect a Pc via the Usb.
I only use tactrix on CAN bus with a Pc and have no problem talking with ecu 0,2,3 and receiving passives pid.

Robh explain also here KWP usage:
Options are limited on Prius 2 ?
Don't program keys.
Here in france we haven't tpms

What else about kWP Bus ?

 

Drewtech is related to Tactrix about like Toyota is related to VW...

The Techstream software interfaces to vehicles via the J2534 driver interface standard. Drewtech makes the Mongoose hardware and a software driver written to the J2534 interface standard. Drewtech clearly works with Toyota to make sure that their hardware/software package is compatible with Toyota vehicles.

Tactrix also provides vehicle interface hardware and software that uses the J2534 interface standard. But there is a problem in their implementation of the KWP interface. Actually, Toyota describes their protocol as Bean, not as KWP. But if you read enough of the KWP standard, what Toyota does appears to be within the optional choices of KWP. Just not the options that most other vendors support. Toyota chose to operate the bus at 9.6 Kb, instead of the more common 10.4 Kb. There may also be differences in the Toyota implementation of the KWP fast init protocol.

I don't see any technical reason that the Tactrix device couldn't be made to work with the Bean (KWP) devices on the Prius. But the current observation is that it doesn't.

 

Re: Response time? Re: CANBUS PIDs

Actually, I was thinking more along the lines of

ATAT0
ATCAF1
ATCF7E0
ATCM7F0
ATH1

Using ATMA is going to overflow the ELM-FTDI interface at the default data rate of 38.4 Kb. You can probably set that datarate to 500 Kb, but even that probably will overflow. Scantool.net has an ELM compatible device (the $100 one, not the $60 one) that claims to work up to 1000 Kb.

The $30 ELM clones are so cheap that it might make sense to use multiple devices. Run one in monitor only mode (ATCF/ATCM), and another for sending queries.

 

Re: Response time? Re: CANBUS PIDs

I am running 2Mb baud so continuous ATMA is no problem. The problem is that not all data of interest have been found in the passive messages yet. For example the inverter and MG data that you generously shared earlier. With the ELM device then I need to periodically stop ATMA, do the request, wait for reply, then start ATMA again. The request/reply creates a gap of a few tenths of a second - long enough to be noticeable on my "realtime" gauges. This gap probably won't affect the usability but is kind of an eyesore. That's why I was wondering about the possibility of not waiting for reply and going straight back to ATMA after sending a request. I did some quick test last night and had limited success. Doing this for a single line reply may have some chance of working: the complete line would come back before the dreaded "STOPPED" message. However subsequent commands occasionally got lost.

I thought of having another ELM doing the request also but I am already using ScanGauge with the ELM with a Y cable. Even if I could stick in another Y cable the whole thing would be so ugly.

I may end up abandoning the ELM and go with Tactrix. The only unknown is how difficult it is to program that, especially the part that it sends request but still reading back all the passive messages (equivalent to ATMA I suppose). Does that mean it's some kind of multi-thread programming - one thread does the request and the other does the continuous read?

 

Re: Response time? Re: CANBUS PIDs

It can be more easy:
-initialisations (500kbps, 11bits ...) (Open, Connect, Startmsgfilter)
-a loop in wich you send sometime a request (Writemsgs) and other time check (Readmsgs) if there is some pid received, sollicitated and passive.
Of course il you use sollicitated and if they are multi frame, you have to ask for the folowing frames after the first response.
-close (Disconnect, Close)

No need to use multi-thread. Write and Read are quickly executed and concern one pid at a time.
With elm you receive a buffer with 4k at a time.

 

Re: Response time? Re: CANBUS PIDs

Thanks again for the quick reply! So if I understand it correctly, it is still sequential, not parallel, programming. The loop would be something like

That's a big relief. And the advantage of Tactrix over ELM is that after writing a request it can immediately continue to read all traffic on the CAN bus, no need to wait for and finish reading the reply. For example the sequence of event in the loop may be

Do I understand this correctly?

 

Re: Response time? Re: CANBUS PIDs

Yes but you have to change a little for multi-frame message.

1) Send 7Ex yy zz....
2) receive one or more passive pid
3) receive one reply to 1) : 7E(x+8) 10 xx zz ... (Hexa notation)
4) send 7E(x+8) 30 00 00 00...
5) receive some passive
6) receive reply frame(s) from sollicitated 1) : 7E(x+8) xx yy ....

7) receive passives.
8) Enjoy driving a Prius

There is an other programing technique for multi-frame messages.
1) Initialisation iso 15765 (More complex)
2) multi-frame are received in one call to PassThruReadMsgs

That's all