The Lotus Cars Community banner

1 - 20 of 73 Posts

·
Registered
Joined
·
1,122 Posts
Discussion Starter #1
ok here are the results of my reverse engineering of the CAN network on the elise. so far this only covers the data broadcast portion; i.e. while i have made significant progress in learning the protocols/encryption that lotus is using to perform obd, reflashes, and data dumps, i cannot talk about any of the work until i have discussed the implications with my firm's lawyers. more on that later. whay i can discuss is the the rest of it, which is technically non-proprietary though it does follow non specific formats. here is what i have found:


The lotus network uses a CAN based network for three conection points in the elise. these points are the ECU, the instrument cluster, and the OBD connector. CAN uses a twisted pair cabling with arbitration, which means that it still functions under a variety of conditions including either signal wire being severed or shorted to ground or 12 volts. it also uses differential signaling; both wires normally rest at 2.5 volts and a data bit is signalled by 3.5 volts on the CANH wire and 1.5 volts on the CANL wire. the advantage of this is that the differential between the two wires constitutes signal and any induced noise will either raise or lower both lines by the same amount, thus not changeing the differential.

the network follows the standard CAN 2.0 spec for the physical layer; it uses 120 ohm impedance twisted pair cabling with each line having a 60 ohm impedance in relation to gnd. the network uses standard TJA1054 CAN transcievers (texas instruments) or 82C251 (phillips). both are very common parts availabl through digikey. the wiring is as follows:

Code:
sig	ECU	cluster	obd	wire color
--------------------------------------------
can H	85	C1	6	red
can L	79	C7	14	violet
gnd	--	A2	5,4	blk
the CAN spec specifies that a number of different bitrates can be used, with 250 and 500kbs being the most popular for C level or engine management networks. the elise actually goes one better and runs the network at 1000 kb/s or 1 mb/s which is actually very fast but does make the network more susceptable to noise issues; at 1MB, any loose connection in the signal wires causes data corruption. CAN specifies that data is transfered in frames; each frame has an ID#, a length descriptor and 1 to 8 bytes of data (sometimes a return request flag too). the ID number designates the type of information sent and sometimes also the sending node though multiple nodes can send messages with identical id's, it is not recommended. the arbitration mechansim is such that lower ID#'s are given priority over higher ones so that if two messages are transmitted at the same time, the node that is sending the higher ID# will back off and allow the lower one to transmit. (for more info on how this happens google the CAN spec and start reading) this allows for message prioritization, and consequently important messages (say like "switch on the high cam NOW!") are given low ID#'s to insure that they transmit as quickly as possible.

the elise regularly transmits only one frame/message ID# and that is 400h (hex). The message is transmitted and thus updated 10 times a second (allowing a resolution of 10 hz). the frame is 8 bytes and so far it looks as though 2 bytes are unused. the frame carries the following data: rpm, speed, temperature, MIL, and fuel. the frame layout and approximate conversions are as follows:

Code:
lotus elise ecu-->cluster broadcast frame


400h	8	AA BB CC DD EE FF GG HH

		AA -----------------------> adjusted speed ~= d(XXh)-11d (61h-->97-11=86 mph)

		   BB --------------------> unused (always 00)

		      CC DD --------------> tach rpms [d(CCh)*256]+d(DDh) 06 D2 = 1746 rpm

			    EE -----------> fuel level (00=empty, FF=full)

			       FF --------> engine temperature ~= d(XXh)-14d (D0-->208-14=194F)

				  GG -----> MIL 06-on, 04-crank, 00-running, 01-shift light

				     HH --> unused (always 00)
the speed and temperature conversions are only approximate; they need to be calibrated against controlled readings. the fuel sender reading needs to be averaged over time as the value fluctuates in relation to the fuel sloshing around and moving the float. the MIL data may correspond to more than what i have listed; i have not had a chance to check bits 3-7.


the uses for this data so far are pretty obvious: it is a solution to the aforementioned speed sensor wire connection that is needed for the speed controlled volume and navigation dead reckoning. microchip inc. sells a microcontroller, 18F248 with a built in CAN controller for around $6 and the CAN transciever (MCP2515) for $2. add crystal and regulator and you have a working unit for ten bucks. the 18F248 also has a bulit in UART, which means that with the addition of one more chip, an RS232 transciever (max232) for another $5 and you have a speed pulse generator and CAN-to-RS232 convertor.

There are also plenty of commercially available convertors on the market now, with prices ranging from $150-$300. if you do not mind doing a bit of programming, you can easily roll your own racetrack datalogger using an adapter, gps card, and a laptop at a fraction of the price of what the racelogic units cost. In fact, i did just this using a custom logging program that wrote for another project (see pics below). custom display/gauges are another application; how about a digital gauge that shows your position on the track, logs lap times, G forces, and calculates recommended entry speeds for turns all in real time and nowhere near the $6K cost of the ones that i have seen. for the truly crazy, this provides the input data that forms the basis of an e-shift system.

practically, i can see two applications that are well suited for this: first, for all of you valentine one owners, how about getting rid of that ugly display once and for all and having the V1 blink the shift light for warning and display the directional indicator by momentarily taking over the temperature or fuel display. that is on the way.

the second app is a trackday datalogger that is self-contained; it would be a box about the size of a pack of cigarettes with an obd plug molded into one end and a gps antenna plug on the other. inside it has 1 megabyte of memory which would be enough to log all of the transmitted data plus gps position at .1 second intervals continuously for up to 3 hours. you simply plug the into the obd connector and set the antenna on the dash/roof. after the race, you download the data to a laptop via USB and do all sorts of cool and interesting things. pricing on something like this would again be pretty inexpensive: under $100 if you build it yourself and $200-$300 for a commercially built unit assembled and ready to go...
 

·
Registered
Joined
·
1,122 Posts
Discussion Starter #2
logger pics

here are some pics of the logger software that i wrote; i also have a version that will be ready to go soon that will actually display some nice gauges plus grab position input from a serial gps unit. i am considering making the software freely available to elisetalkers with the explicit understanding that its only for members of this site and that it remains private software. the reason for this is that some of the techniques and code components used are an offshoot of proprietary software that was written for a client and they cannot be GPL'd or even really discussed publicly. consequently, this is why i cannot even talk about the elise ECU firmware CAN bootloader/encryption... reversing it involved custom software that i wrote that must remain proprietary and our lawyers dont even want me discussing it. (plus companies tend to get quite irritated with RE issues even though it is legal, particularly if it happens too quickly or easily)

one thing to note; the software currently is only compatible with the PEAK usb-can adapters, other adapters will likely require some recoding; a generic serial adapter is probably best if there is alot of interest; we could start a roll-your-own community project and build them pretty inexpensively...
 

Attachments

·
Registered
Joined
·
764 Posts
And The Crowd Goes Wild!

Good work, Rob!

I am humbled by the amount of great stuff the fine people on this board contribute. Way cool stuff indeed.
 

·
Registered
Joined
·
8,270 Posts
Ok, I feel left out. Should I be disturbed that I have no idea what you're talking about? :)
 

·
Registered
Joined
·
2,464 Posts
babak said:
Ok, I feel left out. Should I be disturbed that I have no idea what you're talking about? :)
Computer stuff, we count in base 16 (Hex data) instead of 10 based.
We programmers denote h for hex data and d or nothing for decimal.

so 30h is a hex number that is 3x16 = 48d

0 to 9 = 0 to 9
10 to 15 = A to F

so Ah = 10d, Dh = 13d, 10h = 16d,

---------------
More indepth

Decimal.

a decimal number that has several digits can be expressed as follows

375 = 3*10^2 + 7*10^1 + 5*10^0 = 300 + 70 + 5

Any number to the power of 0 = 1.

hexadecimal follows the same math as well

A3F = 10*16^2 + 3*16^1 + 15*16^0 = 10*256 + 3*16 + 15*1 = 2560 + 48 + 15 = 2623
where A = 10, F = 15

binary is the same as well, only the base changes

1011 = 1*2^3 + 0*2^2 + 1*2^1 + 1*2^0 = 1*8 + 0 + 1*2 + 1*1 = 11

we also use octal but that's pretty much obsolete with digits between 0-7.

it's very easy to work with binary to hex or octal translation because they are all powers of 2 (2, 4, 8, 16), but computers have a lot of trouble representing base 10 stuff because it's not a power of 2.

Anyway, the same math that applies to decimal can be used in any other base.

for fractions for example you use negative exponents where x^-y = 1/(x^y)

so in decimal 0.25 = 2*10^-1 + 5*10^-2 = 2*1/(10^1) + 5*1/(10^2) = 2*1/10 + 5*1/100 = 2/10 + 5/100 = 0.2 + 0.05 = 0.25
in binary it will be 0.01 = 0*2^-1 + 1*2^-2 = 0*1/(2^1) + 1*1/(2^2) = 0*1/2 + 1*1/4 = 1/4 = 0.25

Sorry if I confuse things more than explaining them, but I probably spent enough time already ;)

Edit: fixed some errors and overexplained even more :)
 

·
Registered
Joined
·
1,269 Posts
This is great insight into the design but is there going to be someone that says buy these parts and load this S/W?

I really liked the idea of
  • an iPod sized device that does the data capture and has a USB port for downloading.
  • or, something that takes an external thumbdrive instead of internal storage.
  • not really interested in realtime PC interface.
 

·
Registered
Joined
·
2,464 Posts
jac said:
Miguel you just made it worse.

1/2 way through your post my adult add kicked in. :D
Sorry about that.

weird, since I was at it, the numbers at the end of rob's username 13572468 is CF1974 in hex, coincidence? Carbon Fiber ?or 12/15/1974 or 2/07/1974?

I guess I didn't have anything better to do ;)
 

·
Registered
Joined
·
1,579 Posts
babak said:
Should I be disturbed that I have no idea what you're talking about? :)
Don't worry, sometimes we don't know what you're talking about! ;)

From my limited understanding, CANbus is a protocol used to get data from the engine computer, and upload data to it. For example, this is used when the dealer pulls your 1000 mile engine dump. Or if they reflash your engine computer with an updated map.

These guys are trying to reengineer the protocol that Lotus uses for communicating with their engine computer, and understand what all the data means.
 

·
Registered
Joined
·
12,374 Posts
Is there by any chance, oil pressure information in there somewhere? I miss having an oil pressure gauge. Even a nice small digital one would be wonderful addition...
 

·
Registered
Joined
·
2,195 Posts
Awesome work Rob! Thanks for posting the temp conversion math.. I hadn't figured out the relationship there.

Did you find out if the Dash actually receives a different CAN feed than the Diag port, or are they truely bussed together? I was able to send reports to the dash from the Diag, so I figured there was at least a bridge involved.

Also, where is the EBrake light encoded? I suspect it's in the MIL bits as well.

As far as inexpensive CANBus interfaces, the best offer right now is from Lawicel. For $119 you get a CANBus to RS232 that can do 1Mbps and has a fairly simply high-level interface that's hard to screw up:
http://www.can232.com/products.htm

For sale here and other places:
http://www.autoartisans.com/products/index.htm

Because it has an RS-232 back-end, it can't actually keep up with a full flood of 1Mbps CANBus data and will overflow. But, for sending messages or for receiving periodic packets, it works great. Acacetus also makes an RS-232 adapter that works well and is fully isolated (meaning the CANBus and RS-232/power don't bridge ground). It's about $250 from GridConnect. I like it, but it's especially limited at 56kbps on the RS-232 side.

To do the full monty, you need a USB interface, like the $250 ValueCAN:
http://www.intrepidcs.com/ValueCAN/
I shelved it earlier, because it would only do 500kbps, but now that they posted a bitrate configuration program, it's much nicer.

That one works great, but the low-level protocol is a bit more involved than the Lawicel. It can carry a much larger load at 1Mbps because it's on USB. Internally, it uses an FTDI USB serial convertor chip, so it works great under Linux too.

Overall, the Lawicel is the best deal going. The same company is planning a USB version, so hopefully they can trump the market there too.

I'm stoked to see your logger Rob! Nice work.
 

·
Registered
Joined
·
1,122 Posts
Discussion Starter #15
TimMullen said:
Is there by any chance, oil pressure information in there somewhere? I miss having an oil pressure gauge. Even a nice small digital one would be wonderful addition...
nope, the wiring shows a provision for it but it was never installed.
 

·
Registered
Joined
·
1,122 Posts
Discussion Starter #16
Ground Loop said:
Did you find out if the Dash actually receives a different CAN feed than the Diag port, or are they truely bussed together? I was able to send reports to the dash from the Diag, so I figured there was at least a bridge involved.

Also, where is the EBrake light encoded? I suspect it's in the MIL bits as well.

i checked the wires physically, its only the one bus from ecm to obd port to cluster.

the ebrake light is not encoded via CAN, it is on a discrete wire along with most of the other MIL lights. the actual bit encoding for MIL is as follows:

01- shift light
02- engine light
04- oil light


Ground Loop said:
Because it has an RS-232 back-end, it can't actually keep up with a full flood of 1Mbps CANBus data and will overflow. But, for sending messages or for receiving periodic packets, it works great. Acacetus also makes an RS-232 adapter that works well and is fully isolated (meaning the CANBus and RS-232/power don't bridge ground). It's about $250 from GridConnect. I like it, but it's especially limited at 56kbps on the RS-232 side..
keep in mind that although the bus is running at 1MB/s, the messages are only being sent out once every 100 milliseconds; this means that ~12 bytes every 0.1 seconds or 120 bytes/sec which is approximately 1100 bits/sec. when they converter manufacturer specifies latency as baud rates on the rs232 end, they are limited by the speed at which the internal microcontroller is doing the converting/parsing. this means that even the 56K adapter will work fine with this one application.
 

·
Registered
Joined
·
1,122 Posts
Discussion Starter #17
one more thing: ii worked out the actual encoding of the speed sensor value... it works out to be:

d(xxh) * 0.68 = mph

so a value of ECh = 236 dec * 0.68 = 160 mph



while were on that subject, i call the record for the fastest speed that anyone has gone in an elise... :D
 

Attachments

·
Registered
Joined
·
1,198 Posts
rob13572468 said:
one more thing: ii worked out the actual encoding of the speed sensor value... it works out to be:

d(xxh) * 0.68 = mph

so a value of ECh = 236 dec * 0.68 = 160 mph



while were on that subject, i call the record for the fastest speed that anyone has gone in an elise... :D
And with the brake engaged! Very impressive!

Did you at least open the garage door :)
 

·
Registered
Joined
·
1,122 Posts
Discussion Starter #20
andykeck said:
... and no seat belt either. A bold move, for sure.

yeah, see... well what happend was the car was going so fast that it travelled back in time to a point where a garage existed where the road was. once i saw the garage door, i attempted to avoid catastrophe by taking off my seatbelt, pulling the e-brake and jumping to safety, stopping only to snap that picture of the cluster as the speed fell thru 160 mph...

luckily, the brakes on the elise are SO good that it went from C (186,000 mi/sec) to 0 in only 10 feet. damn this car is amazing! :bow:


seriously, though, i the pic shows that it is possile to not only read the data from the ecu but interrupt and send new data to the cluster as well. it should prove to have some interesting possibilites including being able to reprogram the cluster firmware to accept new input data such as oil pressure reading or even to adjust the speedo to display corrected (actual) speed.
 
1 - 20 of 73 Posts
Top