NefMoto

Does the ECU hardware or software? If software, does the flash code specific which protocol? If so, why can we just modify the flash of the KWP1281 ecus to allow use of KWP2000?

Thanks,
Rey

It is the flash software the controls which protocols are supported. I don't believe the older ECUs contain the code necessary to run the newer KWP2000 protocol.

It would be nice to see if that code could be added to the older ecus since we're modifying the flash anyway.

Which specific ecus are you talking about? Is it an ecu type different of ME7.1/ME7.5 where
you want to add KWP2000?
If it is an ME7.1/ME7.5, you could provide the binary so I can have a look into it.

VW GOLF/JETTA 1.8T AWP 180HP 06A906032PL (http://www.nefariousmotorsports.com/forum/index.php?topic=238.0title=)

This image definitely contains the protocol implementation for KWP2000. If you can't
connect to this ECU using KWP2000, it can be a problem of used communication parameters.
The image supports fastinit to address 0x10(physical) or slow init to address 0x11,
the following communication should use address 0x10(physical) or headermode 0 (none).
Or something on the K-line in the car gets in the way (like the strange behaviour I face in
my car). In this case you could try with a separate K-line wire only from ECU to the tester
or on the bench.

Really? What about this slightly earlier one?:

NORTH AMERICAN GOLF/JETTA 1.8T 06A906032LP 0261207955 (http://www.ecuconnections.com/forum/viewtopic.php?f=41&t=4868)

And this one only had the kwp1281 code, could you copy the kwp2000 code from the first one to this one?

The NefMoto software only uses address 0x01 for fast init with KWP2000, and addresses 0x01 and 0x11 for slow init KWP1281. Adding support for different connection addresses is on the list for future versions.

I'm more interested in getting vagcom to connect and log with kwp2000 for higher sample rates. Can the addresses be moved around in the flash to facilitate this and nefmoto's flash software?

As far as I know, VAG-COM only supports data logging with the KWP1281 protocol.

You could try to manually connect to address 0x11 in VAG-COM though and see what happens.

I didn't know vagcom had an option to manually connect to an address. Do you have more info on this?

This one also has KWP2000 protocol inside and communicates using the same addresses
as the first one.

Regarding VCDS with KWP2000: I don't think it is a problem of the addresses supported
in the image, but you can try to set something under "Options -> TST Addr" in VCDS.
What VCDS needs to log data using KWP2000 (Turbo! button) is an intelligent cable
(not dumb one) and the readDataByLocalId service for id's 00-9F. The images you refered
to do not support this service. In general, I did not find many ME7 supporting this, so I
believe that we can log ME7 with VCDS in KWP2000-Mode only for very few ecu's.

Does this mean that Tony's logging software will be similarly restricted to very few ECU's? Tony?

No, this will not be restricted the same way.
VCDS work only with an official logging interface where you specify a group number and
get defined measurement values in return. This official interface exists in general for
KWP1285, but only on a limited number of ecus for KWP2000.
If you read out variables directly from ecu's memory and do the conversion to physical
values yourself, you can log almost any ME7 with kwp2000 protocol (like EcuX).
But the prerequisite is: you must know which variable is located at which memory
address and how to convert from internal to physical values. And this can differ between
the various ecu images.

So, how hard would it be to 'add' this needed service to the ME7 ecus?

Also, what few ME7 ECUs are you referring to that have the needed service?

Thanks,
Rey

Or....

can we modify the flash to allow a higher baud rate via kwp1281?

'Adding' this would be not impossible but really hard. Too hard compared to the gain.
Still no high performance logging with this method, since you can log only 8 variables per
logging request and the ecu has to do the whole data conversion itself, which is quite a lot
of instructions to perform for each log request.

So far I saw these two images with support for readDBLI:
EPK = 40/1/ME7.5/3/4016.31//24E/Dst06o/071002//
- '0261207931'         (SSECUHN)   
- '1037366920'         (SSECUSN)     
- '4B0906018DA '       (VAG part number)
- '0006'               (VAG sw number)     
               
EPK = 40/1/ME7.5/5/4016.32//24E/Dst02o/180902//
- '0261207941'         (SSECUHN)   
- '1037366871'         (SSECUSN)   
- '8E0909518AH '       (VAG part number)
- '0002'               (VAG sw number)   
   
Raising the baud rate could be relatively easy implemented, but the gain would be nearly zero.
The kwp1281 protocol requests echo bytes to be sent by the communication
partner for each transmitted byte, so the "round-trip-time" is limiting. This is mostly
defined by the time slices the ecu uses for processing data, which is 10ms,
the baud rate is not the limiting factor here. Plus you get only four variables per log request.

KWP1281 sucks because bytes are sent one at a time by the ECU, and the next byte is not sent until the tester sends back an echo byte. KWP2000 is awesome because you can send messages up to 255 bytes long and then send a positive response at the end. This is the main reason why KWP2000 can run so much faster.

Every ME7 ECU I have looked at does not support the KWP2000 local or global identifiers for reading sensors by ID. What this means is that although the KWP2000 protocol supports reading values by ID, none of the ME7 ECUs implement any IDs, so you can't use this system. To read sensor values over KWP2000 on the ME7 you have to read values by memory address. When you read values by memory address you also need to do the conversion from raw values to actual values yourself. To read sensor values with KWP2000 on the ME7 you will therefore need a memory layout of where all the values are, and you will need the conversion functions for each value type, and then you will need to read these values by address. This is the way ECUx works, and it is the same way the unreleased NefMoto data logger works.

On the screen where you choose which component to connect to, ie engine, instrument, etc, there is a field at the bottom that allows you to manually enter a component address. Try entering 0x11 in there.

This may allow you to start a KWP2000 session with the ECU, but I doubt you will be able to do anything more at this point.

Awesome info! Thanks. I tried connecting to address 11 via VCDS with no luck.

So, what about just dumping one of those two bins onto my ecu and recalibrate any maps that need to be adjusted for my hardware?

I'm only looking to get ~7-10 samples per sec when logging 3 groups. Anything more is just a bonus.

I tried a friend's ECUx with no luck either. It would connect and begin logging, but none of the values would change. Everything was static. I assume the mem map was wrong.
I used the property file that listed my ECU part number, and even others that seemed similar.

May I ask how you can tell if an ECU has support for readDBLI by looking at the bin?

Thanks,
Rey

I was running the bins in my simulation and could see that the ecu responds
to a readDBLI request. It seems like the ecus supporting this service do no longer
support the KWP1285 protocol. At least the entry to initialize the communication
session for this protocol is missing for the images where I found readDBLI support.

Ah. you're hitting it with requests and monitoring reqponses. I thought maybe you could recognize the code by looking at the raw hex.

I had the same problem with ECUx. It wasn't the properties file it was the settings.
These settings did it for me. I have my cable set to port 2.

Port: 2
Baud rate: 14400

Try disconnecting cluster fuse, ECUX doesn't work for me at all unless I disconnect cluster.