Repair techs cannot communicate with onboard computer

[asavage]

When allowing the Toyota dealer to perform warranty work (this repair was covered), I am allowed/furnished/given NO information beyond "we will fix it".

[alflash]

When allowing the Toyota dealer to perform warranty work (this repair was covered), I am allowed/furnished/given NO information beyond "we will fix it".

Is there any official documentary confirmation of this level of secrecy of the results of the work of Toyota technicians when performing warranty work? Or is it a local client bullying initiative?
I assume that this level of secrecy is greater/higher than in the CIA and the FBI.

I assumed that yours RAV4EV HVbattery data could be obtained independently (before and after replacing it).
E.g.

[asavage]

I assumed that yours RAV4EV HVbattery data could be obtained independently (before and after replacing it).

Having access to that information is my primary reason for my desire to have a working Tesla Diagnostic Program setup in my possession: so that I can obtain information such as this, as Toyota will not furnish it "for love nor money".

[alflash]

I assumed that yours RAV4EV HVbattery data could be obtained independently (before and after replacing it).

Having access to that information is my primary reason for my desire to have a working Tesla Diagnostic Program setup in my possession: so that I can obtain information such as this, as Toyota will not furnish it "for love nor money".

To be able to receive all available data of the Tesla system of this vehicle , you just need to buy the cheapest such router (preferably with Wi-Fi) https://mikrotik.com/buy/northamerica/usa
And convincingly double-check / confirm the correct wiring / soldering of yours diagnostic cable.

I sympathize and condole with American RAV4EV users who are forbidden to know such information about their vehicle, e.g.


OFF. It's a pity that not all my questions get answers ... But for me it's almost a habit now

[asavage]

Alternatively, one can "purchase" the Tesla Powertrain Diagnostic software -- cracked -- and set it up in a dedicated OS install, then put together a cable that plugs into the Tesla Gateway box at the LR of the vehicle, and which has a RJ45 connector on the other end, plug that into a Ethernet<->USB adapter.

As I suspected, the Ethernet<->USB adapter is not necessary, if the host computer has its own Ethernet port. The laptop I use for auto diagnostics has a 8P8C/RJ45 LAN port, and I have TPD working with my RAV4 EV using that port, no USB involved.

Notes. When diagnosing RAV4EV, the modem connection status is always yellow. I have never seen green.

When the indicator on the lower left (next to the "Monitoring" checkbox is green, the Modem panel can be refreshed via its "recycle" button at the lower right of its panel, and then (on my vehicle) the modem indicator in TDS turns to green. I assume that when 3G goes away in the US later this year, that will cease to turn green.

NOTE: If all steps have been completed and the status light* on the Tesla Powertrain Diagnostics RAV4 - Service software is still red, this is potentially a local firewall issue.

*
[/quote]

Good guess, Vlad.

With computers, it's hard to be certain, but I think the Windows Firewall was my issue. It's probably one of those non-intuitive things.

I had gotten fed-up with my lack of progress in getting TPD working; it would not communicate with the Gateway, yet a port scanner could find the Gateway's MAC and and IP of 192.168.90.102, so I was convinced the hardware connection was OK. I set that project aside for a month, and came back to it today.

My auto diagnostic laptop boots several OSs, and I keep each setup maintained separately. When I went to boot my TPD OS today, something seemed odd but I couldn't put my finger on what, until I went to check the hardware LAN port's IP address: I then realized that rather that Win 8.1, it had automatically upgraded to W10, and it had done so more than ten days ago, so no easy way to revert. Damn!

Well, poking and prodding, eventually TPD did give me a green "light" at the lower left, but but some fields were unpopulated, and when attempting to DO something, I'd see a popup warning about being unable to load data, even with a green light, and I'd never seen the VIN field populated.



But, Hey! That green light had never happened here before, so I was counting that as progress.

Eventually, I re-checked the Windows Firewall, and found that TPD was set to allow data for Private networks (eg, my built-in Ethernet port) but not Public networks (eg the laptop's Wi-Fi). Which seemed correct to me, but I do not trust my guesses when it comes to UIs, so I added "Public" networks as a firewall exception, and TPD now works. In fact, I turned off "Private" networks access, and it's still working.

I've no idea why, but my un-egged beer is more than satisfactory

I tried various firewall options, and landed on this:




I note that TPD takes a while to get to the diagnostic panels screen, maybe 10-15 seconds, and that -- annoyingly -- the program does not provide feedback that a further 10 seconds is needed to begin to communicate with the Gateway. Gawd, I hate UIs that do not provide a live throbber or equivalent, to let you know that something is happening and to wait.

You may need to uncheck and check the checkbox in the lower left of the screen next to 'Monitoring' to establish communications. The red status light should turn green, and the box next to 'Monitoring' should be populated with the vehicle VIN.

So far (sample size: 6 runs) I haven't had to touch the Monitoring checkbox; every time, given a sufficient startup time, it's turned green.

[alflash]

asavage, Some empty spaces in the parameter blocks are due to the fact that some Tesla ECMs are not active at the moment.
For example, in IGN ON mode Inverter is not active. But, if you switch to Ready mode, then its parameters will be available and all data (ID) of the data package/panel "Hardware Configurarion."
Take a look and check it out for yourself

[asavage]

I noticed the behaviour you mentioned, specifically the DC-DC Converter panel being unpopulated until the car is in "Ready" state. Thanks

[ddoxey]

I have been quietly working on this topic (and lurking) for awhile. But I've reached an impasse.
But I'll share some of the milestones of my journey.

I got started by using this snippet of wisdom.


To convince myself that was right, I scoped the CAN_H (RXP) and CAN_L (RXM) lines.


Using this information, I was able to connect to my RaspberryPI / Pican2 setup and collect CAN data.


I took the CAN data collected on Pican2 and I was able to load it into Savvy CAN and make some really neat pictures.


I read a lot of activity on the Tesla owner forums about using this type of analysis to reverse engineer identifying the CAN signals by simply eyeballing the correlations between signal behavior and indications in the car.

But that's not working for me. I want to know which of these CAN signals are related to faults that result in the P312F code on the Toyota side. It's pretty evident that there's no getting around the need for the Tesla Powertrain Diagnostics program.

I see that the word on the street here is that the ODBII to RJ45 adapter can just be plugged into the computer's Ethernet port, either directly, or via an Ethernet to USB adapter. (Admittedly, I doubted this made any sense because CAN is a voltage differential signaling standard, and surely Ethernet is something else. However, after doing a little homework, I see that Ethernet is also a voltage differential signaling standard.)

Further reading on the Tesla Diagnostic Program configuration guidelines validates this.



Here's the thing. When I plug the RJ45 into the Ethernet adapter on my PC, the CAN traffic falls flat (as seen by the candump running my Pican2). I checked the continuity on the CAT5 twisted pairs while is was plugged into the Ethernet adapter. Each twisted pair is shorted, with zero resistance indicated. That just seems wrong.

There's also one more thing. When I attempt to configure the Network Configuration, I get nada.


Neither of my two Ethernet network adapters appear on the Network Configuration list (which I am running as Administrator).

This is where I'm stalling out.

My current thoughts:
* If the Ethernet adapter is configured differently:
** Perhaps the CAT5 twisted pairs will not be shorted out
** Perhaps TPD will recognize the Network adapters
* Perhaps there is a Windows firewall configuration blocking progress.

[asavage]

I know the Tesla DLC connector has ethernet, for use with Tesla Powertrain Diagnostics. I can't recall if the DLC connector also has CAN.

However, the other (grey) connector on the Gateway has both.

I'm sure I read your post too fast, but to confirm: you are using ethernet connections for ethernet things, and CAN connections (on different pinouts) for CAN things, correct? Each requires four wires, but different four wires.

See the pinout/wiring at:
https://www.myrav4ev.com/forum/viewtopi ... 823#p29823

[alflash]

I have been quietly working on this topic (and lurking) for awhile. But I've reached an impasse.
But I'll share some of the milestones of my journey.
...

The pin assignment of the connector that Toyota calls DLC3 No.2 is shown 5 years ago at https://www.myrav4ev.com/forum/viewtopi ... 269#p26269