I would suspect that there may be a conflict since the AP is already going to be connected to the Canbus adding another device may not even connect.

 

As long as they're not both actively running at the same time it should be OK, otherwise its likely that there would be issues. The way UDS and OBD diagnostics works it would cause problems having two test tools trying to talk to the same ECU at the same time. Responses to one tool would be confused for responses to another. Data would likely get mixed up or never come in at all.

If the tools are just monitoring the communication then any number of tools could monitor the same traffic without issue. However, generally those devices are polling for information through diagnostics so they probably won't work right.

 

Ok, so both units cant be plugged in at the same time. Both the accessport cable and the MX can be plugged in but if you connect the AP it will never connect to the car. A message pops up saying something about trying to connect except it never does. If i exit out of Torque Pro then the AP connects and logs fine. If I then go back into Torque the AP will drop the connection.

On a side note, the low profile adapter is great. Because of its small size the white car obd2 connector can stay locked into its holder and the Y adapter seats fully and the access door still closes.

One thing i hate though atleast with the 13 model is the dang obd2 port is upside down. It makes things hard to read especially things like the MX whose 4 lights on the front all mean different things. I wonder if the car mount can be modified to make the white connector lock in right side up.

 

You can fix the upside down part. Depress the clips and rotate around and reclip.

 

@Bugasu - I acquired my secret key recently but what can be done with it? Ive read about something called mode 27 that is some kind of security mechanism built into our cars. Can you shed some light on the subject?

 

Mode 0x27 is called Security Access.
Basically an ECU is supposed to lock certain features away as secured functions.

These include flashing, reading the ROM file, adjusting certain stored parameters, etc.
Typically you enter a diagnostic session using Mode 0x10 on a module, and afterwards perform the security challenge using Mode 0x27.
Then you can go on to use Mode 0x34 & Mode 0x35 to download/upload data, or whatever else needs secured access.

Typically the requests are challenge/response based, so I'm curios as to which secret key you have.

There is also a Checksum for ECU files you may flash for example, which if it isn't correct, the car will not start. (Part of the Bosch MED17 anti-tamper functionality!)
Originally, people thought we'd end up like VW/Audi having to send our ECUs in to be bare-metal programmed because of this, but @COBB and SCT have obviously figured out how to circumvent or generate proper checksums so they can modify ECU files.

I doubt they're willing to share such secrets as there was some R&D cost and it probably wouldn't make business sense. Other modules like the BCM, IPC, etc. as far as I'm aware don't have such anti-tamper protection, but to be honest, I don't know or not. I can flash files that already exist obviously, but those have the checksums already built in correctly. Calculating new ones is not something I've tried to do, and the people who can do it don't typically share the info on how to do it, either because they work with Ford directly and are NDA'd, or because they spent all the time figuring it out and use that info to make money (rightfully so! It's an investment!).

 

If you open any VBF file you should see a plain text checksum given just before the binary section. I'm looking at v2.3 VBF files and all of the files I have have a checksum. It's not just for security but for data validity to make sure that nothing got corrupted in the flash process.

 

I did a metric ton of googling yesterday and found out I already have the needed hardware for CAN sniffing. Focccus has the ability to brute force the secret key(s). I have 2 different keys so far. Ive seen that some people use the keys for nefarious deeds and others do it just for fun or to make a little money. I want to do it because these are things ive always wanted to learn about. Im no hacker but I do like to tinker. I know it takes a long time to figure it all out, but Im into the ST for the long haul so I got time. Here are some things id like to figure out:

 

What he's doing is not hard. First he reverse engineers the CAN messages that belong to certain car functions. Then he blasts those same messages to override what the car would normally be doing. These articles and videos piss me off because it gives people the idea that their cars can be "hacked" when in each case the person hacking has physical access to the car. They give people these ideas that some man in a dark room looking at a console window can crash your car (I **** you not, see video below).

The guy in this article used to work at our company. In the video he's using the software that I help write to "hack" the car.
Hackers May Be Able to Take Control of Your Car's Computer Systems Video - ABC News

 

Not many CAN tool suppliers out there.

 

This isn't the checksum I'm speaking of, I should have been more explicit. There is that file checksum, but as far as I'm aware (and maybe Ford doesn't use it, I haven't actually tried it!), Bosch MED17 Units have a tamper protection system in place. At least supposedly according to this.

This is separate from the normal checksum, and while it's fine and dandy, it would be neat to have the method to calculate these checksums so that custom software could be written. As someone who programs full-time, but in a different field, I definitely would love to tinker around in the area.

I totally agree on the whole "hacking" crap too. It's pathetic. It's not hacking. You're just sending messages over the bus after you have gotten actual physical access to it. If you get actual physical access to a computer, you could do whatever the hell you wanted. It's sensational bullcrap, plain and simple.

I need the HEX header for im assuming the CAN header 726. Also what does the response 7F2231 mean? I thought i remember reading 7F meant error.

Anyhow im testing a PID for Charge Air cooler temp in Torque Pro. My response is coming back and im reading a result for my equation.

Im close! Ive gotta say this is kinda fun!

 

Weird...i spoke with the Forscan developers awhile back and they gave me a pid and equation but no other info to go along with it other than the answer is 1 byte long. Im trying to figure out how to enter it into torque. What is the header for the PCM?

 

7E0 is the address for the PCM.

 

7F is a negative response (most of the time). 22 is Read DID (same as OBD PID), 31 is request out of range. That usually means the particular DID you were requesting is not supported by the ECU. Sounds like you were just talking to the wrong ECU.

 

Ahh ok...i can put a pid into torque and most of the time the response is "No Response" or "no data". This time it responds with an answer to my equation. This stuff is kinda tuff. I guess if youve been doing it awhile you learn the ins and out of the different protocols.

 

It can definitely be confusing if you don't know the protocol. In our vehicles, there's quite a few protocols and techniques used over the CAN network. You have the required OBD/UDS, fit into the CAN Network. Just to get a good core understanding, you can try reading info on this:
1) How CAN sends data over the network, disregarding any protocol. This is covered in ISO11898. This is the "physical" and "data-link" layers. It governs how the electronics work and how data is sent over the network.
2) Next, what data is being sent over the network? Well, A LOT of different protocols and traffic are capable. Most (but not all!) will build on top of ISO15765-2, which defines a network layer/transport layer on top of the core CAN system. It describes ways to send more than one data packet's worth of continuous data between two devices.
3) Now we can usually get to the protocol. OBDII is in SAE J1979 / ISO15031-5. UDS is in ISO14229-1, ISO14229-2, and ISO14229-3. Both have core definitions (how does the protocol work) and also special rules for when they're used explicitly on a CAN network (UDS on CAN, OBD on CAN).

This isn't to say these aren't the only protocols used. The protocol used by your driver window module to tell the passenger window module to roll its window down will be in the CAN format, but that doesn't mean it has to use the addressing, services, or anything else like OBD or UDS. In UDS and OBD, the "header" has it's 11 or 29 bit address, but in Ford's internal protocol those might not even be listed. UDS and OBD are governed for diagnostic purposes only, but it would be silly to think that's all the traffic you'll ever see on the CAN bus, so try not to get stuck in the frame of mind that all headers are addresses, or that data always has to be a certain format, and you should be good to go!

 

Guys, that was quite a read to go through almost 60-something pages of information.

I have a small question, first I have to clarify the situation I'm having now:
- I have a 2013 Focus Titanium, European version, the version the dealer sells in dubai has the monochrome 3.5 inch screen, but the car has SYNC, Bluetooth, USB, and the works
- Bought a Sony 4.2 inch color System, installed it, all working fine except for SYNC: Blutooth, USB, voice commands
- Part number of the old screen is BM5T-18xxxxx-BE, the color one is AM5T-18xxxxx-CG, possible mismatch
- Got the ELM327 modified USB cable, Focccus, tried to load the firmware of the BM5T color screen, which is BM5T-14D358-CH
- As I expected, it is not easy, vbf fails every time, sometimes at 10%, 35%, etc..

Any advice? tips? things to try?

So far I tried with the car in ON, and another time while it is actually running.

This is the cable I got: New Black USB Modified ELM327 Elmconfig Forscan Ford Focus Mondeo Kuga s Max | eBay

Any tips or advice would be highly appreciated.

Cheers,

 

If what you are trying is even possible then ive read that updating calibrations with Elm327 type devices is incredibly wreckless due to the overwhelming amount of chinese clones with piss poor manufacturing. It is recommended to use a device that has a minimum connection speed of 1Mbps. Many clones are unable to maintain 125Kbps without drops. If you can maintain the connection it may take a VERY long time to do the upload.

The sync system is stored on the APIM so swapping screens wont give that option.

 

Will the OBDLink MX Bluetooth do the trick? did anyone try to upload firmware with it and succeeded?

Thanks

 

The problem is noone knows what the NEW fiware names are. They change to a new letter with each new update. The only people who can find out what the new letters are those with a VCM2 or have some kind of passthrough device and have a subscription to FMP. With those 2 things they can reprogram everything themselves and dont need focccus.

The russians have gotten it to work but it is hard as hell trying to translate the wording just to find out word for wword how to do the update. Plus...i think you might need the seed/key to get it to work.

 

I got another insight from the guy who sold me the cable. I'm currently running a 64Bit laptop with windows 7, he claims that it caused problems to many people before and they were able to manage with a 32 bit one.

Anyone with ideas?

 

All I run is 64 bit on windows 7 and never really have any major problems using a ELM327

 

And can you point me to the cable you used? I'm assuming you have successfully uploaded a full VBF on Focccus with that cable?

 

And can you point me to the cable you used? I'm assuming you have successfully uploaded a full VBF on Focccus with that cable?

I haven't even attempted that sorry about the confusion.

 

The STN series of chips in the OBDLink items are upgrades to the ELM. If software takes full advantage of them, they can operate faster than an ELM327.

If you wanted to try programming with one of those I'd recommend an OBDLink SX as it has a cabled connection, which is more reliable.
No matter how you look at it, it's a slow operation.

 

in searching through the thread I cannot find the EcoScout, or even what it is. any info?

 

Do you have an ST

 

Are there instructions for using this to switch headlight type to HID? Sorry, when I search the thread for "HID" it shows no results.

 

@Now534

 

Most of the functions we can do I have made a video about.

How to use FoCCCus:

 

Sorry man, ive been lazy lately about writing a new focccus post. Ive been consumed by the calibration aspects of Focccus. Ive been reading everything i can get my hands on from SAE to ISO and everything in between. Ive probably downloaded 100+pdf files lately on the subject.

 

Yes i read the recovery part, too. You have to put the HW ID in the Recovery field. Then it starts the upload different. Still didn't work.

 

Yes i read the recovery part, too. You have to put the HW ID in the Recovery field. Then it starts the upload different. Still didn't work.

View attachment 81114

Could you maybe try in Windows 7?

 

The image is my Tablet with Windows 8.1 x86 (currently connected and flashing , remote controlling because it's damn cold outside)
Tried it with a Windows 7 x64 Laptop, same result. Couldn't even handle 10%. Current state is 34%.

...

 

The image is my Tablet with Windows 8.1 x86 (currently connected and flashing , remote controlling because it's damn cold outside)
Tried it with a Windows 7 x64 Laptop, same result. Couldn't even handle 10%. Current state is 34%.

View attachment 81125

...

Your baudrate is incredibly low. Try bumping it up to 500k, 1Mbps or even 2Mbps.

 

Took me awhile to find the reference but if you are using an MX or some other device that is capable of automatically switching speeds then you can click auto and maximize speed upin initial focccus connection.
You will want to set timeout to 1ms

 

Thanks for your help! I will try it later with these settings and report.

 

I very recently am unable to connect via MSCAN. Forscan and Focccus cant see any modules on that bus. Ive dont multiple resets to the device and nothing fixes it.

 

Current state:

I did the ELMconfig setup to set for testing 500kb/s

FOCCCus settings set, made it to 76%

Just noticed the ignition turned of so that might be the problem... Car was in test mode and key inside the car (keyless)

 

Wow these adapters sound like a frekin joke man. 15-30 minutes is soooo slow. I'm almost certain we were flashing the BCM in about 5-8 min. Their delay between flash messages must be pretty bad. I'm assuming that's why these things fail randomly. Its too bad this app isn't J2534 compatible. Can this thing generate a VBF file to flash with the new settings via a different app? That would be awesome.

 

He is testing 500k. The ffclub.ru(focccus forum) uses a device that they make/sell exclusively called an ELS27. It uses a 2Mbit rate for the RS232 connection. They recommend nothing under that for connecting. The MX on the otherhand I beleive is capable of a 10Mbit connection. The speeds can and will get faster as we learn proper setup procedures.

As to the generation of a vbf file, im not so sure. Yesterday they were talking about loading a non standard VBF file but with no mention of what program generates the vbf. They also mentioned that that they were able to make changes to existing vbf in order to implement new features. One such feature is things like Track Title and artist names in the in IPC screen and speedo gauge digital display.

 

• STPBR baud Set OBD protocol baud rate. No error when a baud rate is not supported – will generate closest possible; use STPRBR to check.
• STPBRR Report current OBD protocol baud rate

Things gettin intressting, BUT i just saw something which might explain everything.

HS CAN is 500kbps, 31 - HS CAN (ISO 11898, 11-bit Tx, 500kbps, var DLC) for example.

MS CAN (FCDIM Module is on that bus) communicates with 125kbps only

I will do some research to handle the commands with focccus.

Edit:
This also means everything above 500kbps should be useless as the bus can only handle this i guess?

 

Something is really messed up. Brain hurts :smile:

Basically 1 Baud = 1 Bit at a serial connection.

Max MS CAN-Bus speed is 125kbps, would be 125000bit


Firmware AM5T-14D358-CH.vbf got ~1MB (1034292Bytes)

1034292*8/125000= 66,194688 sec


Is this correct?

 

Something is really messed up. Brain hurts [emoji2]

Basically 1 Baud = 1 Bit at a serial connection.

Max MS CAN-Bus speed is 125kbps, would be 125000bit


Firmware AM5T-14D358-CH.vbf got ~1MB (1034292Bytes)

1034292*8/125000= 66,194688 sec


Is this correct?

No. You're not taking into account any latency or protocol overhead.