Let the hacking begin... (Model S parts on the bench)

[markwj]

So, we do not terminate existing buses, do not Write or generate ACK bits,
and only Listen (passively) by using multiple CAN hardware receive buffers.

Aw, where's the fun in that?

But, seriously good advise. Well written.

Another reason to operate in 'listen only' mode, at least until you know what you are doing, is that if you get the communication rate wrong, you can seriously mess the bus up when in active mode.

 

[smac]

Remember when hard drives were advertised with X Mb storage, but due to formatting they could never actual store that capacity. There are precedents for advertising vs real use being disconnected.

I'm not sure that's quite what is happening here. HD manufacturers were at least consistent across their ranges and amongst each other

A better precedent would be cordless power tools.

An old DeWalt 18v Drill had an 18v battery... A new DeWalt 20v Drill has an 18v Battery

Why because people shopping for a new drill naturally assume the 20v packs were better viewing the items side by side on a shelf. Interestingly this method of measuring batteries is not allowed in the EU, so our identical DeWalt battery packs can only be sold as 18v.

18v vs 20v Lithium Ion Power Tools - The Truth Uncovered - YouTube

 

[smac]

That is certainly a conundrum. I'd partially assumed it was the BMS basing it from driven miles vs. rated. The 60 packs may be used / binned or well who knows. I certainly don't think I have anywhere near enough evidence to write a letter to them.

So just as well I didn't send a letter 0x562 != 0562. Battery odo now matches car odo! :redface: (Doh!)

I've double checked the other figures and they still stand.

 

[lolachampcar]

that 0x will get you every time

 

[hnhhzy]

can you upload a tesla firmware package?
and which can MSGID is upload the new firmware bin and notify upgreade? thx..

 

[TheBlackKnight]

Another reason to operate in 'listen only' mode, at least until you know what you are doing, is that if you get the communication rate wrong, you can seriously mess the bus up when in active mode.

That's the best reason, in my opinion. If you are in listen only mode then an incorrect speed setting does nothing to anything else on the bus. Your end just throws a bus error and drops out. Then you change the speed and try again until you find the right one. Otherwise it isn't that dangerous to work in normal mode. Normal CAN is not deterministic at all and so there isn't a lot of harm in adding some extra frames. There is always a bit of uncertainty to the bus at all times. Senders try to send whenever they can and it is inevitable that some collisions will occur on the bus. This holds true whether there is only official traffic or whether you're trying to send some frames as well. There is also the potential that you could ACK a frame that somehow didn't get properly received by the proper node. In that case you told the sender it went through OK but the receiver didn't get it. That would be a rare event and usually OK but it could mess things up in some limited situations. So, the safest option is still to work in listen only mode. But, there are legitimate uses of normal mode - you just should know what you're doing.

I guess my only real point to all of this is to argue with the "likely" point that Gary made. The problems outlined are most certainly not all that likely, just possible. When driving that is probably a good enough reason to use listen mode unless you absolutely have to. I have never had anyone have any trouble with doing captures in a moving vehicle while using normal mode. Maybe I should knock on wood now. I will still admit it isn't as safe as listen only mode. I completely agree that one should use as many buffers/mailboxes as possible on the capture hardware. Frames can come in at upwards of 4000 frames per second (in theory... the tesla never does this) so you could be getting more than one per millisecond. You'd better have a bunch of buffers or a very fast processor or you could miss some. I prefer, for this reason, to use interrupt driven reception on a fast processor so that frames are immediately buffered upon reception. Some processors even support DMA (direct memory access) such that the canbus hardware can write frames into memory itself and thus you have a very high probability of receiving every frame reliably. I'd recommend against a strictly polling approach when the bus load is high. I'm somewhat leery of using external CAN hardware as well. Plenty of people use SPI connected canbus hardware but that adds an extra layer of latency that I really don't want.

 

[Bangor Bob]

So... Who's going to be first to log the bus during a software update? Get all the seed/key pairs for the various modules, etc...

- - - Updated - - -

The only half logical reason I can come up with is we are missing people who can kick Elon in the shins when he opens his mouth still at the point the engineers haven't even worked out if this promise is vaguely deliverable.

Straubel should be the one doing that kicking, no?

 

[faughtz]

Even if you just go by RWD version mileages this should have been evident: 265/200 = 1.33 ... pretty close to 77/59.8 = 1.29. Definitely more realistic than 85/60=1.42. The weight difference between the 60 and 85 kWh packs is something like 200 lbs, definitely not significant enough to account for such a discrepancy in range either.

*shrugs*

<rant>
I don't want to derail my own thread here, but in all honesty (and I just posted this in another thread) I now have zero trust for Tesla. I no longer believe any published spec or advertisement/announcement is truthful. If there was any trust left at all, figuring out the real "85" kWh capacity wiped out whatever was left. When they released the P85D, Tesla used (read: abused) the trust I did have previously to basically swindle me into a pricey trade-up for very little real gain and a promoted feature set that was essentially paid for but unusable until a year later. The way I see it I paid for 691 HP, 285 miles of range, autopilot before summer '15, and an 85 kWh battery. The reality is that I received 463 HP, 247 miles of range, autopilot a year after purchase, and a 77 kWh battery. Sorry Tesla, not falling for your crap ever again. As my own protest I sold off 100% of my rather long TSLA position several months ago (nearly ~3k shares all together). I no longer even own a single share of TSLA because I have no longer have any faith in the company to be honest with customers. That's a surefire way to drive a company into the ground, and I'd have to be an idiot to keep a large investment in such a company.

Now, here's the funny thing. As a 463 HP, 247 miles of range, 77 kWh, AWD EV with autopilot.... it's an amazing damn car. There was absolutely zero need to promote fake specs and lie about the car when the real specs are already the best the market has to offer. It just makes no sense to me whatsoever that Tesla has decided to just promote false and misleading key specifications in order to get more sales in the short term while people slowly work out the truth.
</rant>

Back to hacking...

I have wondered about this for a while. I have never been able to pump more than about 65kwh into my P85D.
Why?
That has not made sense. It's about the data. Thanks wk057.
Here is the end result of my P85D charged from 11% to 100% at a SC, allowing the current to go to zero.

 

[JER]

I'm still scratching my head over this one. The only thought I have right now is what if the thermal losses inside the battery are so large in comparison the drive usage, that adding more batteries significantly increases the total energy used.

If anything, I'd expect the opposite. The 85kWh pack has higher voltage, right? I^2R losses in power transmission should therefore be lower for a given load, given that less current is required for the same power.

.... it's an amazing damn car. There was absolutely zero need to promote fake specs and lie about the car when the real specs are already the best the market has to offer.

You must spread some Reputation around before giving it to wk057 again.

All specifications are aspirational; apply the Musk Correction Factor to predict real results. MCF=(2+RAND)/3 or thereabouts.

 

[AWDtsla]

If anything, I'd expect the opposite. The 85kWh pack has higher voltage, right? I^2R losses in power transmission should therefore be lower for a given load, given that less current is required for the same power.

Real-world driving cycles should mean that you pull more power from a larger pack, because you can. i.e. It would be stupid for a driving cycle in a P90D to have an identical power draw curve to a 70D in the same exact cycle.

 

[garygid]

Someone tried to log CAN messages on a Tesla MS85, using a listen-only setup,
but "accidently" (from the factory) there was a solder jumper on the AVR-CAN board
that allowed the ACK bit to be written to the CAN bus ... and someone's car "barfed"
(did not work properly). Fortunately, when the logging cable was removed, all was
OK, someone discovered the jumper, removed it, and logging-by-listening worked fine.

Hence, my important warning is most likely more than "likely", but perhaps not a certainty.
In any case, I felt that you should be warned. Cheers.

 

[lolachampcar]

and then you have to ask why you would want to ack a message when you were not the one the message was intended for?????? Listen only always unless the message is for you. Sometimes gateways use ack to identify modules live on the bus.

 

[wk057]

I'm working on a little low-horsepower CAN board that I'm going to use to try and control some Tesla hardware on the bench. So far so good, and I can send frames at the same rates that the car does from my little 8-bit MCU and a total of $5 in parts. Definitely not good enough to be a logger, but is capable of picking out messages with hardware filtering.

 

[Andyw2100]

I'm working on a little low-horsepower CAN board that I'm going to use to try and control some Tesla hardware on the bench.

Google translate "wk057 to English" mode translates that to:

"I'm working on a little low-horsepower CAN board that I'm going to use to control my P85D in a few days."

 

[TheBlackKnight]

and then you have to ask why you would want to ack a message when you were not the one the message was intended for?????? Listen only always unless the message is for you. Sometimes gateways use ack to identify modules live on the bus.

Well, any active node has no choice. ACK is part of the message acceptance algorithm. If you receive a frame and accept it then you will set ACK. Listen only mode just disconnects the TX line so that your ACK goes nowhere. Thus, your choices are to be in listen only mode and only receive traffic or be in normal mode and be able to send when you want to and always ACK anything you receive. That is why the EVTV devices are always in normal mode at this point - it's just easier since the hardware and software is meant for transmission as well. I probably really should implement listen only mode for completeness and absolute safety but I have never heard of anyone screwing up a CAN bus by attaching an active node. I have worked with a lot of different electric cars - Model S, Think City, Nissan Leaf, custom cars. Not a one of them ever had a problem with my attaching a listener device that wasn't in listen only mode. A lot of other people have used the same tools on various cars. I've never heard of any issues that can be traced to being in normal mode. Allowing a device to send ACK is only really a problem either if you have the wrong bus speed set or if the bus is in very bad shape. So, I find myself agreeing that listen only mode is the proper way to go for absolute safety. But, I also find the proposed danger to really not exist. In practice I have never once had a single issue with just leaving my tools in normal mode and going about my business. That's easiest for me because I want the ability to inject traffic any time I choose.

Also, consider something else: how many frames do you suppose the center console ACKs? Probably quite a few / most of them. And, the car doesn't wrap itself around a tree. The console is most certainly not in listen only mode but monitors very many messages in order to be able to display the data and configure what is going on. WK has shown that there are debugging screens on the console that can read pretty much any message on the bus. That makes it both an active node and ACK'ing all frames. Things still work because that's exactly how the bus was designed to be able to work.

I couldn't put it past someone to use ACK to identify things on the bus but that would be a very foolish way to do it - for reasons that should be clear from the preceding paragraph. More often things on the bus are enumerated by some higher level protocol like J1939 or CANOpen. This is safer. Anything can ACK any message at any time for any reason. It is a very bad bit to rely upon for much of anything. All it says is that someone, somewhere, thought that they successfully received that message. No more, no less. To really confirm reception one would need a reply frame. This is also why so many frames have counter bits in them. You can't figure out if the opposing end got the frame by ACK because anyone can ACK. But, you can look at the counter and see if it is a dupe or if it has skipped ahead or backward.

Anyway, my arguments are pretty much academic I guess. In practice you won't go wrong if you use tools in listen only mode when you are doing straight captures. Sometimes you need to do a capture while also poking a stick into the beehive to see what happens. Then you can't be in listen only mode but, from my experience, nothing bad will happen due to being in normal mode. Just sharing my experience which seems to be different from some other people's experience. This could come down to hardware. I use the EVTV hardware and Kvaser hardware, not cheap $5 boards or anything like that. If you are using a kazoo and a can of silly string to monitor your canbus then perhaps you should use listen only mode for safety.

 

[markwj]

Agreed: If you can, use listen mode if you're just logging. Less likely to screw things up.

Regarding the technical implementation in the CAN protocol, it is rather neat and deserves explanation. There is no specific ACK frame being transmitted back (for the CAN transfer layer). All that is happening is that while the transmitter is sending a frame, it is also listening for how that frame appears on the bus. If one transmits a 1 and another simultaneously transmits a 0, the result is 0 on the bus. 0 always overrides 1.

In this way, the transmitter can detect collisions, and the neat ID prioritisation scheme works (the lowest ID wins). Think of it as sending a 1, then looking on the bus to see what is there - if it is a 1, all is ok, but if a 0 you know someone else is transmitting at the same time. The ID prioritisation scheme works by the lower priority transmitter sending a 1 as part of the ID being transmitted, but seeing a 0 on the bus, then it knows someone else is transmitting a higher priority ID (the lower the ID, the higher the priority), so it stops transmitting, backs off, and tries again later.

Part of the transmitted frame, near the end, is an 'ack slot' - a bit that the transmitter sets to 1. All receivers who are handling that message are supposed to transmit a 0 there if they got the frame so far ok. The transmitter looks at the bus as it sends the 1 for 'ack slot'. If it sees a zero it means one or more receivers got it ok.

Interestingly, this cannot be used for complete error detection. If two receivers get the frame, but one sees an error, we'll get one setting the 'ack slot' to 0 and the other (who sees the error) leaving it as 1. The result is the transmitter sees a 0 and assumes it went ok.

 

[Whitmarsh]

It strikes me that, given all of a Tesla's many attributes and the ease with which it can be configured, it might be an ideal car for people with physical handicaps of various kinds. For example, someone with a gammy (is that a uniquely British word?) right leg might be able to use the right-hand roller as accelerator and brake - roll to accelerate, press to brake. Or the steering load could be tweaked for someone with weak arms/shoulders, etc, etc, etc. WK057 - in your meanderings through the Tesla's innards, is this something you might keep in mind?

 

[garygid]

Comments on Evaluating CAN logging systems.

When trying to log all the CAN messages, the challenges are greater than when
logging just a hardware-filtered subset of the messages, but the principles are the same.

Gary,
I've been conversing with the developer of this Pi 2 shield:

PiCAN2 CAN-Bus Board for Raspberry Pi 2 [RSP-PICAN2] - £26.90 : SK Pang Electronics, Arduino, Sparkfun, GPS, GSM

Basically we're trying to determine if this board will work in the Model S. From what I gather, CAN3 puts out about 2,000 frames/sec at 500 Kbps. The developer informs me that this is very close to the limit of what this device can process without buffer overflow. He did, however, ask me to get him some solid data from a CAN analyzer so he can tell me for sure. Unfortunately, I do not have such a device, but I suspect that you likely do. Would you be willing to provide precise measurements from an analyzer that I can pass along to the developer?

Thanks,
Eric

I do not have a CAN3 log or a real CAN3 analyzer.
However, maybe the developer can better describe his constraints.

Usually handling 3 or 4 messages with no gaps between them is the first
hurdle. Next is buffering bursts of perhaps 3000 per second, and
then the limitations of getting data written to a file.

I found in writing to a flash device that typical writes could go
quite fast, but occasionally there would be large delays, like 700 ms,
that required a very large buffer.

Then, when there IS a buffer overflow, how is it handled?

I counted the missed messages and inserted a pseudo-CAN
error message into the data stream that contained the number
of missed messages.

Can he inhibit the generation of the Recieve ACK bit, if needed ...
but this might not be important, at least in most cases.

How does he handle termination, and is there provision to
handle single-sided CAN signals?

Find out how he is handling these problems.

Then, he should be able to test by generating messages
on one Pi and receiving on another.

Is he able to capture more than one CAN bus simultaneously?

Does he time stamp each message with second and millisecond
that it was received?

Does he add Date-and-Time pseudo-CAN messages at the start
of each new minute?

Can the log files hold something like 40 million messages,
to allow logging for at least 2, possibly 3 hours?

We think that 2 CAN buses in the Tesla are 500k, two are 125k, and
a hidden one is 33.33k (the Pilot). Is there an easy option
to select the bit rate, or an auto-baud setting?

Cheers, Gary

 

[jpet]

Google translate "wk057 to English" mode translates that to:

"I'm working on a little low-horsepower CAN board that I'm going to use to control my P85D in a few days."

Andy, be careful mentioning the words horsepower and P85D in the same sentence without adding an asterisk somewhere. :biggrin:

 

[apacheguy]

I'm working on a little low-horsepower CAN board that I'm going to use to try and control some Tesla hardware on the bench. So far so good, and I can send frames at the same rates that the car does from my little 8-bit MCU and a total of $5 in parts. Definitely not good enough to be a logger, but is capable of picking out messages with hardware filtering.

May I ask what this will accomplish? I mean is it just for the sake of testing or is there something cool you'd be able to do that you otherwise wouldn't? I guess I'd just worry that this would raise eyebrows in Tesla's engineering dept and possibly force them to implement security on the CAN busses.