The Lotus Cars Community banner
  • Hi there! Why not register as a user to enjoy all of the benefits of the site? You may register here. When you register, please pick a username that is non-commercial. If you use a name that appears on any search engine commercially, you must pick another name, whether it applies to you or not. Commercial usernames are for supporting vendor use only. If you want to become a supporting vendor and grow your business, please follow this link. Thanks!

CANBUS RE analysis

45K views 72 replies 34 participants last post by  Gradenko 
#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...
 
See less See more
#52 ·
I am also very interested in bringing something to fruition here (particularly as it pertains to a speed sensor signal, and potential for Valentine 1 display). If there is anything I can do to help, let me know.
-Sky

cjl said:
Has anyone else made progress with this? I'd like to resurect this project and am very interested in spearheading a GPL'd movement for both hw and sw dev for the CANbus on our Elises.

Thoughts anyone?
 
#53 ·
I need a speed signal for the in-dash nav I have. Without it, the system won't work. Period.

For those of you who wish to add your own VSS, there are some problems that may be insurmountable. I have a VSS kit to work with a Blaupunkt travel pilot and there is no way I can think of mounting it. They have a diagram on how to mount it, but on a Lotus, there is nothing behind the rotor to tap a screw in so the sensor can read the tape.
 

Attachments

#55 · (Edited)
There is already a wheel speed sensor on each wheel.

If you have a high-impedance input, you can probably just tap (carefully) the shielded sensor line. But it's for the ABS so I'd rather not.

Fortunately, you can also pick up the same four signals after they've been buffered and amplified by the ABS logic. They're in the wire bundle between the ABS and ECU. See the wiring diagrams.

Seems a lot easier than mounting another sensor on the wheels.
 
#57 ·
Ground Loop said:
There is already a wheel speed sensor on each wheel.

If you have a high-impedance input, you can probably just tap (carefully) the shielded sensor line. But it's for the ABS so I'd rather not.

Fortunately, you can also pick up the same four signals after they've been buffered and amplified by the ABS logic. They're in the wire bundle between the ABS and ECU. See the wiring diagrams.

Seems a lot easier than mounting another sensor on the wheels.
Maybe, but I couldn't figure it out. For me, it was awfully easy attaching the tape to the inside of the front wheel and bolting the sensor to the existing bracket of the abs sensor. Then you just run the wire through the rubber donut all the other wires go through in the passenger footwell, up through the cubby on the right side, and then accross that shelf that is under the passenger airbag, which leads to the back of the radio.

I now have what may be the first elise on the planet with a proper speed sensor. Anyone running an in-dash system with no speed sensor is really missing out I think. My GPS is accurate to what seems like an inch.
 
#58 ·
I have mounted a magnet on the rear wheel which sends a signal to the Panoram Bike Speedo on my dash. good up to 115mph and dead accurate.

Works great for me. I installed the week after I got the car...March 2005.

I just could not put up with an indicated 80 and only doing 73-74 Mine is better at low speeds...only about 2 mph off and increases as you go higher..

Tony V
www.lotusowners.com
 
#59 ·
Autoenginuity looking for an Elise in Mesa

AutoEnginuity manufactures scan tools and claims they have 60% share of the scan tool market for professionals.

I have purchased one of their scan tools and am doing an analysis for this group. However I have experienced some problems with the update rate and control of the car's functions while using the tool.

AutoEnginuity wants to do some diagnostic work and wants to upgrade the tool's ability to get to some of the extra data in the Lotus ECU.

If you live in Mesa, AZ or close by and are interested in letting them plug into your car, they will provide a their tool to you at cost for your troubles. Please let me know if you are interested and I will provide the contact information.

You can check out their product at autoenginuity.com.

This is not(!) a recommendation for their product. In fact, I suggest you hold off on purchasing one until the problems I have seen are resolved.

Michael
 
#63 ·
I've seen and used many OBD, GPS and professional data loggers on the market. There's one things missing.... a cheap data logger that's easy to use and has software that provides good information for track use and coaching. Look at the OBD market alone, there's tons of companies producing cheap products, but none of them are really great.

With people on this board interested in making one, who is going to produce something for all of us to use?

My only issue with doing all this freeware stuff... those who program it will find other interested and stop development. So maybe a community project should be setup so that new people can continue where others left off?
 
#64 ·
Fast, cheap , good you only get two.

I have my own OBD II logger, but there are a few problems, namely the update rate is so slow that it doesn't really seem worthwhile, you really need to add external sensors or tap into the existing sensors.

A couple of people have talked about making a free one, why not go ahead and start one and see who joins in.
 
#65 ·
charliex said:
Fast, cheap , good you only get two.
And you usually don't even get two...;) rotfl
 
#66 ·
Does the Lotus ECU implementation of CANbus implement a CAN Application Layer like CANopen, or is it a proprietary protocol? I'm looking at the OSI diagram on this page:

CAN Application Layers

If I buy a CANbus->USB connector and want to write some custom software can I get raw access to the data stream without using proprietary driver API? From reading through various posts it seems as if others have been parsing the raw packets.
 
#67 ·
go back to the beginning of this thread and read the first page: There is no application layer at all: Its literally just one message with all of the speedo data stuffed into the 8 bytes. I guess you could say its proprietary but its so simple that it doesnt really matter: just one frame sent from the ECU to the cluster.

I do alot of mercedes CAN work and by comparison you will see an application layer used on each of the *six* seperate CAN networks that are built into the newer models. In fact there is a seperate application layer actually exists across all of the networks since they are interconnected via gateway translators that relay specific messages from one network to the next. The mercedes application layer is proprietary as are most automaker vehicle networks; they arent really interested in open networks. The only exception is MOST fiber networks which uses common standards but even then non of the manufacturers adhere to the standards enough to make components interchangeable.

As far as using a USB adapter to access the CAN data you dont need to even worry about any sort of API except for the CAN adapter itself (e.g. to handle the actual data transfer over USB). most USB-CAN adapters have their own API and software examples so that you can write your own code; PCAN-USB by PEAK is a good example. As far as the data itself you get back 8 bytes and then just parse it.
 
#68 ·
I love annual post resurrections ;)

Rob you wouldn't happen to have a little black box that would take the following inputs and drive the stock cluster would you?

- rpm (via a low voltage coil line) also trips shift light when required (adjustable)
- speed (via stock wheelspeed sensor tap)
- temp (via stock sensor tap)
- fuel level (via stock sensor tap)
- oil pressure light (via stock sensor tap)
- miscellaneous input for mil light

I just remembered that you were working on this and wondered if anything had progressed further as mentioned in this post...

http://www.lotustalk.com/forums/894574-post4.html

Thanks!
 
#70 ·
i've been using this thread to work on my own ECU to lotus dash conversion box - i'm running a standalone ECU - thought some might be able to use what additional info i found.

working on the awesome work of the OP, Rob, above ....

frame data: aa bb cc dd ee ff gg hh

aa = dash understands speed in kilometers per hour (good as i live in Australia and we are metric)

bb = unused

cc = first part of rpm. take rpm from ecu output eg. 4000rpm and divide by 256 = 15 (dont care about the decimal left overs(.625)) now convert 15 to hex (0F) and send to the dash.

dd = second part of rpm. take the second two digits of rpm eg 4090, now just use 90 and convert to hex (5A) and send to the dash.

ee = fuel - all depends on your ECU calibration. as Rob states - 00 - FF

ff = engine temp. dash needs to understand engine temp in deg F for some reason. and has an offset of -14. so for 90 deg C engine temp use the following: ((tempin * 9.0 / 5.0)+32)+14 where tempin variable is 90

gg = various dash lights:
send the following to the dash - all in hex. tc = traction control light.
00 = off. 01 = shift light. 02 = MIL. 03 = Mil&Shift. 04 = oil. 05 = oil&shift.
06 = oil&mil. 07 = oil&mil&shift. 08 = tc. 09 = tc&shift. 0a = tc&mil.
0b = tc&mil&shift. 0c = tc&oil. 0d = tc&oil&shift. 0e = tc&oil&mil.
0f = tc&oil&mil&shift

hh = unused by dash.

Hope this helps some people, i spent a while working it out as i dont have lotus ecu connected up any more - just a dash on my workbench with a couple of arduino boards - 1 sending CAN and one listening and resending to dash. my ecu outputs CANBUS, but it is not able to modify the values....
 
#71 ·
Digging into the past; but has any hardware s/w come of this for us not programming geeks? Wanting to dump info to datalogger and Valentine 1 display to dash. Also where does steering angle and TPS and MAF data go onto CAN bus of newer cars? FYI, the speed conversion of x*o.68 = mph works out to be the conversion factor from feet/sec to miles/hr 60*60/5280= 0.681818 Also any knowledge as the CANbus protocol used in the Evora?
 
#73 ·
I've finished the Arduino software to convert Haltech CAN output to something the Lotus dash can understand. Works pretty well, complete with gauge sweep, but the fuel gauge goes up veeeeery slowly. Not sure what is wrong with that yet.

Source code is available here for those interested: https://github.com/dineshpannu/CANBusTriple-Lotus/

With most of the interesting stuff in:
https://github.com/dineshpannu/CANB...ter/avr/examples/CANBusTriple_Lotus/Haltech.h
https://github.com/dineshpannu/CANB...r/avr/examples/CANBusTriple_Lotus/LotusDash.h

The Arduino unit I'm using is this: https://canb.us/
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top