ECUFlash - Getting close!

[FrX]

You can obtain a copy of the J2534 spec here:

https://law.resource.org/pub/us/cfr/...j2534.2002.pdf

You would probably be surprised how little difference there is between, say an EcuTek cable and one of the Chinese Clone MVCI cables.

The EcuTek cables (and the Ross-Tech and Bavarian Technic) are all made my a company called Sensolutions. They include an Atmel MCU, FTDI USB controller, and a set of the Microchip CAN controller and transceiver pair.

The Chinese MVCI cables contain an NXP LPC MCU with a built-in CAN controller, an FTDI USB controller and a CAN transceiver.

Theoretically the Chinese clone cables are perfectly capable of the speeds any of the other hardware gives you. However, the software and firmware they provide is buggy and does not fully meet the J2534 spec. Only a bare minimum of the API is provided. Not to mention that it is stolen/cloned from a previously legitimate source who has since stopped development. You are not going to see any bug fixes or help for your problems, ever.

One interesting aspect of the Chinese cables is that the reset and ISP programming pins are connected correctly to the FTDI chip. You can successfully have the device enter the ISP mode and respond to queries. The current firmware is protected, but it may be possible to overwrite it with your own. I have not tried that yet, though.

In regards to working with your own hardware, which is appealing because all the current players are full of lock-down, I like the new TI Stellaris/Tiva chips. They include both USB and CAN on-board (still need the transceiver IC, a Microchip MCP2551 or NXP TJA1051 work well). They also have 4 UART controllers, so you can tap into both K-Line ports too. The Launchpad is a nice development platform, too.

[nelsmar]

Originally Posted by xjohnx

Pardon my ignorance, but what kind of things could you make with this?

Thats an open question with an open answer.

The answer? Whatever you want!

I need a little more info as to what you are looking for lol. Are you asking what i personally can make using one? what i am going to make? what the application of one of the ARM based cpu's is? I just don't fully know what kind of answer you are looking for.

[xjohnx]

Originally Posted by nelsmar

Thats an open question with an open answer.

The answer? Whatever you want!

I need a little more info as to what you are looking for lol. Are you asking what i personally can make using one? what i am going to make? what the application of one of the ARM based cpu's is? I just don't fully know what kind of answer you are looking for.

I was mainly wondering what you planned on making with it. Also wondering if it could be used somehow to simulate the pedal dance for track cars.

[FrX]

Originally Posted by xjohnx

I was mainly wondering what you planned on making with it. Also wondering if it could be used somehow to simulate the pedal dance for track cars.

If the information necessary to enable it is transmitted via the can bus, and you figure out what specifically need to be transmitted, sure. Note that the OBD plug is not a direct line to most of the car's can bus, and is firewalled somewhat behind a controller/router. The parts of the car you need to talk to may be behind this firewall.

[nelsmar]

Originally Posted by FrX

If the information necessary to enable it is transmitted via the can bus, and you figure out what specifically need to be transmitted, sure. Note that the OBD plug is not a direct line to most of the car's can bus, and is firewalled somewhat behind a controller/router. The parts of the car you need to talk to may be behind this firewall.

^^^ this is correct.

Originally Posted by xjohnx

I was mainly wondering what you planned on making with it. Also wondering if it could be used somehow to simulate the pedal dance for track cars.

Luckily our cars have SSM... which has a lot of functionality of reading / writing to memory. I don't know (as i haven't tested) what is actually permitted at this time for sending. Yes it is 100% possible to do something by re-writing memory to make the ECU think that events are happening. However it may require a patch to the ecu and re-require reflashing for all I know. I am actually new to this stuff but this is in the ballpark of what I do for a living so trying to catch up isn't taking me to long. Hell a few weeks ago I had no idea what the hell SSM was, or any of these protocols, or how the port even functioned and now I have some hardware fitted and am working on attempting to communicate with the ecu.






I am personally building a hardware datalogger. Basically take the idea of Torque, P3 gauge, and the tactrix cable and put them all in a blender. I am using a small LCD/OLED that as of current is going in my driver side vent, however I may relocate to mirror, or above my steering wheel. The idea is to allow you to configure the values you want to log, and a refresh rate.

This will act like a flight recorder for the event of catastrophic engine failure, mechanical issues etc. Anything that goes wrong i can simply hit a button and it will flag that moment in the log. Logs will rotate and run indefinitely. So say my car is sputtering? great! tap the button for flagging and it will add a flag in the log it writes to the SD card. Then when i get home i can pull the SD card, throw it in my computer and look at what was going on in the ecu.

Also tied with this is a small display that will show data that I feel is relevant to me. As of current the concept is showing AFR + a small 1-5 second graph with it showing AFR over the last few seconds (to visually see spikes), knock feedback, boost, ethanol reading, and warnings.

The idea of warnings is say my oil temps hit a certain temperature? the screen will flash + a red led (which will be programable) and one of the gauges that are lower priory will be swapped out for oil temps so i can monitor. I also plan on adding a few input/output connections for 0-5v input, and whatever for output for say an intercooler sprayer.





I was tired of dealing with using my laptop day to day to check things. And then when something goes wrong i have to pull it out and i cant re-produce it. I also have a P3 gauge and its great and all but it shows one thing at a time, and i would really like to see my AFR, OIL, and knock feed back (which it doesn't even have!!) all in one place at the same time. I hate when going on spirited drives i have to shut off my AFR to see my oil temps to make sure I'm not getting things crazy warm.

So that is the basic sum of the goal of my project, hopefully i can get caught up at this project I am behind on at work so I can push lots of effort into this. At first it will be basic and just display minor bits, then logging, then ill work up and make the UI a little better and work towards input/output + easy ways to config.

I planned on starting with a small processor in an easy to use platform to start, and if i start running out of headroom I can easily port my code over to a PIC/ARM cpu that is faster to handle things. I'll know pretty quickly what this little 16mhz amtel can do here soon.

[ft_sjo]

An AVR can run an entire engine reasonably well so I'm sure it'll handle a bit of data logging just fine, as long as your code isn't shit.

[xjohnx]

Originally Posted by nelsmar

^^^ this is correct.



Luckily our cars have SSM... which has a lot of functionality of reading / writing to memory. I don't know (as i haven't tested) what is actually permitted at this time for sending. Yes it is 100% possible to do something by re-writing memory to make the ECU think that events are happening. However it may require a patch to the ecu and re-require reflashing for all I know. I am actually new to this stuff but this is in the ballpark of what I do for a living so trying to catch up isn't taking me to long. Hell a few weeks ago I had no idea what the hell SSM was, or any of these protocols, or how the port even functioned and now I have some hardware fitted and am working on attempting to communicate with the ecu.






I am personally building a hardware datalogger. Basically take the idea of Torque, P3 gauge, and the tactrix cable and put them all in a blender. I am using a small LCD/OLED that as of current is going in my driver side vent, however I may relocate to mirror, or above my steering wheel. The idea is to allow you to configure the values you want to log, and a refresh rate.

This will act like a flight recorder for the event of catastrophic engine failure, mechanical issues etc. Anything that goes wrong i can simply hit a button and it will flag that moment in the log. Logs will rotate and run indefinitely. So say my car is sputtering? great! tap the button for flagging and it will add a flag in the log it writes to the SD card. Then when i get home i can pull the SD card, throw it in my computer and look at what was going on in the ecu.

Also tied with this is a small display that will show data that I feel is relevant to me. As of current the concept is showing AFR + a small 1-5 second graph with it showing AFR over the last few seconds (to visually see spikes), knock feedback, boost, ethanol reading, and warnings.

The idea of warnings is say my oil temps hit a certain temperature? the screen will flash + a red led (which will be programable) and one of the gauges that are lower priory will be swapped out for oil temps so i can monitor. I also plan on adding a few input/output connections for 0-5v input, and whatever for output for say an intercooler sprayer.





I was tired of dealing with using my laptop day to day to check things. And then when something goes wrong i have to pull it out and i cant re-produce it. I also have a P3 gauge and its great and all but it shows one thing at a time, and i would really like to see my AFR, OIL, and knock feed back (which it doesn't even have!!) all in one place at the same time. I hate when going on spirited drives i have to shut off my AFR to see my oil temps to make sure I'm not getting things crazy warm.

So that is the basic sum of the goal of my project, hopefully i can get caught up at this project I am behind on at work so I can push lots of effort into this. At first it will be basic and just display minor bits, then logging, then ill work up and make the UI a little better and work towards input/output + easy ways to config.

I planned on starting with a small processor in an easy to use platform to start, and if i start running out of headroom I can easily port my code over to a PIC/ARM cpu that is faster to handle things. I'll know pretty quickly what this little 16mhz amtel can do here soon.

sounds awesome. If you ever sold something like that, I might be interested in buying one.

I'm assuming when you press the "event" button it could be configured to also flag/save the data logged prior to the button push (say you push the button to log an event, it could be preconfigured to flag and save that entire trips log (since the last engine startup), or maybe flag/save X number of minutes that preceded the event button push, too?

[Td-d]

Originally Posted by nelsmar

This will act like a flight recorder for the event of catastrophic engine failure, mechanical issues etc. Anything that goes wrong i can simply hit a button and it will flag that moment in the log. Logs will rotate and run indefinitely. So say my car is sputtering? great! tap the button for flagging and it will add a flag in the log it writes to the SD card. Then when i get home i can pull the SD card, throw it in my computer and look at what was going on in the ecu.

That's incredibly useful - I ran the onboard SD logging on the OP2 basically permanently, and with CAN logging, you could run literally up to 40 parameters without polling rate degradation. I always had logs when shit happened that I wanted to analyse The main downside is that the OP2 is not capable of timestamping - so your proposed device would be immensely useful.

[AdrianG]

Originally Posted by Td-d

That's incredibly useful - I ran the onboard SD logging on the OP2 basically permanently, and with CAN logging, you could run literally up to 40 parameters without polling rate degradation. I always had logs when shit happened that I wanted to analyse The main downside is that the OP2 is not capable of timestamping - so your proposed device would be immensely useful.

Is the OP2 able to log for the BRZ yet?

- AdrianG

[Td-d]

Originally Posted by AdrianG

Is the OP2 able to log for the BRZ yet?

- AdrianG

Not yet, no. This was on my STI.

[nelsmar]

Originally Posted by ft_sjo

An AVR can run an entire engine reasonably well so I'm sure it'll handle a bit of data logging just fine, as long as your code isn't shit.

Exactly. And running a display w/o a buffer on the display is where most of my resources have been going as of current. Which isn't a huge deal.

Originally Posted by xjohnx

sounds awesome. If you ever sold something like that, I might be interested in buying one.

I'm assuming when you press the "event" button it could be configured to also flag/save the data logged prior to the button push (say you push the button to log an event, it could be preconfigured to flag and save that entire trips log (since the last engine startup), or maybe flag/save X number of minutes that preceded the event button push, too?

Currently I just planned on making it log indefinitely. Hitting the button would just add a "1" or something in a column of the log file, and move it to a flagged folder.

Originally Posted by Td-d

That's incredibly useful - I ran the onboard SD logging on the OP2 basically permanently, and with CAN logging, you could run literally up to 40 parameters without polling rate degradation. I always had logs when shit happened that I wanted to analyse The main downside is that the OP2 is not capable of timestamping - so your proposed device would be immensely useful.

Yeah... dying to have this -.- And no timestamp?! EEP! I have never used OP2 personally, so I don't know a ton about it. I need to find someone that has a cable locally that I can mess with. The slowest part of dev is well other than my job killing me lately... is testing things w/o having a basis to compare to.

[FrX]

One of the items you can poll over SSM is the status of stuff like the defrost and cruise switches. If you want to make a note of something in particular happening to the car in the logs, you could easily add a logged channel for the switch.

[stugray]

Originally Posted by FrX

One of the items you can poll over SSM is the status of stuff like the defrost and cruise switches. If you want to make a note of something in particular happening to the car in the logs, you could easily add a logged channel for the switch.

The datalogging feature of the OP2.0 defaults to start logging at "defrost on".

[Td-d]

Originally Posted by stugray

The datalogging feature of the OP2.0 defaults to start logging at "defrost on".

Yup, but you can practically set up the logcfg.txt file to trigger on any scenario you want - like for WOT runs, I would set it up to trigger above a certain RPM, and close above another RPM.