Ford Focus V8

[Jaffman]

Fastdruid said:

*crunches knuckles*....

Right then, lets consult my big load of notes...

Tacho is 4-cylinder type as the 1UZ ign system is in effect two 4 cylinder engines (two ign generations/coils/dizzys), tacho signal is a simple mirror of the coil input. Pretty trivial to work with.

J1850PWM isn't CAN. Or at least it isn't CANBUS (we can argue all day if it is a Controller Area Network) , I've had a play with Mazda ISO 15765-4 CAN but that is trivial as you can buy CAN transceivers. You can use an ELM327 to communicate and they're pretty easy to use to scan data. If you get a USB ELM327 and connect via a serial terminal you can manually set the settings to what you want and just dump all the activity on the bus. Trouble is there that you need a "live" car to do it on and as far as I'm aware you don't have one.... If you have a Focus you can borrow then commands for the ELM327 are here.

https://www.elmelectronics.com/wp-content/uploads/...

To read J1850 PWM I'd do this (notes on what the commands do with the # lines

# Reset
AT Z

# Set 115.2kbps
AT PP 0C SV 23

# Turn on 115.2 setting
AT PP 0C ON

# Reset
AT Z

# Disable in-frame responses (not really needed tbh)
AT IFR0

# Monitor all messages
AT MA

Can then play about with looking at the data.

As for writing it the advantage as the J1850 PWM as a 5V bus you can use an arduino easily, disadvantage is you may need to bit bang. I've never tried as CAN is *way* easier.

I just called J1850 a CAN as it would hopefully make the most sense to people. call it Ford SCP or the 2 wires that let the car talk to itself for all I care I'm just glad someone knows what I'm talking about when I say J1850 😁

I've also maybe been a little disingenuous in my original question by not explaining everything, so here goes...
I have a few packets of data from a friend who has probably done what you suggest above to give me a bunch of data to work with, and tbh if I needed more it probably wouldn't be too hard to get the spare up and running for long enough to get more sweet sweet bytes from that proprietary network

Poor thing is looking sorry for itself sat next to that sexy looking red thing...



anyway, with these packets of frames we have managed to decipher how some of it works, ill explain briefly for those uninitiated.

you might have a frame of data that looks like this;

81 1B 10 25 12 6A 02 CE 00 11

and I know in general the first 3 bytes are the header, in the header you get priority, then destination for the frame, then the source of the frame, in this case I happen to know 81 is high priority, 1B is the tacho gauge on the cluster and 10 is the ECU. The last byte is seemingly always a checksum based on a polynomial equation, and the bits in between are ... well ... gibberish.

I have managed to work out that if you send a byte of 25 and then a byte of hex ranging between 2 specific numbers the tacho will spring into life and in this instance but as for the 6A 02 CE and 00 I am totally at a loss. which is what I was hoping for help with

(you know someone who worked on this stuff in the 90's might have some documentation laying around that they accidently upload into an email and send it to a stranger on the internet, stranger things have happened)

because whilst I know the malfunction light address, the tachometer, the speedo, the mileage counter & the coolant gauge, I still don't know the battery light, EML and any other interesting destinations. Knowing those would be a great help towards the end goal.

So as I said, I can get the dash to jump around and do a little dance based on the codes I send from an Arduino, what I cant seem to do is send them quick enough (I'm hoping my recent purchase of multiple Arduino Nano's solves this) and if I'm missing something in the packet of data I just mentioned that I should be sending beyond the first 2 bytes after the header. Progress is being made there though I guess, I'm just hoping someone can help me hurry it along 😊

of course, once I have achieved that and know how and what to send to the dash, I need to code the Arduino too do that based on real world conditions, so the analogue read of a ohmic value for the coolant temp sensor is probably an easy one, but nothing is more satisfying and gives more instant gratification that having a tacho dance to the tune of my foot on the pedal. to get that hit of dopamine I need to understand how to get the Arduino to recognise the signal I posted in my previous post, which tbh, I'm still none the wiser as to what it is.

I know its 12v at its peak and I know its pulsing at a frequency of 80hz, but what's the significance of that pulse and how to I tell the Arduino that that = ~1000 rpm?! I know I'm going to have to drop the voltage down to 5v so I don't fry the Arduino so that would imply using a voltage splitter but that would then make my current readings all wrong....

... im just gonna have to split the voltage and chuck the scope on it again aren't I...

[Fastdruid]

Jaffman said:

anyway, with these packets of frames we have managed to decipher how some of it works, ill explain briefly for those uninitiated.

you might have a frame of data that looks like this;

81 1B 10 25 12 6A 02 CE 00 11

and I know in general the first 3 bytes are the header, in the header you get priority, then destination for the frame, then the source of the frame, in this case I happen to know 81 is high priority, 1B is the tacho gauge on the cluster and 10 is the ECU. The last byte is seemingly always a checksum based on a polynomial equation, and the bits in between are ... well ... gibberish.

I'd suggest they're probably still adhering to OBD (certainly the RX-8 did). In which case this is handy https://en.wikipedia.org/wiki/OBD-II_PIDs

So if we take this: 81 1B 10 25 12 6A 02 CE 00 11
Header: 81 1B 10
Data: 25 12 6A 02 CE 00
Checksum: 11

Lets assume it's an RPM in which case it'll be a pair of bytes, lets call them A & B (because that's what the wikipedia page calls them)


Now this is where you need to know what the original car was doing, if we take those pairs then there are almost certainly two options.

25 + 12 gives 2372 RPM.
12 + 6A gives 1178 RPM.
6A + 02 gives 179 RPM (probably not it).
CE + 00 gives 13184 RPM (almost certainly not it).

In the case of the RX-8 the same message that sent the tacho data also sent what appears to be a torque delta, vehicle speed (two bytes, in Km/h) and accelerator pedal position.

Reversing that if we want to send a tacho signal I'd try the following pairs, try them in different positions and see if they work.
RPM A B
1000 0F A0
2000 1F 40
3000 2E E0
4000 3E 80
5000 4E 20
6000 5D C0

[Jaffman]

I promise I don't wait 3 months between updates on purpose - I guess I'm just Lazy!

either way its been on the dyno

massive disappointment









Standard engine management having a fit when it see's boost

so next upgrades are standalone ECU and custom dash so I don't have to mess about with any of that Ford nonsense