![\"CTX](\"https:\/\/gonzos.net\/projects\/wp-content\/uploads\/2015\/09\/CTX-box-on-bike.png\")
<\/a><\/p>\nThe data is shown on a character display on the dash. It contains\u00a0the following information:<\/p>\n
Top row: gear position, coolant temp, instantaneous fuel economy (km\/litre), fuel in tank
\nBottom row: % of chain oiler cycle time, average fuel economy, km to empty.<\/p>\n
There is a detailed web interface that can be accessed via a smartphone:<\/p>\n This document was written to help others to build a system to communicate with the ECU on Honda motorcycles. The vast majority of information here has been obtained from contributors on the pgmfi.org forum. That forum has been \u201cdown\u201d for months, so the information is not accessible. Hence this document. Note: Feb 2016 – pgmfi.org is back up!<\/p>\n The key steps to extract information from the ECU are:<\/p>\n My setup was based on a Raspberry-Pi model B+ with a PiFace2 I\/O board running Raspian. I used a PiFace board because I wanted I\/O for driving various things on the bike eg: an auto chain oiler. However, I also used it for pulling the K-line low (see section 5 below). You could use some other method for this function, but it was convenient for me to use one of the PiFace’s relays.<\/p>\n The information flows in my system are quite complex:<\/p>\n Going through these items one by one:<\/p>\n You need to locate the socket on your bike. The CTX socket is a red 4-pin unit near the battery. The connections are 12V, earth, bi-directional K-line and a reset line. You need only the first three to talk to the ECU. Check your manual for the wire colours. The CTX uses a Sumitomo HM090 connector. The connector on the bike looks like this:<\/p>\n I made the following board:<\/p>\n This sets the port so that, when you use a program (eg Python) to specify 38400baud for the port, it goes to the custom speed instead of 38400. The port settings are 8 bits, no parity, one stop bit.<\/p>\n To get the adapter to work properly on a R-Pi, you need to add the following in the \/boot\/cmdline.txt<\/em> file :<\/p>\n Basically the ECU simply responds to requests for information. It doesn’t care if the response is not heard.<\/p>\n A typical request is of the form:<\/p>\n 72 07 72 11 00 14 F0 (in hexadecimal)<\/p>\n 72: the destination code (I think?)<\/p>\n 07: the number of characters in the message including the checksum<\/p>\n 72: the type of query (\u201cgive me data from memory?\u201d)<\/p>\n 11: the data table number<\/p>\n 00: the starting register within data table 11<\/p>\n 14: the finishing register within data table 11<\/p>\n F0: the checksum<\/p>\n The ECU will respond with a similar format:<\/p>\n 02 1A 72 11 00 XX XX XX …XX YY<\/p>\n 02: the destination code (I think?)<\/p>\n 1A: the number of characters in the message (in this case 26 decimal)<\/p>\n 72: the type of query (\u201cdata from memory?\u201d)<\/p>\n 11: the data table number<\/p>\n 00: the starting register<\/p>\n XX: the data<\/p>\n YY: the checksum<\/p>\n The checksum is calculated differently to the ISO OBDII protocol. It goes like this:<\/p>\n Sum all the values of the characters together, and take that value from 100 (hex). If the sum is greater than 100 hex, just use the last two characters (in hex).<\/p>\n So, the request message above (in hex) would be:<\/p>\n 0x72 + 0x07 + 0x72 + 0x11 + 0x00 + 0x14 = 0x110<\/p>\n Use only the last two characters, 0x10<\/p>\n 0x100 \u2013 0x10 = 0xF0 = the checksum F0<\/p>\n The response checksum is calculated similarly.<\/p>\n There are other query types (the third character in the request sequence). The ones I know to exist are 71, 72, 73 and 74. Code 71 requests all of the table data, rather than a subset:<\/p>\n 72 05 71 00 18 requests all of the data in table 00<\/p>\n I don’t know what a code 73 or 74 request does.<\/p>\n The ECU will not respond until it has received the correct initialisation sequence. I used this:<\/p>\n That’s it. You can then send requests and the ECU should respond with the data requested. The communications needs to be \u201ckept alive\u201d, however. That means that if the ECU hasn’t received a request within a certain time it goes back to sleep and needs to be initialised again. I think the time is around 3 sec.<\/p>\n Note that I haven’t tested the above times to see what the limits are. All I know is that they work for me and my system.<\/p>\n How do you pull the K-line low? I used a relay driven by the R-Pi. It simply shorted the K-line and ground terminals on the interface board. It doesn’t have to be a relay. If you’re using a \u201csoft serial\u201d where you can directly control the Tx line, you can simply pull that low, and the interface board will pull the K-line low.<\/p>\n I tabulated the information obtained from a few guys working on this project at pgmfi.org . The data for the small selection of bikes shows that the critical information is held in only a few data table, and some of these tables are duplicated (don’t know why). The most frequently used tables are 00, 10 and 60, 11 and 61, so those the re best places to start. Refer to the \u201cHonda Data Tables.pdf\u201d document:<\/p>\n Honda-data-tables<\/a><\/p>\n The document shows the contents of the various tables on the bikes tested, and it shows how to calculate the real life data from the values that come from the ECU. The data comes in single or double bytes \u2013 double bytes are used for data that needs more precision or has a high value (eg: engine speed)<\/p>\n If these data tables don’t work for you, you’ll have to write a program to \u201cscan\u201d through the various table numbers to see where the data exists. The ECU will simply reflect your query back at you if the table doesn’t exist.<\/p>\n Writing a program is up to you. I used Python running under Raspbian. You need a program that handles serial comms (obviously). You will have to be able to handle the following:<\/p>\n Receiving data is tricky. Because all the comms come on one line, the serial adapter receives all the data it sends, as well as the responses from the ECU. In addition, the ECU doesn’t necessarily respond immediately \u2013 it may be busy doing something else, so you have to wait until you have received the full response. In addition, the program has to ignore anything that comes back from the initialisation sequence.<\/p>\n I used the following process:<\/p>\n This is what I did \u2013 it may give you ideas. The R-Pi controls the following:<\/p>\n My R-Pi was set up as a wireless hotspot so the user interface (an old Medion smartphone) could be used without wires. In addition, it means that any program changes can be done without connecting a keyboard and monitor to the computer.<\/p>\n Here’s the assembly on the test bench:<\/p>\n<\/a><\/p>\n<\/a><\/p>\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
<\/a><\/p>\n1. Make a cable<\/h2>\n
<\/a><\/p>\n2. Make an Interface Board<\/h2>\n
\n\n
\n\t #!\/bin\/bash
\nsetserial -v \/dev\/ttyUSB0 spd_cust divisor 2307<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/p>\ndwc_otg.speed=1<\/code><\/p>\n4. Use the Correct Message Protocol<\/h2>\n
5. Use the correct Initialisation Sequence<\/h2>\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
6. Determine where the data is located<\/h2>\n
7. Write a program<\/h2>\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
8. Package it<\/h2>\n
\n
\n
\n
\n
\n
\n
\n
\n