Anyone got an arduino on hand? Might be able to start faking some speedo input and start increasing the odo.
Not sure what the ppk for fords are, but id say 3000ppk would be a safe bet. Soooo, 3000pulses/km x 1km/hr = 3000pulse/hr = 0.83pulses/sec so at 100km/hr it would be 83.3pulses/sec.
Just need to make the arduino to pulse the digital pin 83times a sec.(assuming I did that basic maths right!)
Seems we are at the point of needing to get a few 1km increment reads to nail this algo.
Interior Modifications
BA Falcon Instrument Cluster EEPROM Programming
by Rerouter » Mon Dec 08, 2014 5:51 am
I have some arduino's and your math is sound, 83.33hz, or how it will be done in software is a pin toggle every 6 milliseconds, my thoughts here are that for the even numbers it modifies the even bytes, 0,2,4, etc, or adds something to numbers that are dividable by 16 + 7, probably similar to the how the odd bytes are handled for the +2 increments,
if you need any help with the code just pm me,
if you need any help with the code just pm me,
by TazzI » Mon Dec 08, 2014 7:18 am
aumatt wrote:The issue I see with that is that the cluster doesnt have a speed input as it is a CAN message from the PCM.
Matt
Well I guess that answers that. I thought there was a speed input when looking at the pinout diagram.. Can someone post that up as it's hard to navigate on the iphone! I'm sure matti has it posted up in the cluster section.
In that case, if it is a CAN message.. That's even better!
Just listen into raw chatter, then spam correct frame back to the cluster on bench. Easy as.
by TazzI » Mon Dec 08, 2014 7:44 am
Hopefully this image comes out alright on tapatalk. Looks like pin 2 and 3 on the cluster are used for CAN communication.
You do not have the required permissions to view the files attached to this post.
by TazzI » Mon Dec 08, 2014 8:15 pm
This doco is a better pinout for the ba cluster.
Five or so wires and both elm and cluster can be hooked up on bench.
But, we will need some raw comms reading from a BA ford to get this moving.
Five or so wires and both elm and cluster can be hooked up on bench.
But, we will need some raw comms reading from a BA ford to get this moving.
You do not have the required permissions to view the files attached to this post.
by Rerouter » Tue Dec 09, 2014 8:29 pm
According to what i can dig up, its J1979 and speed is PID 0D, would this alone be sufficient info to inject with an ELM?
by TazzI » Wed Dec 10, 2014 12:13 am
Rerouter wrote:According to what i can dig up, its J1979 and speed is PID 0D, would this alone be sufficient info to inject with an ELM?
Not quite mate, I think the J1979 (PWM) is used on the older models (I Think!.. might have to check on that with zerone since hes to goto for ford stuff as well!). I know that ford did use J1979 at some point for the ECUs which is essentially VPW but with two wires instead of 1.
But Im fairly certain it uses CAN 11bit
As for the PID, using PID 0D will request the speed from the ECU, PIDS as used to ask for diagnostic data from a module. What we are after is the "constant chatter" that is always happening over the comms line by all the modules at once. The ecu will be outputting a constant message with data including speed, rpm, faults, coolant temp ect. This message is then picked up by the instrument cluster and displays the appropriate speed,rpms ect and updates the trip and odo.
So what we want to do, is put the ELM into CAN11bit and then send off a "ATMA" which means "Monitor ALL chatter" and will display all the data on screen. Then, we go through each different frame captured until one of them makes the trip and odo values increase.
*Edit
This is in the fordmods forum, on the au series fords, they used PWM for communication:
Had a bit more of a play, to get codes for an AU with an elm, fire up hyperteminal and enter the following where the prompt is >
// Set the protocol for J1850 PWM
>atsp1
OK
And, here is someone turning the traction control off/on in the instrument cluster on a BA using can (can see them set the header to 720 so it must be CAN 11bit) http://www.fordmods.com/auto-electrical-forum-f89/disabling-traction-control-lamp-on-ba-t122568.html
OK, thanks to the scantool thread of Luke I have managed to turn it off.
With ELM327 set to 38400 , 8 , n ,1 and ignition ON.
atsh720 <- Cluster
ath1
3b03010c <- high series cluster TC off
or
3b03030c <- high series cluster TC on
by TazzI » Wed Dec 10, 2014 12:52 am
Nice little list of the protocols used in some of the fords. Looks like they use the same as the VZ V6 on CAN 11bit 500kb/s.
http://www.runtek.it/FORD%20_OBD.pdf
Iv also seem a few posts dotted here and there by aumatt way back in 2011. Looks like hes attempted to make something for the clusters already. Even an app for updating the police mode. See attached.
Im yet to investigate further. But Im pretty sure, based off the other info found now, that all the programmable features can be done with the standard DID functions. Before anyone asks, PIDs are diagnostic requests whereas DIDs are programmable sections which generally hold vin,serial.ect.
eg 3B 03 01
Which means:
3B = WRITE DID
03 = DID table 03
01 = DATA
Reading DID's is just as easy. All we have to do is either listen in on a scantool, or read out each possible DID then match it up with the eeprom findings and we will be on our way.
Alot of DID requests utilize multiline responses. This means the response will come back as more then 1 line. Iv already dealt with this before, both reading and writing is easy with the correct commands. But using terminal will be sufficient for reading out the DID data in the clusters.
We should be able to use my "software on ELM street" software to monitor all the traffic in car or from a scantool. And if there is too much traffic, we can just set custom filters and try narrow down the ecu responses.
Soooooo whos got an ELM?! Should definitely try get this kickstarted!
http://www.runtek.it/FORD%20_OBD.pdf
Iv also seem a few posts dotted here and there by aumatt way back in 2011. Looks like hes attempted to make something for the clusters already. Even an app for updating the police mode. See attached.
Im yet to investigate further. But Im pretty sure, based off the other info found now, that all the programmable features can be done with the standard DID functions. Before anyone asks, PIDs are diagnostic requests whereas DIDs are programmable sections which generally hold vin,serial.ect.
eg 3B 03 01
Which means:
3B = WRITE DID
03 = DID table 03
01 = DATA
Reading DID's is just as easy. All we have to do is either listen in on a scantool, or read out each possible DID then match it up with the eeprom findings and we will be on our way.
Alot of DID requests utilize multiline responses. This means the response will come back as more then 1 line. Iv already dealt with this before, both reading and writing is easy with the correct commands. But using terminal will be sufficient for reading out the DID data in the clusters.
We should be able to use my "software on ELM street" software to monitor all the traffic in car or from a scantool. And if there is too much traffic, we can just set custom filters and try narrow down the ecu responses.
Soooooo whos got an ELM?! Should definitely try get this kickstarted!
You do not have the required permissions to view the files attached to this post.
by LangasLS » Fri Dec 12, 2014 3:45 pm
Well as of today I have an ELM sitting next to my BA cluster - Time to do some reading to make it all work 