for anyone else who wants to use the data in my last post,


USER BEWARE!!! this only changes the MUT table to use some unused space to report the calulated load.

Above are the only known free spaces for different ROM images. Use this at your own risk

 

I thought that those xml entries are the MUT lookup table in the rom, these values point to Memory addresses that are contain values while the ECU is running, and we are just changing the RequestIDs 00 and 01 to look at different memory addresses, (hopefully looking at actual LOAD values) and these memory addresses and MUT lookup table addresses are different for each rom/ecu.

 

correct. We are pointing to what we think is the correct load value. It works pretty well, so far there have not been any problems with using these request ids.

 

Hi

Ok, for those of us to lazy/thick/can be arsed to get the 2 byte thing working. What is the variation between the timing logged, against values in the ROM to work out your load cell, compared to the 2 byte method.

I've been going for checking the timing, and then adjusting the cells adjacent to this load cell. The load cell nearly always corisponds to the boost level from my GM MAP in ECU+.

MB

 

The lame answer is.. It depends.. So far the 2 byte load hack, which is just reallocating 2 existing requestID's (not the way we ultimately want to do this)
Its pretty accurate as its the actual memory location for the load used for reference in the ECU, at least on 94170008.

Unfortunately, I have a unique problem in that making this modification isn't always an option given I work with different Rom versions, Different ECU's, and in reality, altering that value (along with the baud rate mod) may affect the ability to correctly perform diagnostics when the car is at the dealer. I don't worry about this on my car, but its a concern if your tuning other cars that are still under warranty. The last thing you want to do is raise a red flag or let them think they might have a corrupt rom.

I use both the calculated load (which is off about 5% on my car) and Timing to find the correct cells I also added an additional "Error correction" parameter that allowed me to make some error correction changes to get the ECU (1C load) at low loads to match the Calculated load, in doing that, I can then accurately use the calculated load after a run or two to find the "Error %" on a car.

Specifically on my car, I also have the 2 byte (2 request) load logged too as I can test the error correction and correlation to see how off it really is before I release it as part of the new version of Mitsulogger.

At the moment, development of new mods is pretty stagnent, basically its only 2 people working on it, and one is recovering from a huge loss, and I don't have the time to participate in the disassembly. But its getting there.

 

I have plenty of logs that I can show, let me get the laptop plugged in and I will post some logs that demonstrate the different load calc results.

 

Not really that lame, not when it's the truth! I shouldn't be so lame in not looking into it properly.

Anyhow I've been doning a bit of backwards math ( I know there's a proper term
like transposition, but whatever). on the formula in Mistilogger, the constant in this expresion in 5* if I look at my timing and get an approx load cell my constant is 4.5, this may sugest the constant isn't a constant and a function of some other variables.

Interstingly in the UK we have had very high barometric pressure, about 1045 mB, low air temps, 32 to 40 F and very high humidity, 99% I remeber reading here that some of these might form part of the load equation. Any ideas anyone?

MB

 

I think there is some more data on this that will turn up shortly.. Its just taking awhile to get verified..

 

MJ: I hope this isn't off topic, but I figure you are the one to ask. For the open source cable tools control I just altered the MUT class (by request) to support the non standard, higher baud rate. At the same time, I put in a little back door mechanism so that you can make non standard requests.

The generic 'id' of a CableTool request is a long, but in MUT the typical requests are bytes. So I used the MSB of the id for a back door hack.

0x00000000 initiates a request of 00 and expect a byte response.
0x01000000 initiates a request of 00 and a request of 01 and assembles the two responses into a UINT16 (MSB first).
0x02000000 and 0x03000000 extend this for a third and forth byte (UINT24 and UINT32) respectively.
0x10000000 initiates a request of 00, but expects a non standard two byte (UINT16) response (MSB)
0x20000000 and 0x30000000 are similiar, expecting non standard three and four byte (UINT24 aund UINT32) responses (MSB).

Before I check this version in I wanted to ask if these two mechanisms (sequential requests assembled into MSB UINT results and support for non standard 2, 3, and 4 byte responses (again MSB UINT results)) covered the basic hacks people are using.

Second, for high speed MUT hacks should I support variable rates, or is the 60+ Kbaud speed the only one in wide use?

Thanks
-jjf

 

Okay.. Here's all the info I have currently on the developments..

Mut Protocol standard is a single byte request, with a 2 byte response, first byte is an echo of the request, second byte is the response.

The enhanced protocol that Bez and the rest of us have been talking about are a single byte request, and a 3 byte response, again, the response is 1 byte of echo, and the MSB/LSB data for a word response.

Ultimately that mode (and those mods in general) use a single request byte, and the response is 1 or 2 bytes of data after the echo. This was done specifically so those interested in patching the rom, could potentially patch it to replace an existing request with a full range response.

There is also another protocol that we have been discussing for Enhanced MUT, which consists of a 3 byte request, and a 3 byte response, basically equivalent to the old "Peek / Poke" functions, where two unused requests are reallocated, you place the request.

The peek function, which is one of the requestID followed by the 2 bytes for the address in memory you want to retrieve, the response is the echo of the request, and the value of the word in that memory location. As you can see, the conversation consists of 6 bytes (3 request and 3 response) and therefore can slow things down to OBD-II speeds.

The Poke function is likely even longer as it has to make a request, a location, and a value, and the response should be an echo of the value to make sure it wrote correctly to shared memory. This is the basis of live tuning BTW.

UNFORTUNATELY, as these new enhancements start arriving, you'll notice the serial speed needs to be increased. Currently we have the memory location for the baud rates, and it can be set to whatever you want, so its important that the software be capable of manually setting the speed, as if the rom is altered, the diagnostic tool (MUT) will only communicate at that speed, if the user has an option for nonstandard rates that the PC and ECU supports, its statistically possible that someone might use it.

FWIW, the higher logging rates don't seem to provide more information when using standard MUT requests, as the resolution of the values is reduced to fit into 1 byte, and therefore you just end up with repeating values and more resulting data, this happens in the current log speed now, a good example is engine speed (RPM) as although at 16 bits its accurately measured, when its converted to 8 bit output, and then converted back with the formula, the sweep through the RPM step is lost.

Where the faster logging will excel is in the enhanced requests and live tuning, where there is larger conversations happening consisting of enough data that would slow the stock baud rate down to a sample rate similar to OBD-II where you'd only get a few samples per second.

I implemented all of this in Mitsulogger (except the peek/poke protocol as it hasn't been firmly documented by anyone officially researching its feasability)

This is completely different than the current 2 byte load and airflow mods, as they reallocate 1 requestID per byte, so 2 byte load requires 2 different requests, and the individual responses are then put back together. This is different, and requires nothing more than some simple modifications and some math on the logger to put the MSB and LSB back together.

 

Thanks. I omitted the echos from my post since they are really K line hardware related.

It sounds like I've got almost all the cases covered. I'll use one more bit to support the generic peek scheme (leaving the actual request and address to be the bottom three bytes of my protocol independant 'ids'), and make the baud rate for all protocols programatically over rideable in the control.

I think I'll leave out any support for 'poke' for now. Once people start moving maps to RAM and dynamically adjusting them a value by value protocol may need to be rethought.

Thanks again,
-jjf

 

On an offtopic note, the reason the poke method works, is your only making a few small changes at a time, as the unchanged data won't be updated.. The resulting map wouldn't be loaded into memory, but flashed perminently later.

But I understand not supporting this yet simply because we havent written code to do it. It may make more sense to do block writes, but I am just the guy developing the interfaces and programs for the PC, the ROM hacks are a group contributed effort on aktivematrix.com

 

jjf,

Using your method above, what ID value would I configure the protocols.xml file with to log request 2C and 2D, to be assembled into a 16 bit number? Actually, I think the MSB (2C) contains 3 bits and the LSB (2D) contains 8 bits, but that shouldn't matter, right, seeing that the first 3 bits will just be 0?


Thanks,
Eric

 

0x0100002C. This would tell the protocol handler to make two byte requests (2c and an 'extra' at 2D, then assemble them into a unsigned 16 bit word (no problem if the top bits are 0).

The Enginuity SVN server seemed to be down (or at least very sluggish) last night, so I'll be checking in the changes described above later today (probably this evening). At that point, the built control and test will update as well. So you could just download it and the LogWorks plug-in, which uses the same control, would pick up the new ability (you would put in the protocol XML line with # (#0100002C) not 0x for the LogWorks plug-in).

The LogWorks installer will be updating early in the week. There are a couple of new plugins (by request). At that time, the updated control will be included with it as well.

I hope the above is clear!
-jjf

 

Finally got a chance to try out the 2 byte load and compare it to calculated load. Turns out that calculated load seems to diverge away from actual load at the highest load values. Not too far off at the lower load values. Anyhow, 2 byte load is pretty easy to log. Thanks again.