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:
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:
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...