PDA

View Full Version : MEFI 4 ECM definition file



blazerdude
September 14th, 2006, 06:36 PM
I am trying to create a definition file for an ECM that is not on your list. The data stream I am working with is an 8192 baud stream from a Delphi MEFI 4 controller running on a sand rail with a Corvette LS6 engine on it. I was able to see what looked like proper chatter from EFILive V4 using the GM274, GM163, and 95 Pontiac vin K definition files, but the charts and graphs had meaningless data in them. The other definition files did not seem to allow any useful chatter to be seen.

I logged some data with Carbytes V2 using the Holden_VS_V8.ald definition file (the Lotus_Carlton one did not seem to provide any data). The first part of the log file from Carbytes V2 looks like this:

15:40:08.804,66,98,0,0,0,0,90,128,0,0,118,0,135,7, 16,110
15:40:09.204,66,98,0,0,0,0,90,128,0,0,118,0,136,7, 16,109
15:40:09.214,240,86,244,198
15:40:09.224,66,98,0,0,0,0,90,128,0,0,118,1,137,7, 16,107
15:40:09.234,66,98,0,0,0,0,90,128,0,0,118,255,138, 7,16,108
15:40:09.274,240,86,244,198
15:40:09.314,66,98,0,0,0,0,90,128,0,0,118,0,133,7, 16,112
15:40:09.424,
15:40:09.434,66,98,0,0,0,0,90,128,0,0,118,167,134, 7,16,200
15:40:09.525,240,86,244,198
15:40:09.565,66,98,0,0,0,0,90,128,0,0,118,0,135,7, 16,110
15:40:09.675,
15:40:09.695,66,98,0,0,0,0,90,128,0,0,118,0,136,7, 16,109
15:40:09.775,240,86,244,198
15:40:09.815,66,98,0,0,0,0,90,128,0,0,118,1,137,7, 16,107
15:40:09.935,
15:40:09.945,66,98,0,0,0,0,90,128,0,0,118,255,138, 7,16,108
15:40:10.035,240,86,244,198
15:40:10.075,66,98,0,0,0,0,90,128,0,0,118,0,133,7, 16,112
15:40:10.186,
15:40:10.196,66,98,0,0,0,0,90,128,0,0,118,167,134, 7,16,200
15:40:10.286,240,86,244,198
15:40:10.326,66,98,0,0,0,0,90,128,0,0,118,0,135,7, 16,110
15:40:10.446,
15:40:10.456,66,98,0,0,0,0,90,128,0,0,118,0,136,7, 16,109
15:40:10.536,240,86,244,198
15:40:10.576,66,98,0,0,0,0,90,128,0,0,118,1,137,7, 16,107
15:40:10.696,

I am really at a lose here as to what to do to properly log data from this MEFI ECM. I'd like to be able to program it also. I've read various stuff on disassembling the binary and trying to create a hack file to create a definition from it, but this sounds like a long process.

How do I go about creating a definition file for this MEFI ECM?
How do I properly dump the bin from this ECM?

Thanks much!

Extinct
August 11th, 2012, 03:06 AM
I am in the same "boat", literally. I am working with a MEFI-3 controller for a Volvo Penta version of the Chevy Vortec 5.7L. I am interested in using my EFI-Live in a scanning mode only. I have a TunerPro RT .ADX file (data acquisition definition file) and a .XDF file (tuning definition file), and would like some help in getting my EFI-Live to at least scan this type of file, if not tune.

Ross and Paul, can you point us in the write direction?

If you need additional information regarding the data stream coming out of the ALDL connection, please let me know.

Any help you can give would be greatly appreciated.

Thanks

Tim

GMPX
August 12th, 2012, 09:21 AM
Ross and Paul, can you point us in the write direction?
I don't remember how it works Tim, sorry, it would have to be 10 years since I looked at an ALDL data stream.
Do you have information on what each data byte does and what each message request contains?

kangsta
August 12th, 2012, 09:36 AM
Extinct, you can create a definition for EFILive v4 from your ADX file.

Extinct
August 12th, 2012, 12:34 PM
Extinct, you can create a definition for EFILive v4 from your ADX file.

I thought it was probably possible, do you have any suggestions to get me started in the right direction?

kangsta
August 12th, 2012, 01:23 PM
First step would be to open the ADX in TunerPro and understand how the communications work then translate that info into how EFILive defines the data stream. It should be pretty straigh forward with that ECM. One thing to watch out for is that in the ADX the data item is defined by its starting offset and length (8,16bit). In EFILive its defind by the end offset and the length (8,16bit) so say if RPM was at offset 0x01 and 16bit in the ADX in EFILive it would be 0x03 and 16bit.

Extinct
August 12th, 2012, 01:35 PM
First step would be to open the ADX in TunerPro and understand how the communications work then translate that info into how EFILive defines the data stream. It should be pretty straigh forward with that ECM. One thing to watch out for is that in the ADX the data item is defined by its starting offset and length (8,16bit). In EFILive its defind by the end offset and the length (8,16bit) so say if RPM was at offset 0x01 and 16bit in the ADX in EFILive it would be 0x03 and 16bit.

I thought one could probably do that, but I have never done that kind of thing before so I was not sure. I have opened the ADX file using tunerpro and looked at the information, however I'm still not sure how to understand how the communications work and how to translate that to what EFILive uses.

13707

To all that have contributed to this thread, please let me say thanks for your help. I am willing to do the work to learn how to do this, but am not sure where to start, so I deeply appreciate the help to get me going in the right direction.

Now, back to teaching Tim ;-)

Extinct
August 12th, 2012, 01:39 PM
First step would be to open the ADX in TunerPro and understand how the communications work then translate that info into how EFILive defines the data stream. It should be pretty straigh forward with that ECM. One thing to watch out for is that in the ADX the data item is defined by its starting offset and length (8,16bit). In EFILive its defind by the end offset and the length (8,16bit) so say if RPM was at offset 0x01 and 16bit in the ADX in EFILive it would be 0x03 and 16bit.

OK, looking at your post close and looking at the ADX file closer, think I am beginning to understand. To make something EFILive would understand, does it have an editor where I can create a translated definition file?

Extinct
August 13th, 2012, 01:10 PM
Well, I looked at the V4 Definition editor and I'm afraid I don't understand much better than before I looked at it, can anyone help point me in the direction to learn a bit more so I can get this done?

Blacky
August 13th, 2012, 01:35 PM
You should read the V4 documentation on how to create a data stream. The editor is accessed as shown in the image below.

13712

Regards
Paul

Extinct
August 13th, 2012, 01:47 PM
You should read the V4 documentation on how to create a data stream. The editor is accessed as shown in the image below.

13712

Regards
Paul

Thanks for the help Paul, I did find how to open the editor, and have read a lot of the documentation, more than once. Can you recommend a specific section? I don't remember seeing a datastream section, although I did read the Vehicle Definition section and the ALDL protocol sections (didn't understand a lot of it, but I'm guessing if I read enough instructional material it will start to get through my thick skull - I am disadvantaged as I am a mechanical engineer, not a software or electrical engineer ;-)

Blacky
August 13th, 2012, 03:22 PM
Unless you have knowledge of the actual layout, format, scaling of the data stream then its going to be a difficult, uphill battle to figure it out.

Normally, the data is returned from the ECM as a sequence of bytes. Assume a simple/short data stream of 5 bytes (that I'm just making up on the spot) is defined as follows:

Byte 0 and 1 = RPM.
Byte 2 = Throttle position as %.
Byte 3 = Vehicle speed as mph.
Byte 4 = Battery Voltage as V.

Assume the following raw (hex) data was received from the ECM

$28,$63,$AF,$42,$7A

RPM = $2863 = 10,339 with a scaling factor of 0.25 = 2584.75rpm
TP = $AF = 175 with a scaling factor of 0.392157 = 68.6%
VSS = $42 = 66 with a scaling factor of 1 = 66mph
Battery = $7A = 122 with a scaling factor of 0.1 = 12.2

So you'd need to know:
1: The byte layout of the data stream data sent from the ECM.
2: The units and scaling factors that convert the raw hex data into engineering units.

Unless you have that info you can't easily create a data stream definition in EFILive.

Regards
Paul

Extinct
August 15th, 2012, 10:28 PM
Unless you have knowledge of the actual layout, format, scaling of the data stream then its going to be a difficult, uphill battle to figure it out.

Normally, the data is returned from the ECM as a sequence of bytes. Assume a simple/short data stream of 5 bytes (that I'm just making up on the spot) is defined as follows:

Byte 0 and 1 = RPM.
Byte 2 = Throttle position as %.
Byte 3 = Vehicle speed as mph.
Byte 4 = Battery Voltage as V.

Assume the following raw (hex) data was received from the ECM

$28,$63,$AF,$42,$7A

RPM = $2863 = 10,339 with a scaling factor of 0.25 = 2584.75rpm
TP = $AF = 175 with a scaling factor of 0.392157 = 68.6%
VSS = $42 = 66 with a scaling factor of 1 = 66mph
Battery = $7A = 122 with a scaling factor of 0.1 = 12.2

So you'd need to know:
1: The byte layout of the data stream data sent from the ECM.
2: The units and scaling factors that convert the raw hex data into engineering units.

Unless you have that info you can't easily create a data stream definition in EFILive.

Regards
Paul

Following your example, here is what I have:

RPM: Packet Offset (H|D) = 0x26 38 = RPM (no scaling or conversion)
TP: Packet Offset (H|D) = 0x23 35 = X * 0.390625


I'm not sure this is the same information as your example, but is it the same type of information? It has been years since I read Hex, but I am willing to get a calculator and work through it if I have all the information. I am really looking for a confirmation that I do have all the necessary pieces of information and if so how I might learn to put it all together in to something useful. Again, more than willing to re-read the documentation and go back through the process, just looking for a rosetta stone right now so I know what I am looking at.

Thanks again for all the help!

Blacky
August 16th, 2012, 09:09 AM
If a "rosetta stone" exists, it will be in the file called ALDLStuff.zip here: ftp://ftp.diy-efi.org/pub/gmecm/
That zip file contains hundreds of *.ds (plain text) files. Ecah file corresponds to a different GM engine controller's data stream.
Finding the right one for a MEFI controller may be difficult because the files are all listed by VIN codes and engine RPO codes - which yo umay not have/know for your MEFI controller.

Regards
Paul

Extinct
August 21st, 2012, 01:11 PM
OK, update on my project, which consist of creating a definition file for V4 using the Tunerpro ADX information I have for the Mefi controller. Hoping you guys can give me a little help along the way here...

1. 1st Tab - Application -
a. Eprom ID=Not sure - is this for informational purposes or does EFILive actually need it?
b. ALDL Baud - 8192

Blacky
August 21st, 2012, 01:16 PM
Application tab page: All values are for information only - to help other users identify whether the data stream works on their vehicles or not. The only value that is used by the EFILive software is the ALDL baud setting.

For the other tab pages, its probably easier if you refer to the documentation installed on your PC: file:///C:/Program%20Files%20%28x86%29/EFILive/V4/Doc/edit_vehicle.htm

Regards
Paul

Extinct
August 21st, 2012, 01:18 PM
Sorry about that post, hit enter before I finished it. I have the documentation in my lap and am working back and forth between what V4 needs and what I have. Trying to translate Spanish to Italian when I don't know either!

Blacky
August 21st, 2012, 01:19 PM
Sorry about that post, hit enter before I finished it.
I figured that's what happened :)

Extinct
August 21st, 2012, 01:38 PM
2. 2nd tab - Chatter - this is more difficult to decipher - I have six pieces of information and I am not sure how to translate them in to V4
a. Mode 8 Stop Chatter - 0xF4 0x56 0x08 0xAE
b. Reply - Mode 8 Stop Chatter - Timeout=200ms, Payload Offset (Dec)=3, Payload Size (Dec)=3, Body Size (Dec)=3)
c. Macro - Mode 8 Stop Chatter -
i. Command
ii. Mode 8 Stop Chatter
iii.Reply - Mode 8 Stop Chatter
d. Mode 9 Start Chatter - 0xF4 0x56 0x09 0xAD
e. Reply - Mode 9 Start Chatter - same as Mode 8 Stop Chatter
f. Macro - Same as Mode 8 macro except 8 and stop are replaced with 9 and Start

I assume this stop and start equates to V4's Suspend and Resume - correct?

Seems like I have the resume and suspend commands, but what about Heartbeat? Obviously I guess I could connect and determine it per the V4 documentation instructions but I am guessing I already have it in Tunerpro - I just don't recognize it.

Also, I assume I should check the reply check boxes in Chatter?

Blacky
August 21st, 2012, 01:47 PM
I assume this stop and start equates to V4's Suspend and Resume - correct?
Correct


Seems like I have the resume and suspend commands, but what about Heartbeat? Obviously I guess I could connect and determine it per the V4 documentation instructions but I am guessing I already have it in Tunerpro - I just don't recognize it.
The term heartbeat is just something I "made up" for EFILive. Basically all EFILive is trying to do is to find some "bus silence", i.e. when no other module is transmitting any data. It needs the silence so it can send the "stop chatter" command without the stop chatter command being garbled by some other module transmitting data on the bus while EFILive is halfway through transmitting the "stop chatter" command. So I figured the best way to "know" when there will be some bus silence is to record all the chatter and analyze the time between each frame of chatter data. The frame that has the most time between it and the next frame is what I call the "heartbeat" frame. You can choose any from you like but it has to be a frame in which the first "n" bytes are unique and do not change. The first "n" bytes are the bytes you enter for the "chatter" frame - that's what EFILive looks for on the bus. When EFILive sees that sequence of bytes it knows that it can transmit the "stop chatter" command once the current frame is complete.


Also, I assume I should check the reply check boxes in Chatter?
Check those only if the ECM sends back a reply when EFILive transmits the stop/start chatter commands. You can verify that by turning on the menu option: View->Serial I/O. That will show the frames being sent/received.

Regards
Paul

Extinct
August 21st, 2012, 01:49 PM
3. - 3rd tab - timing - I am guessing this has something to do with the timings from my previous post - but not sure. Tunerpro list several different Commands:
a. Mode 1 Message 0 ALDL request
b. Mode 1 Message 2 ALDL request
c. Mode 1 Message 4 ALDL request

all three of those ALDL request have byte strings and Timeout, Payload Offset, Payload Size, and Body Size values similar to the Chatter commands. Are these the timing values I am seeking? Or do I need to seek elsewhere? There are also two other commands, a clear all trouble codes command and a Command Message Normal Mode?

Blacky
August 21st, 2012, 01:55 PM
3. - 3rd tab - timing - I am guessing this has something to do with the timings from my previous post - but not sure. Tunerpro list several different Commands:
a. Mode 1 Message 0 ALDL request
b. Mode 1 Message 2 ALDL request
c. Mode 1 Message 4 ALDL request

all three of those ALDL request have byte strings and Timeout, Payload Offset, Payload Size, and Body Size values similar to the Chatter commands. Are these the timing values I am seeking? Or do I need to seek elsewhere? There are also two other commands, a clear all trouble codes command and a Command Message Normal Mode?

The timings are described in detail in the documentation - there's not much more I can add that is not already explained there.

The ALDL MODE byte values are pre-defined and listed in the drop down list box shown in the image below.

13796

Regards
Paul

Extinct
August 21st, 2012, 01:58 PM
Check those only if the ECM sends back a reply when EFILive transmits the stop/start chatter commands. You can verify that by turning on the menu option: View->Serial I/O. That will show the frames being sent/received.

Regards
Paul

Ok, and looking at the .adx file that has the macro listed as:

"Mode 8 Stop Chatter
Reply - Mode 8 Stop Chatter"

and that the Reply -Mode 8 Stop Chatter field had as a "process data" check box that is checked, would it appear that the ECM sends back a reply?

Blacky
August 21st, 2012, 02:00 PM
13799

Blacky
August 21st, 2012, 02:00 PM
Ok, and looking at the .adx file that has the macro listed as:

"Mode 8 Stop Chatter
Reply - Mode 8 Stop Chatter"

and that the Reply -Mode 8 Stop Chatter field had as a "process data" check box that is checked, would it appear that the ECM sends back a reply?
I would assume so, yes.
Paul

Extinct
August 21st, 2012, 02:05 PM
Ok, great, I am learning things tonight! Thanks for the help Paul. I need to study your post a bit more to make sure I can understand it fully, but I really appreciate the help and education.

BTW, part of the reason I am so keen on using EFILIve on this application is the MEFI-3 controller does not have much in the way of available inputs to use for O2 sensors the way old OBD-1 guys would use AC pressure or something like that for O2 sensor voltage. Therefore I am hoping to build a definition file and use my old EFILive blackbox with the external inputs to do input the 02 sensor reading.

Took the boat out this weekend and AFR was everywhere from 10:1 at WOT to 16:1 at cruise (used standalone LM-1 box).

Extinct
August 21st, 2012, 02:25 PM
OK, so reading the documentation more, and looking at the .adx file more, when I see something called a Byte string in the .adx file that looks like this:

0xF4 0x57 0x01 0x00 0xB4

I can interpret it as this:

Frame ID=F4
Length=57
Date Bytes=01&00
Checksum=B4

and this would be relatively standard byte string for Mode 1 Message 0 ALDL request

Right ? I think I am beginning to understand more...

Blacky
August 21st, 2012, 02:45 PM
OK, so reading the documentation more, and looking at the .adx file more, when I see something called a Byte string in the .adx file that looks like this:

0xF4 0x57 0x01 0x00 0xB4

I can interpret it as this:

Frame ID=F4
Length=57
Date Bytes=01&00
Checksum=B4

and this would be relatively standard byte string for Mode 1 Message 0 ALDL request

Right ? I think I am beginning to understand more...

Yes, exactly. If you look at my most recent screen shot, you'll see exactly that frame.
The length byte $57 is always $55+actual length - i.e. $57 means data length of 2.

P.S. Where you have typed 0x, EFILive uses $. Its just a C versus Pascal convention. C uses 0x to prefix hex numbers, Pascal uses $ to prefix hex numbers.
Just FYI: EFILive is written in Delphi (i.e. Object Pascal), FlashScan firmware is written in C so I sometimes use 0x and sometimes I use $ and but mostly I just confuse myself.

Regards
Paul

kangsta
August 21st, 2012, 08:51 PM
Extinct, looks like you're making good progress. Paul has kindly posted pretty much everything you need to translate the ADX into an EFILive xml file. If you want to post the xml file you have so far I'll have a look over the weekend, it makes it a bit hard to test without a controller to test it on.

P.S. I am a mechanical engineer too, this stuff is a little different but it once you understand it its not so bad. You'll find once you understand Efilive v4 it was years ahead of anything out there for ALDL, it still is the most stable effective datalogging tool for that comm protocol.


Therefore I am hoping to build a definition file and use my old EFILive blackbox with the external inputs to do input the 02 sensor reading.


dont know what interface you are referring to there but as far as i know EFILive v4 only works with traditional ALDL cables. That is untill Paul get a chance to integrated it with v8 ;-)

Extinct
August 30th, 2012, 07:47 AM
Extinct, looks like you're making good progress. Paul has kindly posted pretty much everything you need to translate the ADX into an EFILive xml file. If you want to post the xml file you have so far I'll have a look over the weekend, it makes it a bit hard to test without a controller to test it on.

P.S. I am a mechanical engineer too, this stuff is a little different but it once you understand it its not so bad. You'll find once you understand Efilive v4 it was years ahead of anything out there for ALDL, it still is the most stable effective datalogging tool for that comm protocol.



dont know what interface you are referring to there but as far as i know EFILive v4 only works with traditional ALDL cables. That is untill Paul get a chance to integrated it with v8 ;-)

Thanks for the nice words Kangsta, although I don't really think I am making too much progress - mostly due to other time demands. Once I get a little further I would love to post the file to have you look over the file.

Extinct
August 30th, 2012, 07:56 AM
13833Ok, I am now finally working on building the .xml file. If you guys would be so kind as to take a look at the attached screenshot (example attribute is IAC Base Pos, I have a couple of questions:

1. What V4 field do I put the hex value of 18 into (0x18)?
2. What V4 field do I put the hex value of 24 into?

Blacky
August 30th, 2012, 09:29 AM
0x18 hex is 24 decimal, its just the same value represented two different ways.
The 24 is the position (offset) of the data byte in the data steam packet. That value is called the "Start" value in EFILive, so put 24 in "Start".
The source data size is the same as EFILive's "Bits" field.

Note: If you have a 16 bit field, you have to specify the second byte as the start byte in EFILive, I'm not sure if the other package specifies the first byte.
For example, say the RPM was 16 bits and the two 8 bit bytes took byte positions 14 and 15 in the data stream.
In EFILive you would need to put 15 as the start byte and 16 as the bit size.
In the other package, they may specify it as an offset of 14 - just something to watch out for.

Regards
Paul

Extinct
August 30th, 2012, 12:10 PM
0x18 hex is 24 decimal, its just the same value represented two different ways.
The 24 is the position (offset) of the data byte in the data steam packet. That value is called the "Start" value in EFILive, so put 24 in "Start".
The source data size is the same as EFILive's "Bits" field.

Note: If you have a 16 bit field, you have to specify the second byte as the start byte in EFILive, I'm not sure if the other package specifies the first byte.
For example, say the RPM was 16 bits and the two 8 bit bytes took byte positions 14 and 15 in the data stream.
In EFILive you would need to put 15 as the start byte and 16 as the bit size.
In the other package, they may specify it as an offset of 14 - just something to watch out for.

Regards
Paul


First step would be to open the ADX in TunerPro and understand how the communications work then translate that info into how EFILive defines the data stream. It should be pretty straigh forward with that ECM. One thing to watch out for is that in the ADX the data item is defined by its starting offset and length (8,16bit). In EFILive its defind by the end offset and the length (8,16bit) so say if RPM was at offset 0x01 and 16bit in the ADX in EFILive it would be 0x03 and 16bit.

OK, thanks for the tips guys. So just to make sure I understand the offset situation for 16 bit fields, I will use the RPM field which is a 16 bit field. It is 0x26|38, so in EFILive I need to put 39 as the start bit, is that correct?

Blacky
August 30th, 2012, 12:24 PM
If the RPM was defined as 16 bits and taking up byte positions 38 and 39, then in EFILive you have to specify the byte that contains "Bit 0" as the start byte. That means byte 39 is the start byte. See image below.
13839
The concept is that the bytes in the data stream are numbered left (low) to right (high). However, the bits in each 8-bit BYTE or 16-bit WORD are numbered right (low) to left (high).


Regards
Paul

Extinct
August 31st, 2012, 07:36 AM
OK, still moving through populating all of the data fields. If you guys wouldn't mind taking a look at this example screen shot - have I left anything out that I need to populate in to the EFILive configuration (haven't started working on the dashboard or charts yet, that will come later - is that really required for the .xml file?)?13843

Blacky
August 31st, 2012, 09:59 AM
That looks ok, although you should make the EFILive "Code" field a nicer description than "4". It really should be "RPM" as that is what is displayed on the gauges and in the menus, see image.
13844

The "Chart", "Series" and "Dashboard" values simply tell the other parts of the EFILive software where to display the data. They are automatically set when you select the attribute (i.e. parameter) for display. Each chart and series and each gauge have a unique value associated with them that can be assigned to each attribute to cause that attribute to be displayed at that particular location. (see the documentation: Reference->Requests->Attributes for a list of the values)

In the screen shot above, the RPM parameter would have its "Dashboard" value set to 9, which is the unique value for the large gauge at the top of the dashboard.

Regards
Paul

Extinct
August 31st, 2012, 10:49 PM
That looks ok, although you should make the EFILive "Code" field a nicer description than "4". It really should be "RPM" as that is what is displayed on the gauges and in the menus, see image.
13844

The "Chart", "Series" and "Dashboard" values simply tell the other parts of the EFILive software where to display the data. They are automatically set when you select the attribute (i.e. parameter) for display. Each chart and series and each gauge have a unique value associated with them that can be assigned to each attribute to cause that attribute to be displayed at that particular location. (see the documentation: Reference->Requests->Attributes for a list of the values)

In the screen shot above, the RPM parameter would have its "Dashboard" value set to 9, which is the unique value for the large gauge at the top of the dashboard.

Regards
Paul

OK, thanks for the advice. Somehow I thought the EFILIVE "Code" field corresponded to the Tunerpro "Unique ID" field and that it was something the ECM read uniquely.

Now, to the 64 dollar question. How do create an external input parameter? The whole intent of this exercise is to use my flashscan blackbox (I have both the early FSP V1.2 and the latest handheld) to get an oxygen sensor input in to the data stream?

Blacky
September 1st, 2012, 01:11 PM
OK, thanks for the advice. Somehow I thought the EFILIVE "Code" field corresponded to the Tunerpro "Unique ID" field and that it was something the ECM read uniquely.

Now, to the 64 dollar question. How do create an external input parameter? The whole intent of this exercise is to use my flashscan blackbox (I have both the early FSP V1.2 and the latest handheld) to get an oxygen sensor input in to the data stream?

Right now it is not possible to log ALDL data streams with FlashScan V1 or V2. That will be available once the V8 Scan Tool software is released for FlashScan V2.

Regards
Paul

Extinct
September 1st, 2012, 01:15 PM
Right now it is not possible to log ALDL data streams with FlashScan V1 or V2. That will be available once the V8 Scan Tool software is released for FlashScan V2.

Regards
Paul

Wow, major bummer. I'm sure there is a thread with a hundred people bugging you about when that will be. So I take it the ALDL data stream is significantly different than the later models? So to use the V4 to log data I guess a different cable is required?

Blacky
September 2nd, 2012, 10:14 AM
Wow, major bummer. I'm sure there is a thread with a hundred people bugging you about when that will be. So I take it the ALDL data stream is significantly different than the later models? So to use the V4 to log data I guess a different cable is required?

Yes a different cable is required but you can make an RS232-ALDL cable yourself for around $10 in parts if you have a real serial port on you laptop or you can purchase an ALDL-USB cable for around $80-$100 from various places on the net.

Reagrds
Paul

Extinct
September 2nd, 2012, 01:06 PM
Yes, I have an aldl cable, but it actually seems kind of pointless at this point, I really can't do that much without the oxygen sensor input.

Extinct
December 8th, 2012, 05:00 PM
Right now it is not possible to log ALDL data streams with FlashScan V1 or V2. That will be available once the V8 Scan Tool software is released for FlashScan V2.

Regards
Paul

Paul, can you point me to the thread where I can get updates on the status of the software release you referenced here?

Thanks

Blacky
December 9th, 2012, 08:46 AM
Paul, can you point me to the thread where I can get updates on the status of the software release you referenced here?

Thanks

Each time we release a new software update (including pre-releases) we'll post it here:
http://forum.efilive.com/forumdisplay.php?71-Software-Updates-and-Installation-Help
There is a pre-release update due to be posted this week.
It does not have ALDL support yet, but we are much closer to releasing ALDL support because ALDL uses a very similar logging strategy to the Cummins logging which is supported in this pre-release.

And this page will get updated when each official public release is available:
https://www.efilive.com/index.php?option=com_content&view=article&id=48&Itemid=133

Regards
Paul

Extinct
January 1st, 2013, 08:07 AM
Paul, quick question on this, my next shot at this project is in March, do you expect to have the ALDL logging by that time or should I prepare a plan b?

Blacky
January 1st, 2013, 10:17 AM
Paul, quick question on this, my next shot at this project is in March, do you expect to have the ALDL logging by that time or should I prepare a plan b?
Sorry, ALDL logging via Flashcan or AutoCal won't be available before March.
Regards
Paul

Extinct
January 2nd, 2013, 12:47 AM
Sorry, ALDL logging via Flashcan or AutoCal won't be available before March.
Regards
Paul

Thanks for the reply Paul, that helps with my planning!

Extinct
August 29th, 2013, 12:20 AM
Paul, thought I would check in here as I am anxious to be able to use my EFILive scanner to read the MEFI datastream with a wideband. In the interim, I went snooping around on the internet looking for alternate solutions - thought it was funny that when I looked in on the competitors forum it led right back to where I started with you.

For your enjoyment: http://www.hptuners.com/forum/showthread.php?63-91-ZR1&highlight=aldl

Extinct
September 3rd, 2013, 03:19 PM
Right now it is not possible to log ALDL data streams with FlashScan V1 or V2. That will be available once the V8 Scan Tool software is released for FlashScan V2.

Regards
Paul

I was just re-reading this -are we there yet?

Blacky
September 3rd, 2013, 03:33 PM
I was just re-reading this -are we there yet?

The short answer is no.

The long answer is I am working on the V8 scan tool right now (have been for the past few months).

I still can't say when we'll have ALDL ready though.

Regards
Paul

chrissnow
March 25th, 2016, 08:04 AM
OK, still moving through populating all of the data fields. If you guys wouldn't mind taking a look at this example screen shot - have I left anything out that I need to populate in to the EFILive configuration (haven't started working on the dashboard or charts yet, that will come later - is that really required for the .xml file?)?13843


Appreciate i'm dragging up the past but could you share your definitions?
would be greatly appreciated :-)

Extinct
March 25th, 2016, 01:07 PM
Appreciate i'm dragging up the past but could you share your definitions?
would be greatly appreciated :-)

See this post: https://forum.efilive.com/showthread.php?3418-MEFI-4-ECM-definition-file&p=196893&viewfull=1#post196893

Dropped this project due to lack of support from the guys. MEFIburn is your only option. I have a copy I would be willing to sell.

chrissnow
March 25th, 2016, 10:57 PM
See this post: https://forum.efilive.com/showthread.php?3418-MEFI-4-ECM-definition-file&p=196893&viewfull=1#post196893

Dropped this project due to lack of support from the guys. MEFIburn is your only option. I have a copy I would be willing to sell.

Ok, may be interested :-) can you drop me an mail. chris@(myforumname).co.uk obviously replacing (myforumname), I get enough spam as it is!!

T

iaff284
May 10th, 2016, 12:33 AM
Extinct,

I am trying to scan engine data on a Mercruiser 5.7 MPI MEFI 3 with Tunerpro. Can you send me a copy of your ADX?