tim36 wrote:Hey guys, I've been playing with this too. There's a great forum on using the com-port to speak to modules via the CAN through an elm scanner, "http://www.fordmods.com/ecu-fuel-system-eec-f21/ba-bf-sx-sy-scantool-fun-t25010.html".
I have my BF cluster apart at the moment and have piggybacked onto the eprom (93c56w) with a G540 chip programmer.
I have been able to flash both of the BIN's uploaded previously, onto my own cluster with success. The odometer values read correctly according to the file titles.
I have worked out that the odometer value is in the top line of code, and I think there is something in there that plays with the illumination. Trying to decode the top line to make sense of the HEX code is proving difficult though. I've been at it two nights and the only way I can get visible change is by swapping the entire top row from the BIN. I'll upload my own BIN at some stage. any ideas on translating the HEX would be a step forward I think.
Im still a little unsure what protocol fords use to communicate with everything. I know that the old ford ecus's used PWM at some stage, then upgraded to using CAN. Im unsure what the actual cluster and all other modules utilize.. I would have assumed it would be CAN!
This site shed some light on programming these units. It does look like we will be hooking up an ELM after all.. even mentions some stuff to do with odo programming with the ford global programming service:
http://www.fordmods.com/documents.php?d=37Try changing just a single byte in the first line... the last byte where you think the odo sequence ends. I imagine there will be an "algo" for us to work out.. but it would be good to start tinkering!
LangasLS wrote:Yep - I will try and get this POS BA running on the weekend for some more dumps.
Yeah, this will be a tremendous help! Even getting just 2 or 3 reads at 1km increments will make this a hell of alot easier to crack.
When Im back in Aus, ill hook the microcontroller onto the speedo line and try increment it that way
aumatt wrote:The odometer has a very unique coding process.
The eeprom contains DTC's, Serial Number (which consists of the date), the CI Number, hardware version, model number etc.
Matt
We will without a doubt smash out the algo after getting a few reads of small increments.
And for anyone wondering what is "EE Version", that is eeprom version number. Id assume.. even if the version changes, the same model cluster will till have the same "map out". Just possible have some additional features implemented.
Also, another thing, has anyone checked if the "trip" value is reset after power is removed? Or is this value also stored in the eeprom? (I am assuming the clusters have a trip value!). If the trip is stored, we will need to note down the trip distance on each dump, and also do a "clear trip" and read that value to identify where the trip value starts and see if this is incorporated in the odo calcs.