grayw

I'm going to have a test on the X again tomorrow, I've asked Sean the guy who wrote it to see if he can add the adjustable baud rate.

CLaNZeR

Hi

Just posted this over in reply to mrfred:

*******

I think the OP2.0 in future firmware upgrades is going to allow control of shorting Pin 1 to GND via software, but at the moment I have not found the command or it has not been implemented.

So you have two choices, either pop the clear case off the OP2.0 by using a screw driver and solder a wire, maybe with a switch! to pins 1 and 4.

Or get behind your vehicles OBD-II connector with a Paperclip and short 1-4 out.

Bit of a pain and to tell you the truth, with the speed the OP2.0 logs at, I dunno if it worth it, better to build a cheap cable and have two seperate cables.

I have been playing with the OP2.0 all day today too see if I can speed up the requests, but no joy so far.
********

CLaNZeR

Interesting that your firmware is reporting version 1.02.2232 as the OP2.0 I have here is Version 1.01.2145.

I take it the lastest version of ECUflash updates the firmware, will try and update cable firmware I have here and see if it upgrades to the same version you have.

Did you short out Pins 1+4 on the OBD-II Connector, as this is needed.

Cheers

Sean.

CLaNZeR

Hi GrayW

The standard baud rate for the MUT protocol is 15625 Baud. So if using a normal Serial OBD-II cable or a FTDI, we simply set the software to communicate at this rate, send the Request ID's and get replies.

With the OP2.0 it is different as the OP2.0 is actually a middle man as such using Pass Through Programming.

So our communication with the OP2.0 will always be at 38400 Baud.

We send the Connect command and tell it to use ISO 9141-2 as it is the closest to the MUT Protocol ( The difference is the byte sent in the 5 baud Init).
During the Connect command we tell the OP2.0 what Baud rate we want it to communicate with the ECU at and this is where we tell it 15625 Baud.

So now the setup is we Communicate like this:

PC > OP2.0 at 38400 Baud.
OP2.0 > ECU at 15625 Baud.
ECU < OP2.0 at 15625 Baud.
OP2.0 > PC at 38400 baud.

Packets out PC > OP2.0 > ECU
Packets back ECU > OP2.0 > PC

The slowness is down to the amount of bytes we have to send to the OP2.0 just to get it to send 1 byte to the ECU.

There has got to be more commands, just need time to suss it

Cheers

Sean.

grayw

Sean,

There software updates the firmware version, so there will be a few different ones depending on what version of the software you are running, mine is 1.03.2304

CLaNZeR

I have downloaded ECUflash 1.40 and still cannot see a option for updating firmware.

Can read my EVO6 Bench ECU with Version 1.40 with it and it reports Firmware 1.01.2145 but does not seem to attempt to update it.

grayw

I'm not 100% sure what the current released firmware version is for 1.40.2178, some of these guys will be using beta versions, so yours could well be upto date.

mrfred

iTrader: (50)

Indeed, the latest firmware update is in a closed beta of ECUFlash. It would be great to get you talking with Colby about what can be done with OP2 to provide pin shorting capability and improve passthrough speed. Have you tried PMing him on forums.openecu.org?

CLaNZeR

Dunno if he will really like that seeing I am ripping the sh*t out of his adapter to see what he has done with it and how it works.

I thought the circuit for raising the 16+ volts on the Init Adapter circuit was built into the Flash adapter (Due to it's weight), but metering it out directly on the OP2.0 circuit board seems that the 16+ volts is there without the adapter and just proved it by slinging the flash adapter to one side and connecting the Boot Init line from ECU directly to the OP2.0 circuit board, Worked just as well.

I can see where he gets his speed for Reading and writing to the ECU, some of the packets coming back are nice at 100 bytes a packet.
But then his firmware is probably taking care of the commands to request data out of the ECU and spitting it back in nice long packets to the PC.

Not really interested at the moment in sorting out the ECU Write/Read stuff as conentrating on the monitoring/logging, so will drop him a mail.

downforceinc

So I'm guessing, out of the box this data logger doesn't work with the OP2 cable.

Also I thought PCMScan was already working with OP2 and the Evo X....just not free though.

xbox4414

iTrader: (2)

Dam I was hoping for promising results. So if we do ground the pins, with al the slowness does it still make for a good data logger to tune to. Is it slow in live time results or what?

CLaNZeR

PCMScan works with the OP2.0 using the Pass Through Protocol but only with OBD-II ISO 9141-2 Protocol and not Mitsubishi's MUT Protocol.

So good if you want general stuff that 100's of OBD-II programs and cables will do for you at a cheap price, but not so good if you want to monitor/log Mitsubishi specific stuff like Knock count.

CLaNZeR

Just improved the speed a little for Version 1.6 which I will be releasing in the next couple of days.

It all depends on what you want to Log.

There are 45 Request ID's, not all the calculations are complete yet as a work in progress.

But for example say we wanted to monitor 5 different things , then we log at about 3 times a second and write to log file for OP2.0.

Using normal Serial Port Cable or FTDI cable then we get about 11 times a second.

Depends how many request ID's you want to log at the same time.

How many you expecting to log when tuning?

xbox4414

iTrader: (2)

Okay what about support for a WB O2? Will we be able to hook up say a UEGO via serial?

CLaNZeR

No Wideband support at the moment.

As I said a work in progress and this software has only been in development for nearly 3 weeks with 5 releases as we discover more.

If you want all the bells and whistles then a commercial program is probably better for now, if you can find one that works with the OP 2.0