Hi everyone, today check lights came on for active suspension, brakes and engine. I lost regen braking but normal brakes worked fine. I switched the engine on and off and the lights cleared and regen brakes worked again. When I checked the codes with Scangauge it said 27 pending codes but only gave me P0001 (Fuel Volume) , B2600, and B2501. I have checked the web and all the Prius DTC lists I could find and cannot find the B2600 and B2501 codes anywhere. Does anyone have any ideas?
According to a list that I looked at, B2xxx codes are Body Manufacturer Specific. Sorry can't seem to attach the file but that is the explanation given.
I experienced the similar occasional regen braking failure when I had the chinese ELM OBD-II adapter attached. The start/stop sequence fixed the warning, I didn't find any significant (brake related) DTC code logged. Just a general CAN communication DTC error and related freeze frame data without any malfunction signs. When I replaced the OBD adapter to more advanced one, this hickup disappeared.
Seriously? Is there really documented history of OBDII adapters interfering with the functionality of a vehicle? It seems like a bit of a stretch? I thought OBDII was pretty much read-only and can't affect the car's settings?
Yes, seriously. The ELM BT communication with Torque stopped after the car in Ready. Only fail-safe braking, e.g. without regen and power braking, available. I used this blue-box from DealExtreme. After the replacement to more advanced one I never seen the related DTC code. The TechStream datafile is attached - the error code was U0073(Control module communication). The TSE file has to be renamed from .zip to .TSE file extension.
Thanks guys for your replies. I have an OBDII splitter in place, running Scangauge and Ultra Gauge. After reading PaJa's repy I'm suspicious that it may have been caused by my accidentally knocking the OBD II connector while vacuuming the car. I remember there was some funny behaviour on the dash display at the time but I thought nothing of it. Going to the local dealer in the morning and will let you know what's said.
It seems the Scangauge and UltraGauge running in tandem caused a brief coms failure and this resulted in the loss of regen braking. I have yet to test whether it is the splitter or either of the gauges causing the problem. It is odd that this should happen after nearly 80,000 kms of these gauges running in tandem.
It seems insane that a read-only data port, even if it's short-circuited could create vehicle malfunctions. I'm sure Toyota and OBDII device makers would be very alarmed by the liability implications of this problem, especially because it's related to the failure of a braking system. I mean they're required by law to have these data ports and the whole design of these ports is to give you and your mechanic data but not allow you to control/affect systems other than clearing codes. Hopefully some experts will join in on this thread to clarify what's going on here? Some important knowledge is missing from this discussion!
Yes I agree. I think I'll ring Toyota on Monday. My dealership is really good but they tend to be a little "rural" in their attitudes.
The ODB-II (DLC3 in Toyota's terms) is NOT read-only connection, especially for CAN bus usage. The CAN bus OBDII pins 6,14 hang directly on the bus signal CANH, CANL without any separation. The connector is designed just for the service purposes. If we use it for the rutine on-line data collection, we have to know its limits. When the OBD adapter is badly designed or programmed it can generate some CAN bus glitches. It is good to know, that chinese adapters are not based on original ELM327, but they often use cloned universal PICs. Their interface circuits design is also a big question. My current adapter works well w/o any problems, so I'm quite sure the DTC trouble was the China box related.
That makes sense. I have so far tested Scangauge, directly connected, UltraGauge, directly connected, and Ultra Gauge through the splitter. So far no problems. I'll test Scangauge through the splitter tomorrow and then both gauges together again. I rang Toyota Australia and am waiting for an engineer to call me back.
I can confirm that an OBDII adapter can interfere with CAN bus activity. I am using an app named "Torque" on an Android device, connecting via Bluetooth to a ScanTool MX Bluetooth adapter. If Torque is left to it's default to "Thorough protocol scan" for the type of connectivity supported by the vehicle, and the Prius power button is pressed while it is trying to do this, the ODBII tool/software ties up the bus and prevents some of the systems from communicating long enough that some systems do not work until a power recycle. This happened twice until I manually selected the communications mode for the OBDII to talk to the Prius. It caused the ABS/Stability/etc. lights to come on. The bus is a shared bus, and it is NOT read only. Remember that you can use these tools to change seatbelt beeping, backup beeping, etc. Also, Toyota can do all sorts of changes with their TechStream tool.
Sorry - I wasn't near my Android device when I made the post above. The term used in Torque is "Thorough protocol scan". I corrected my post above. Open Torque and if you have it set to go to the dashboard automatically, back out to the main Torque screen where you see a single dial gauge with choices around it. Tap the Settings icon at the bottom left of the screen. Select Vehicle Profile. Select Edit. Scroll down to "Preferred OBD2 Protocal". The default is for Torque to use "Automatic - Thorough protocol scan" each time it connects to the OBDII/car. It does a probe of the long list of protocols you see there. If this occurs while the car is powering on, the CAN bus either becomes confused or saturated & some systems can't communicate for their initial power up. This is what was happening to me. For both our 2008 & 2012 Prius, it will eventually select "ISO 15765-4 CAN (11bit 500k baud)". This is after doing the "Automatic - Thorough protocol scan" each time the application connects to the OBDII/car. To avoid the problem, I manually selected "ISO 15765-4 CAN (11bit 500k baud)" for both vehicle protocols. I haven't seen an issue since.
