CANBUS PIDs

Re: Response time? Re: CANBUS PIDs

Thank you for the very helpful info! Another question about the Openport 2.0: does it go to sleep (turn off power consumption) after the USB is disconnected by either unplugging the cable or using the "Safely Remove Hardware" applet in the system tray so I can leave it connected to the car without worrying about draining the 12 V battery?

 

Re: Response time? Re: CANBUS PIDs

I just unplug usb side and odb2 side. Unplug usb side is not necessary. I do this because the usb plugs (one for tactrix and one for gps) hold the pc on is support !

I think it does not go to sleep because on odb side 12v is permanent.
But i don't try waiting a long time to see if it will sleep. Probably i will sleep before it.-_-

 

Yes we can!

For anyone out there who is following the conversation between planetaire and me I got great news to report: there is a way to program the ELM327 to send out a request and then immediately go to listening for all traffic. So it works essentially the same as the Tactrix Openport 2.0 as described by planetaire earlier.

The only drawback is the FTDI latency timer of 16 ms is still there, but only when I need to change the header to talk to a different ECU, otherwise the delay is less than 1 ms (I am just using the timer on my laptop that only has 1 ms resolution). There is an instruction in the FTDI document on how to lower the 16 ms latency down to 1 ms but after many trials I found the hardware just doesn't always do what the Device Manager or Windows Registry ask it to do. Most times it insists on 16 ms delay and occasionally it decides to follow order and gives 3 ~ 4 ms delay. Any suggestion on how to tame this FTDI beast will be greatly appreciated.

Even with the 16 ms latency I am very happy with the performance. A gap of 16 ms is not detectable by my eyes staring at the constantly fluctuating HV current reading - before, when the gap was more than 100 ms, I could definitely notice the brief pause. In a test drive today I sent out a request every 1/4 second and everything worked well.

A big thanks to planetaire again who has helped tremendously on this adventure. Now I can see light from the end of the tunnel.

 

Re: Yes we can!

Great information. I observed this latency issue, it's nice to see that it may be possible to fix it even with a low-cost off-the-shelf solution.

I gave up on the PC-based stuff for general monitoring, but my current project is still playing with the same data on the same bus, and we need good logging to learn more! I have a CANUSB, a Tactrix OP2, and now a Chinese knockoff of the Mongoose. None are as useful as my home-built gadgets though, mainly because I like to be able to monitor more than one "side" of a CAN conversation from any point on the bus.

 

Just started looking at the MG RPM and got a max of 33287 for MG1 RPM! Any idea what went wrong? Maybe some higher bits are not meant for the RPM?

 

There is a bias of 16383 for MG1/MG2 rpm. Still sounds high, but I really haven't looked much at real data.

I've attached a log of an 11 minute trip including hard acceleration onto a freeway. The max MG1 in the log looks like about 10,000 rpm. The data is the 61 C3 messages from 7EA, with MG2/MG1 data delimited with extra spaces. According to my notes where I used forced data, a value of 0xFFFF causes Techstream to display as 49152 RPM.

 

Another strange thing is that the two inverter temps both would not go below 15 ~ 16C even when the outside temp was 0C and the car just started.

 

The MG1 Temp, MG2 Temp, Motor Temp 2, & Motor Temp 1 values seem reasonable in the data file that I just posted. The sample values I recorded are 0x00=-58 F, 0x4C=79 F, 0x51=88 F, & 0xFF=401 F.

The "HV Battery Voltage" item following the temperatures (B34) makes better sense doubled rather than halved.

 

Thanks for helping! I looked in your posted data and the temps of the two inverters also does not go below 16C. In the beginning of the record the MGs are at 12~13C and the inverters 16~17C. If the data was collected from a cold start of the car then it may be showing the same problem I am having: for example yesterday after work (car parked outside all day) the OAT was 0C, the MGs were at 1~2C (reasonable), but the inverters were both at 16C! Still baffled.

PS. when I did the measurement the car was just turned IG-ON, not READY, so nothing in the inverter should have generated a lot of heat in a short time.

 

I'm working on a similar project using the MCP2551 transceiver and an mbed processor (mbed.org). I've collected lots of data (passive) from my 2010 Prius, but none of the codes seem to match the previous generation. I can verify that the CAN baud rate is 500k bps. Soon I will be trying to transmit on the CAN bus to request other data. I'll let you know how it went.

 

Hi all!

Thanks for all the info.

I'm using the Arduino shield developed by DarrenG to build a HSI bar for GEN2.

I can read all the passive data frames and will try to get the on-demand extended codes.

You can see my HSI bar working by going to youtube and searching for "Desenvolvimento de uma barra HSI para o Prius 2G - 2" - sorry it's in portuguese.

Regards

 

Yes, I'll post it later on the HSI for Gen II with Arduino and CAN-BUS Shield thread.
The code still needs some tweaking and debugging...

Regards
Alex

 

Any advance on the KWP front using ELM? Thanks!

 

The problem appears to be the initialization sequence sent by the ELM. While the hardware appears compatible, I haven't found any way to invoke the proper sequence with ELM commands. So the only game in town is the J2534 interface, such as the Mongoose. And the Drewtech Mongoose and Denso devices are the only ones that work.

 

Someone has success with their Vitz that is also on KWP 9600 on Torque Forum. Perhaps you can try if it works on Gen2?

Vincent

 

Vincent you are the man! Your link hinted on custom-setting the ECU address. Then from the Berkeley document we easily figured out the skid control ECU is at address 29. So after setting the address to 29 we got successful BUS INIT! Here is the log:

Then a sweep of queries were issued to see what came back:

We got pretty much the same info as in the Berkeley document except the undocumented 2123. There didn't seem to be any standard stuff though:

Eventually we would like to read the DTCs. Could the response to 2123 be it?
Update: Berkeley document has it - we just didn't notice before. It's 21E1.

This was all done with an OBDLink device. It will be interesting to see if other ELM compatible devices work the same.

Apparently the scary, special "non-standard" signal for hardware handshake (as described in the Berkeley document) is not needed, i.e. no need for special cable/device.

 

I believe 21E1 only gives you the no. of DTC and not the DTC itself. Instead of sending 03, which is only for emission-related DTC, you can try to send 13. You may need to change header first.

Vincent

 

Just did a quick try:

I suppose if there is DTC logged then the count won't be "00" and the code won't be "00 00"? Also would the clear code command be "14"? (To test further I may disconnect some connectors to cause DTCs. But before doing that I would like to know how to clear the codes.)

Also I vaguely remember the TPMS is on the KWP bus? It would be interesting if the tire pressures can be read off the OBD port.

 

That is correct.

TPMS is on the KWP bus as posted by RobH and his decoded TPMS msg.

Vincent