Eagle_Phoenix

WELLLLLCOOMMEEEE FOR HONDA WORLD, A WORLD OF HIDDEN INFORMATION THAT FORCE YOU ENTHUSIAST OF GOOD HEART TO TAKE YOUR CAR INTO THEIR WORKSHOP AND SPEND ALL YOUR MONEY!!!!!!!!

I HATE HONDA!

Eagle_Phoenix

I WILL PUNCH YOU HONDA!

Eagle_Phoenix

I NEED TO HAVE SOME PHONE NUMBER OF WHO I SHOULD SHOUT TO!!!!!!!

Eagle_Phoenix

I'VE PAID FOR MANUAL .... AND IT IS A C******************* S****************

Eagle_Phoenix

PROFANE WORLD

JDogg

http://www.modifry.com/products/ect/index.htm

Eagle_Phoenix

Works on model years 2000-2003 (AP1) & 2004-2005 (AP2)
Does NOT work on 2006 or newer clusters

Eagle_Phoenix

"SENSURED"

Eagle_Phoenix

"SENSURED"

Eagle_Phoenix

WOOOOOOOWWWWW 1,181 VIEWS

Eagle_Phoenix

Sad....

JDogg

did you think of calling modifry to see if he knows, but just hasnt built an adapter for it?

that being said, why not just go buy an earlier model cluster and not worry with all this?

Eagle_Phoenix

They clear answer that this stuff does not work at all on years after 2005, I dont have money to buy another earlier cluster.

The seller wants me to send this item back .... but I will not have any warranty if one day in this sauer life I will receive back this replacement cluster .....

I now will need to eat this cluster with "rice and roasted beans".

Tyler Riddle

Hi Man,

I feel your pain here I'm an open-source software enthusiast and hate it when I can't just change stuff I own. Unfortunately the temp gauge may not be so simple, it depends on how Honda has implemented things. I've spent some time trying to find any CAN-bus information about Hondas and it's a totally unknown world it seems. I am going to try to get details of how to talk to the coolant gauge and perhaps other parts of the CAN-bus; I've got another thread open with details about sniffing CAN-bus, interpreting the data, and why Honda might make this really really really hard to do.

The thread is over here.

Cheers mate, hopefully this will be solved Any Time Now(TM)

Eagle_Phoenix

Bump for a fellow-citizen.

Nice to find you here, it really shows how hard is this job I am doing and how people are misinformed about technologies.

I just left behind my cluster, I was going to open the cluster and find out on cluster controller what signals and voltages make the bargraph to work and make a mod with "ps2 mod wires" in order to make the bargraph to work.

The only problem is that it will not receive the proper signal to make the "oil file" to work properly.

Oil life is a function that based on water or oil temp it will tells the driver the proper viscosity life procesing the temp changes, it is a quite smart capability and I wanted to make this cluster fully functional.

But nobody help, honda service shop just ignore my calls, this is the reason why "Japan" is going down on economy ...... and "China" is blowing up and passed "Japan" on economy.

Why not share the information? it should be free or at least as I am an enthusiast, they could at least tell me what info I need to finish this project.

All I need to know is what wires are definetely responsible for can bus and what codes the receiver from s2000 cluster need to operate the bargraph on cluster up and down and then create in "Pic" a program set to this canbus stuff.

Please, add me on my msn contatopro@hotmail.com and fell free to contact me for more information, you got my blood in this project, this is my inspiration for my fathers company.

lets make it happen and help others to dont burn their heads with it anymore, too much greedy guys selling fries-fries mod that fries potatos and does not work in this cluster s2000 2007+ on canbus network.

Ahhhhhhhhhhhhhhhh

I wish the great arquitect of this stuff bless me with details for this to be finished and I install it on my Eagle Talon.

Bye for now.....

Tyler Riddle

While it'd be possible to program a PIC to output the right kind of signals to drive a CAN-bus interface I think you'll find the electrical signaling characteristics to be a total pain in the ***. A short search on Mouser shows CAN-bus chips going for a few US dollars in medium sized quantities; I'd think it'd be much much easier just to have the PIC talk to the CAN chip.

For instance, you need to enforce the constraint that no six identical bits can be in a row and the non-return to zero voltage levels. As well there's a header and a footer on the CAN-bus data burst giving a total of about 70 bits per burst (with only 8 of those bits being actual data values); the burst includes checksums, message types, etc. I think you'll drive yourself insane trying to support all of this.

Eagle_Phoenix

ok, so what o you advise in this situation? I am just feedup with all the Headeaches it caused me.

What is the right step, I mean

1.

2.

3.

?????????

Tyler Riddle

Basically all that's needed is to switch layers; instead of working in the realm of oscilloscopes and waveforms, or specifically how the information is transmitted to the cluster, one works in the realm of the data - identifiers and values. The CAN-bus spec is loose in a lot of regards, not just when it comes to what data on the bus means. It also allows the vendor to choose different types of electrical characteristics for the bus to use. Basically all that is non-sense to the actual problem: feeding it the right numbers to get it to stop blinking 12:00 like some VCR from the early 90s.

I can't find any information on the Honda implementations of CAN-bus but it'll be important to know what the signaling standard is and then once that's sorted out the data will have to be tackled. My previous post is about what kind of data might be there and why having access to that data, or even identifying the ID of various components, may not actually unlock talking to them.

I don't have an AP2 so I can't read the CAN-bus data for the instrument panel; I also can't find any CAN-bus data wires in my AP1 so far. My plan for getting the ID of the panel and injecting some test values is to get a pair of CAN-bus transceivers, hook them both up to my computer with some custom software, and track and filter all the data that comes over the CAN-bus stream into the panel. By turning off each specific ID I'll be able to figure out quickly which one it is that makes it light up. Since I've got full control of that data stream I can quickly try injecting some values to see what it does or log a bunch of data as some test signals go into the coolant sensor. I think as well correlating the data coming across the CAN-bus at any moment in time to the data coming across the OBD-II connector will be a great help.

If we are super super lucky the OBD-II connector is using CAN-bus for it's data transfer and it's the exact same data that's going into the instrument panel. The encoding for the data is well known because any OBD-II reader can get that information and already displays it. In this scenario as well the instrument panel is basically just an OBD-II reader.

If that's not the case then correlating the values going into the instrument panel with the temp data that comes across OBD-II should give a dead simple way to identify what is going on. If the encoding is non-trivial this will also offer some much needed data to reverse engineer it.

If Honda has decided to obfuscate or encrypt things (I know how you feel about how Honda has handled this situation and the lack of available data but I can't confirm or deny yet they have actually made this out to be harder than it needs to be) then it might be a total show stopper.

Eagle_Phoenix

Please, confirm for me if they encrypted the data, because if they did so, it will be a pain in the ***, and I have pain on ***.

hahhhahha

All the methods tried and I want to make this cluster perfect, if at least Honda could give me this in private, then under this agreement, I will not make this public, I will keep it with my responsibility and then definitely I will need to become a “FAQ”.

Maybe this is the reason why they don’t want to reveal the "codes" and encryption as it could open the gate to many crook captains develop and steal my “*** pain” project, selling stuff to people mod automatically this cluster into their cars.

Also, it could increase the thieves on this car brand model on USA, this maybe are the weak point on Honda reveal the codes for me and I make it public.

Especially now that we got all around the world people asking for £0.50 pence or $0.50usd and R$1.00 real money on streets.

FULL OF SCAMMERS ALL AROUND THE WORLD, BUT THIS PEOPLE HAVE SHORT LIFE.

Anyway, think about it, the possibility for we to get this information on private and not make it public.

We could check if the cluster was not stolen and if definetely it was from a "insurance" salvage car.

Tyler Riddle

Have you been able to use your scope to record any kind of output from the cluster on the CAN-bus wires? Specifically, if the cluster is acting as an OBD-II reader we should be able to investigate the signal and match up the queries for the ECT information to the known OBD-II over CAN-bus values. The cluster would need to send a query message and wait for a response to it; it is also possible we would see this query every few seconds as the cluster tried to find the ECU.

It's also possible that the ECU has to send data into the cluster before it'll "wake up" and start trying to query information. But we can start by looking at what ever information the cluster puts out onto CAN-bus when it gets initial power.

In the Helm for the 2006+ S2000 can you find out if the CAN-bus line in the instrument panel is electrically the same as the CAN-bus line going to the DLC? How does the Helm identify that wire? What is it's label? In my Helm (2002), under the Body Electrical chapter and Gauges section there is a Coolant temperature Gauge Circuit Troubleshooting procedure - it specifies a continuity check between pin 7 on Gauge Assembly Connector C and ECM connector A. Obviously it'll be slightly different in your Helm but once we know what pin the cluster is talking to the ECU on we can check to see if it's the same pin as the DLC. The troubleshooting procedure for the DLC should also link the CAN-bus pins back to the ECM - if the match up, we move one step closer to winning.

Another place I've been finding really good information is alldatadiy.com - in reality it might all be exactly the same information as is in my helm but I don't think so; its' also got estimates for jobs and other information a service station would require. It's been a good reference for pin-outs on my AP1 but you pay for the data for each specific model year. :-(

Tyler Riddle

Here is some more information I was able to scrape together:

Pin 26 of connector B on the 2006 instrument cluster is a 'F-CAN' signal line labeled "SEFMJ" that goes to the ECM via Pin 13 of connector E. The ECU guide lists pin 13 of connector E as a multiplex control unit communication line and labels that pin "SEFMJ" as well. This pin seems to be for the exclusive use of the instrument panel (contrasted to the TL implementation talked about in the links below).

The DLC in 2006+ has the CAN lines connected to the ECU via pins 11 and 24 on connector E; the DLC is using two wires but still labels the wires F-CAN (contrasted to the single wire F-CAN for the instrument panel). This may mean the F-CAN specifically refers only to the speed of the data across the line, not the electrical characteristics. It may also be that something is wrong with this data I found; this discrepancy is hard to account for with out finding more details.

F-CAN or Fast Controller Area Network is not something I'm able to find very much information on but apparently on a TL there are two busses Honda uses: F-CAN and B-CAN (body CAN). See http://tl.acurazine.com/forums/showthread.php?t=645068, http://tl.acurazine.com/forums/showthread.php?t=643562, and http://www.mdxers.org/forums/19-audi...-nav-unit.html

Tyler Riddle

Here's some more good information I found:

• Information on a Philips CAN controller IC which has details on the signal characteristics for single wire CAN: http://www.nxp.com/documents/applica...ote/AN2005.pdf
• An overview of the DeviceNet protocol used on top of CAN: http://www.rtaautomation.com/devicenet/

I have not been able to confirm Honda is in fact using DeviceNet to communicate with the instrument panel (or any other information on protocols they may be using as well) but this is my best guess right now.

The good thing about DeviceNet is that the network only supports 64 unique devices at a time. This means if the panel is using device net you should be able to query all 64 addresses for their device information and if the panel responds with some information about itself then it's running DeviceNet. The bad thing is that DeviceNet is connection oriented much like TCP/IP so the overhead of connecting to a network device and querying it is high.

It's also been hard for me to find very much information on DeviceNet; the standard is claimed to be "open" but you need to pay $1000 for the 350 page specification, blah.

Now that I think about it, there are only somewhere around 2,000 unique addresses on a CAN version 1 bus. You should be able to program your PIC to inject values on each and every combination of addresses and see which one makes the instrument panel light up. Because of some rather nice design decisions in DeviceNet when you are sending data to all those unique combinations you'll also be sending DeviceNet control data at the same time. If the panel is running devicenet during your scanning you should see it responding with error data telling you that you talked to it wrong.

If you go down this path you must make sure the signaling characteristics are right as apparently CAN is very sensitive to this. My best guess is that honda F-CAN signals at 500kbit but you may need to perform the search of the network at all the defined CAN speeds, starting at the fastest.

Eagle_Phoenix

Good information buddy! We together sure will make this greedy cluster back on life, if it was so easy, anyone could make it!

Sure, we will win this battle, but it will be a fashionable fight between the finest people!

All the information you gave me was the smartest ideas I received in this forum, I really appreciate your help.

The only issue is that the Ap2 Cluster on model 2006+ (this one is the 2007 exactly) has two sockets only “A” and “B”.




HONDA S2000 AP2 YEAR 2007 FUNCTIONS DEMO.

http://www.youtube.com/watch?v=UlZ4S...layer_embedded


TACHO SIGNAL TEST (12 VOLTS POSITIVE SQUARE PULSE FREQUENCY)

http://www.youtube.com/watch?v=69rJY...layer_embedded

SPEED SIGNAL TEST (SQUARE WAVE 28, 3 PULSES PER 1 KM\H – 2830 HERTZ FOR 100KM\H)

http://www.youtube.com/watch?v=odju5...layer_embedded

FUEL GAUGE (NEGATIVE WIRES TO NEGATIVE OF 1.5 BATTERY AND POSITIVE ON B10 WIRE) YOU MUST HOLD ON SOME SECONDS IN ORDER TO THE CLUSTER RETARD VARIATION STABILIZE A BARGRAPH.

http://www.youtube.com/watch?v=ln5eg...layer_embedded

Let’s be objective and direct the cluster has the following functions that we need to find out how to enable it:

1. Speedometer, Tachometer, Fuel Led Bar, Temperature Led Bar, External Temperature data displayed on cluster, Oil Life Viscosity based on Changes of Engine Temperature, Airbag Light, ABS Light, High Bean, Low Bean, Oil Pressure, Battery Charge Light, Doors Open, Open Boot, left turn signal, right turn signal.

2. Speedometer works based on 28 pulses per 1km\h or 2830hertz per 100km\h on square wave, I’ve created a speedo healer based on pic and one transistor in order to increase and decrease the pulses based in a switch key multipliers. Then we will include on our “module box” the circuit that will make the conversion together with the “pic obd2 or can emulator to this cluster.

3. Tachometer is a positive pulse of 12+ positive volts on square wave also, we believe that if the Eagle Talon has the 12+ volts on signal, it would not require any mod on tacho, however if there is any difference, then I will make a kind of circuit to invert the voltage.

4. Fuel Led Bar works with 1.7 or 1.8 volts, as much the voltage fall it decrease the fuel leds on to off state until the cluster alarm we that there is no fuel on tank, here we must find out what voltage the Eagle Talon send to original cluster and then create a circuit in order to based in this voltage, it will generate a voltage of 0.200 millivolts and alarm the empty tank when it is empty and as much the fuel lever goes up (more fuel) it increases the voltage until the maximum supported on cluster to make the full led bar on (basically 1.7volts to 1.8 volts full led bar on).

5. External temperature? What wires are exactly responsible for external temp? is there any voltage that must be supplied on cluster together with a resistance (thermostat) what is the resistance variation in this thermistor on front bumper?

6. Left Turn and Right Turn, OIL PRESSURE works on normal signal, also door open and boot open the same.

7. The high Bean and Low Bean it seems that it work on “OBD2 or CAN” because nothing could make the headlights on and the same for battery warning light and malfunction warning light, in regards my strong research, we realize that it work on “LIN – LOCAL INTERCONECT NETWORK) the can slave receives a header with a code to enable the lights on high bean, battery warning light and malfunction lamp in order to make it ON AND OFF.

8. Now the Coolant temp it is technically the same than fuel, except that it receives header and data to make it full (hot) or off (cold), based on KM odometer and high temp it calc the “Oil Viscosity life and shows a percentage %.

INFORMATION NEEDED:

LIN = LOCAL INTERCONECT NETWORK
CAN = CONTROLLER AREA NETWORK
OBD2 = ONBOARD DIAGNOSTIC II

http://www.youtube.com/watch?v=M1VI9...layer_embedded


A)IS THE HIGH BEAN ON LIN-CAN?

B)IS THE BATTERY WARNING LIGHT ON LIN-CAN?

C)IS THE MALFUNCTION WARNING LIGHT ON LIN-CAN?

D)IS THE COOLANT LED BARS ON CAN-BUS OR OBD2 DATA? HOW TO TALK TO COOLANT LED BARS AND MAKE THEM GO UP AND DOWN?

E)IS THE OIL LIFE LINKED TO COOLANT? WE UNDERSTAND THAT BASED ON COOLANT TEMP, IT WILL SHOW A MATH % PERCENTAGE.

BASED IN THIS INFORMATION I CAN CONCLUDE THE PROJECT IN ONE WEEK TIME.

Tyler Riddle

I was ambiguous before - let me clear that up. Pin 26 on connector B of the instrument panel goes to Pin 13 on socket E for the ECU. This is the pin I identified earlier as the F-CAN line using one diagram. Before I crafted this post I double checked my findings and used another diagram, this one labels Pin B:26 as 'MIL control' - TADA! If you are sure that the panel is using LIN then the answer to the question of "is it LIN, CAN, or OBD-II" is YES! LIN is CAN and OBD-II. LIN is implemented as a subset (or using parts of the specification in any case) of the OBD-II protocol on top of CAN.

I think you can safely assume (for now anyway) that everything left is on LIN (ignore DeviceNet); I think the next step is to "fuzz" the instrument panel with LIN data. Basically have your microcontroller run through all the different LIN ids (good thing there are not very many) sending random data bytes (the number of bytes per packet is all configured by the manufacturer when it's designed so you'll need to match it). You may also want to just blindly assume that the instrument panel is going to be configured by Honda to work almost exactly like OBD-II with the OBD-II data encodings and PIDs.

The LIN protocol was designed specifically to be easy to implement - it looks like it could be done with a microcontroller with out a lot of hassle. Here's an idea - take a microcontroller and hook it up to the LIN line and the bulbs for the things you need to identify how to turn on. Send all of the possible values that LIN can do for all of the possible identifiers and have the uC identify what bits it sent triggered an action on one of the lamps then record that. If you have the panel installed on your car you could run some external power into it and let it run at night.

I'm a software guru, we do stuff like this all the time to see how the software functions on various computer systems. I've never worked on stuff like this but it's not a far jump anymore from Ethernet to CAN and these computer systems are absolutely fascinating. :-) See also my previously mentioned thread where there is a post about a set of computer scientists who were able to use CAN on a GM to turn it into a total death trap with hidden and nearly impossible to find soft modifications to the vehicle or by setting various components (like the ABS controller) into a test mode where it canceled all driving braking input while the vehicle was rolling.

Eagle_Phoenix

Ok, let’s get the fried chicken, then we realize that the pin 26 on connector "B" is the can bus\obd2 and Lin input signal? What other wires is together this?

I am on point to create this pic signal injector to do a brute force and crack the headers and further instructions bits, I haven’t got the ecu, all I got is the cluster alone and would like to know a way to sniff any data it may send to ECU that is not available then we will add this wire straight to input of oscilloscope and see what it tries to send to "ECU", however we are talking only about pulses and frequency, then how to decode into numbers and values those frequency?

Correct if I am wrong, will this cluster works like this?

B26 ask on "ECU" bad luck wire number "13"

"I am here with the coolant bar graph with one led bar on, the battery warning light on, srs airbag warning on, check engine warning light on, high bean off, what information you got for me?"

Then "ECU" answers...

Ok we are going to talk on ISO15765 language:


The signal I got here is related to “thermostat resistance” on coolant sensor, the master transformed that resistance into a bit value as bellow and he order the slave to light on 19 active segments because the engine is getting fried.

We know that the cluster has 19 segments on temperature bar graph led, but what are their names so I can turn them on and off?


ISO15765 (Standard)

This protocol is a multi-frame version of CAN used on vehicles. It extends the CAN protocol in two main ways. First, it can transmit large logical messages (up to 4095 bytes) using a series of individual CAN frame. Second, it provides control over the rate at which individual message frames are transmitted.

There are two addressing modes: Standard (11-bit) and Extended (29-bit) and both are used on OBD-II vehicles.

Table 3: ISO15765 Message Structure Type Header (4) Data (4095 max)

D0 D1 D2 D3 D4 ... DN EDI

Functional Request 00 00 07 DF X Y Z CRC

Physical 00 00 0A BC X Y Z CRC

Flow control filters are used to establish an ISO 15765 conversation. These filters automatically transform the large logical messages (up to 4095 bytes) into a series of individual CAN frames (up to 7 bytes each). By default, the requests that multi-frame message send as quickly as possible, in a single burst, with no interruption.

Some controllers expect the messages to be zero-padded to a full 8 bytes, while others expect only the necessary data. Adjust the ISO15765_FRAME_PAD flag to match the expected behavior.

Functional Addressing

The tester can broadcast an OBD-II request using identifier 00 00 07 DF. In this mode, expect several modules to respond to each request.

There are no other interesting, standard functional addresses available on this protocol.

Physical Addressing
For this protocol, each automaker assigns addresses differently.

OBD-II Tester Code
// Establish a logical communication channel using ISO15765

PASSTHRU_MSG Mask, Pattern, FlowControl;
U32 ChannelID, MsgID, i;

PassThruConnect(ISO15765, 0, &ChannelID);
for (i=0; i < 7; i++)
{
Mask.ChannelID = ISO15765;
Mask.DataSize = 4;
Mask.Data[0] = 0x00;
Mask.Data[1] = 0x00;
Mask.Data[2] = 0x07;
Mask.Data[3] = 0xFF;
Pattern.ChannelID = ISO15765;
Pattern.DataSize = 4;
Pattern.Data[0] = 0x00;
Pattern.Data[1] = 0x00;
Pattern.Data[2] = 0x07;
Pattern.Data[3] = (0xE8 + i);
FlowControl.ChannelID = ISO15765;
FlowControl.DataSize = 4;
FlowControl.Data[0] = 0x00;
FlowControl.Data[1] = 0x00;
FlowCotrol.Data[2] = 0x07;
FlowControl.Data[3] = (0xE0 + i);
PassThruStartMsgFilter(ChannelID, FLOW_CONTROL_FILTER, Mask, Pattern, FlowControl, MsgID);
}
Mask.ChannelID = ISO15765;
Mask.DataSize = 4;
Mask.Data[0] = 0x00;
Mask.Data[1] = 0x00;
Mask.Data[2] = 0x07;
Mask.Data[3] = 0xF8;
Pattern.ChannelID = ISO15765;
Pattern.DataSize = 4;
Pattern.Data[0] = 0x00;
Pattern.Data[1] = 0x00;
Pattern.Data[2] = 0x07;
Pattern.Data[3] = 0xE8;
PassThruStartMsgFilter(ChannelID, PASS_FILTER, Mask, Pattern, NULL, MsgID);