Let's talk MEFI

[Skiier64]

24 minutes ago, GaryDoug said:

I think we may be getting somewhere now. Download this new version, still an early trial and will not work fully, but it can help me get started on a working version. Do the same as before and post the file. Engine does not need to be running yet. Thanks.

http://www.mediafire.com/file/wdtbt3p0g94myp7/MEFI4.exe/file

 

OK this is all I got with the new version. I do immediatly get an "Unhandled Exception" as soon as I click the "scan" button though.

Shutup request----F45608AE----
Shutup request----F45608AE----
Shutup request----F45608AE----

Time=10:06:27 PM
Idle traffic:F4 56 08 AE F4 56 08 AE F4 56 08 AE F4 56 08 AE F4 56 08 AE F4 56 08 AE
Engine request-->--F4570100B4----

[GaryDoug]

Uh oh. I will take a look. Must be a bug with the changes I made. I didn't test it on my boat first. Tomorrow. Thanks.

[GaryDoug]

I can't duplicate the unhandled exception error here. Can you copy and paste the complete error message?

Edit: Never mind, I think I found it.

Try this one: http://www.mediafire.com/file/awrqmqy9pgdrgza/MEFI4.exe/file

 

Edited May 22, 2018 by GaryDoug
add link

[Skiier64]

3 hours ago, GaryDoug said:

I can't duplicate the unhandled exception error here. Can you copy and paste the complete error message?

Edit: Never mind, I think I found it.

Try this one: http://www.mediafire.com/file/awrqmqy9pgdrgza/MEFI4.exe/file

 

WooHoo!!  I can read data now from the ECM.  The only thing is that it looks like the data values are in the wrong places.  Example: when I move the throttle, runtime and minute meter change values.  Let me know if you need any more testing.

[GaryDoug]

Yes, the data will not be in the right places. Can you post the Comms log  for about 30 seconds of scan time here? I want to see the entire line of engine data. That will confirm the message length and be a guide to putting the data in the right places. Also, can you email the comms file to me at [email protected]?

We will definitely need to do more testing. But the next step should give some useful results. Thanks

Edited May 22, 2018 by GaryDoug

[Skiier64]

40 minutes ago, GaryDoug said:

Yes, the data will not be in the right places. Can you post the Comms log  for about 30 seconds of scan time here? I want to see the entire line of engine data. That will confirm the message length and be a guide to putting the data in the right places. Also, can you email the comms file to me at [email protected]?

We will definitely need to do more testing. But the next step should give some useful results. Thanks

No problem, I will run it and send you the file when I get home from work tonight.

[GaryDoug]

Would it be possible to have the engine running for this scan? That would be more helpful for confirming the parameters.

[Skiier64]

1 hour ago, GaryDoug said:

Would it be possible to have the engine running for this scan? That would be more helpful for confirming the parameters.

I might be able to test it with the boat running tomorrow.

[GaryDoug]

If having the engine running is a problem, just do the scan without it running.

[Skiier64]

52 minutes ago, GaryDoug said:

If having the engine running is a problem, just do the scan without it running.

I did email you the scan log, with the engine not running, on the 22nd.  Didn't you get it?

Edited May 25, 2018 by Skiier64

[GaryDoug]

Yep, it went to the spam folder. Thanks.

File looks great, very stable with no fluctuations. I should have something to use in a few days.

Edited May 25, 2018 by GaryDoug

[GaryDoug]

Important update. It has become apparent that most cables that are built by individuals like us will not work properly with the boat computer. This is the fix:

Place an ordinary small silicon diode (I used a 1n4001) in series with the TXD line (usually orange) with the anode of the diode toward the end with the boat engine connector. It appears that most cables will pull up too strongly to the data line and prevent the ECM from transmitting enough signal back to the cable. The diode blocks that pull-up.

Edited July 30, 2018 by GaryDoug

[Gmdattilo]

Any chance of getting this to work with MEFI 2? I'm planning to have my boat home this weekend and I have the parts laying around to build the interface. 

[GaryDoug]

18 hours ago, Gmdattilo said:

Any chance of getting this to work with MEFI 2? I'm planning to have my boat home this weekend and I have the parts laying around to build the interface. 

Here you go: http://www.mediafire.com/file/zb1b026mc6ildeg/MEFI2.zip/file

It is in beta testing so there are probably some bugs.

[Gmdattilo]

Thank you GaryDoug. Unfortunately I did not get to do any testing this weekend. I had the boat home to do trailer work and ended up cutting the crap out of my finger with a cutoff wheel. Long story short I was lucky to get the trailer pieced back together. I will test the next chance I get, hopefully in the next couple of weeks. I'm also beginning to thinking that my boat may actually be MEFI-3 not MEF-2. I hope you didn't put too much time the beta you posted. I will probably end up not being able to use it. I guess on the bright side, for me, it sounds like the MEFI-3 version is working quite well. 

Do you have any documentation you'd be willing to share that details the MEFI-3 data stream. Maybe the ADX file you posted earlier contains this information but I'm not familiar with the tunerpro format. 

[Gmdattilo]

...and after asking about my question about the data stream format google turns up a post gear head efi where one GaryDoug asks a very clear question about ADX format and gets only non-answers. I can't imagine there is more than one GaryDoug out there who is interested in this stuff. Did you ever find a documented answer on the ADX format? I have a suspicion you just figured it out yourself.  

[GaryDoug]

No problem with the MEI2 app. It was already developed for another user in another forum.

GaryDoug, that's me at Gearhead EFI. All I know came from the ADX file as far as the parameters. Format is RS232 inverted (0=1, 1=0) at TTL (0-5v) levels. The following is a sample of a typical data string coming from a particular GM ECM. It is only an example. The Frame header, frame length and mode are given in the ADX file. The rest (3-65 in this line) except the checksum are all data. The checksum at the end of both the request and reply is calculated by the program and must match what the ecm calculates or the request is ignored. The column named ptr is incorrect; the real pointer starts at byte 3, not 5. Byte 3 may be an extension of the header and, in our MEFI case, it is 0 for "message #0". In our case, there are multiple request and reply messages possible. Those are listed in the ADX file. So, in our case, the data pointer really starts at byte 4.

The lines for the requests (sent by the pc) are given in the adx file.

Byte    ptr    Name    "Value, conversion formula"    Comments    
0        Frame Header    =0xF0        
1        Frame Length    =0x95=0x55+ number of data bytes    0x40 data bytes    
2        Mode    =0x01        
3        PROM ID - MSB    =0x02    Prom ID=0x0245    
4        PROM ID - LSB    =0x45        
5    0    Malfunction Byte1    "digital, bits correspond to error code"    not verified    
6    1    Malfunction Byte2    "digital, bits correspond to error code"    not verified    
7    2    Malfunction Byte3    "digital, bits correspond to error code"    not verified    
8    3    Malfunction Byte4    "digital, bits correspond to error code"    not verified    
9    4    Malfunction Byte5    "digital, bits correspond to error code"    not verified    
10    5    Coolant Temperature    [Dec C]=N*0.75-40        
11    6    Same as coolant temperature    =byte 10        
12    7    Startup Coolant Temperature    [Dec C]=N*0.75-40        
13    8    Throttle Position Sensor (TPS)    [Volts]=5*N/255    should be between 0.4V and 4.5V    
14    9    Engine Load        not verified    
15    10    RPM    [RPM]=N*25        
16    11            analog    
17    12    "Time between Reference Pulses, MSB"    Inverse proportional to the RPM        
18    13    "Time Between Reference Pulses, LSB"            
19    14            analog    
20    15    Vehicle Speed Sensor (VSS)    [MPH]=N        
21    16            digital    
22    17    Oxygen Sensor  (O2)    [mv]=N*4.44        
23    18    Oxygen Sensor Transition Counter    Count=N        
24    19            analog    
25    20    BLM Fuel Correction    128 = Unity    should be 118-138 (typicaly)    
26    21    BLM Cell    cells range 0-15    0=ideal 15=WOT    
27    22    Int128 Fuel Correction    128 = Unity        
28    23            analog    
29    24    Same as byte 28    =byte 28    analog    
30    25    Desired idle RPM    [RPM]=N*12.5    not verified    
31    26    External Pressure    "[Volts]=5*N/255, [Kpa]=(N+28.06)/2.71"    uses the MAP on ignition    
32    27    Manifold Absolute Pressure (MAP)    "[Volts]=5*N/255, [Kpa]=(N+28.06)/2.71"        
33    28            analog    
34    29            digital    
35    30            analog    
36    31            analog    
37    32    Battery Voltage    [Volts]=N/10        
38    33    Spark Advance    [Deg]=N/2.844    not verified    
39    34        =0    constant    
40    35            analog    
41    36        "255 when engine running, 0 when off"    constant    
42    37    Same as byte 40 + 68    =byte 40 + 68    analog    
43    38    "Injector Pulse Width, MSB"            
44    39    "Injector Pulse Width, LSB"    [msec]=0.0153*(MSB*256+LSB)    "not verified, range is 1-6msec"    
45    40    Air Fuel Ratio (A/F)    [Ratio]=N/10    Ideal ratio is 14.7    
46    41        seems related to AFR    analog    
47    42    Fuel Flow Rate            
48    43            analog    
49    44    Engine Run Time MSB            
50    45    Engine Run Time LSB    [Sec]=MSB*256+LSB        
51    46            digital    
52    47        =0    constant    
53    48    MSB        analog    
54    49    LSB        analog    
55    50            digital    
56    51        =0    constant    
57    52        =32    constant    
58    53    Status Byte 1        digital    
59    54    Status Byte 2        digital    
60    55    Status Byte 3        digital    
61    56            digital    
62    57            digital    
63    58            digital    
64    59            digital    
65    60            digital    
66    61    Checksum    N=modulo256(sum of bytes 0..65)        
                    
                    
                    
                    
DTC    Byte 1    Byte 2    Byte 3    Byte 4    Byte 5
Bit 0    23    35    53    66    
Bit 1    22    34    52    64    
Bit 2    21    33    51    63    
Bit 3    19    28    45    62    
Bit 4    15    27    44    61    
Bit 5    14    26    43    55    
Bit 6    13    25    42    54    
Bit 7    12    24    41       

Edited September 6, 2018 by GaryDoug

[Gmdattilo]

GaryDoug you are the man. The MEFI-3 tool worked right off. My trailer related suffering continued today but that gave me the opportunity to test your software this evening. I guess the dealer who sold me the boat 9 years ago was honest about the engine hours. He told me it was around 200 hrs. 20047 mins today according to your software strikes me as reasonable. We baby the boat. I'm really grateful that you've created a tool you're willing to share. MEFI seems to be a big secret and folks want hundreds of bucks for simple scan tools. Again, thanks so much for your work and sharing it.

The note about using a diode on the TX line several posts back was not lost on me. I went ahead and built up my board with the diode and a weak pull-up so I could do a loop test and make sure the USB-TTL converter was working. If anyone needs a schematic and photo of my rig please let me know. I can sketch it up and provide a pic. I also found that some wire ferrules worked pretty well as pins for the ALDL connector. Sadly I chose one of those awful FTDI UARTs that was a fake. I spent much more time rolling back drivers than I spent actually connecting to the ECM. It was dirty-pool that FTDI decided to "break" all of those chip that folks bought with no knowledge that they were fakes. I digress...

Thanks a third time for your efforts and sharing!

[GaryDoug]

Thanks for the feedback. I wrote this app for myself after I was so disappointed in the ScanerPro one I bought. And I really didn't want to go through the hassle of trying to collect a fee for it. More trouble than it's worth for me. I wrote the Scan9495  PC app (LT1-based Camaros and Firebirds 93-95) several years ago and I give that away for free also. Same reasons.

For what it is worth you can get the mating Delphi/Aptiv connector pins and bodies from Mouser Electronics for a very reasonable cost (about $10 including ground shipping).

.As for the FTDI scandal, at least they pulled back the kill versions of the driver that rendered the cable unusable for most users. It took me whole day to learn how to recover them. Now their drivers just refuse to work with the clones.

Edited September 16, 2018 by GaryDoug

[Gmdattilo]

On 9/15/2018 at 9:40 PM, GaryDoug said:

Thanks for the feedback. I wrote this app for myself after I was so disappointed in the ScanerPro one I bought. And I really didn't want to go through the hassle of trying to collect a fee for it. More trouble than it's worth for me. I wrote the Scan9495  PC app (LT1-based Camaros and Firebirds 93-95) several years ago and I give that away for free also. Same reasons.

For what it is worth you can get the mating Delphi/Aptiv connector pins and bodies from Mouser Electronics for a very reasonable cost (about $10 including ground shipping).

.As for the FTDI scandal, at least they pulled back the kill versions of the driver that rendered the cable unusable for most users. It took me whole day to learn how to recover them. Now their drivers just refuse to work with the clones.

GaryDoug

Somehow i never ended up with a copy of the FTDI driver that bricked a chip. I've only had the driver that returns the non-genuine-device string. I guess I'm lucky.

I started doing some research on you Scan9495 software and ended up reading about 10 pages of posts on firebird nation. Cool to see how the software develops and I can also see how once you had the MEFI-3 adx it was (relatively) easy to get something working for MEFI. So this brings me to my next questions and please feel free to tell me to quit bugging you if I'm wearing you out...

Poking thru the MEFI-3 adx file i think i might be starting to understand the response format, sorta.

<ADXVALUE id="64" idhash="0xDE68F5B0" title="IAC Desired RPM">
    <units>RPM</units>
    <packetoffset>0x1B</packetoffset>

In the example I copied above, is it correct that the 0x1B (27th) byte in the reply is the Desired RPM? Your example above lists the bytes of data starting at some additional offset so maybe the desired RPM is really at 0x1B+0x03 or +0x04? What part of the adx tells us where the header ends?

I am also curious about all the modes and messages listed in command areas of the adx. I am assuming that at least one of these commands tells the ECM to "shut-up" and then another tells it to send the data 64 bytes of data. I saw one of your posts on another forum where you said you had to send 3 shut-ups to make things work. I assume one of the "macros" does this?

I probably should have logged some data the other night when i tested your software. I could probably dissect it myself but I didn't save anything and the boat is back at the lake. Any chance you've got a log file saved that you could share so I can do some dissection before I get back to the boat?

My end goal is to develop an Arduino sketch that will pull dash-board-like data from my ECM continuously. I think your work could be the basis for that effort.

I know this post is getting long, but once again, thank you for sharing your work. This is awesome.

[GaryDoug]

On 9/17/2018 at 8:12 PM, Gmdattilo said:

I probably should have logged some data the other night when i tested your software. I could probably dissect it myself but I didn't save anything and the boat is back at the lake. A

Do that. For the maybe a dozen users that I have supplied with free scan software for the Mefi-x ECM on the condition that they return the favor by sending me some useful log data, I have received practically nothing. I am not happy about that and have decided to communicate on a pay-as-you-go basis. Give me some data and I will give you guys some explanations. Sorry, but this is getting old for me. I would have thought the users would live up to the deal but so far, nothing.

[Gmdattilo]

Gary, As long as the weather cooperates I will be winterizing this weekend. I will do some captures then. I wont be able to run much over idle since the garden hose barely keeps up with the raw water pump. Is there anything in particular you want me to capture? I can blip the throttle in neutral but obviously can't put an load on it.

 

Edited September 25, 2018 by Gmdattilo
wrong word

[GaryDoug]

That's fine. Just enable the Engine data logging (Auto-save scan file box checked) and the Comms data (Enable Comms display and Include Idle traffic boxes checked), so the Comms data appears in the box. Then save the Comms log to file at the end. Also need a screenshot of the Engine status (with engine running) and ECM Configuration (anytime with ignition on) screens.

Send me the Comms log file, Engine data log file , and the two screenshots to [email protected] or post them here if possible, Thanks

[Gmdattilo]

Gary you should have an email with my scan data from today.

[GaryDoug]

On 9/17/2018 at 8:12 PM, Gmdattilo said:

GaryDoug

Somehow i never ended up with a copy of the FTDI driver that bricked a chip. I've only had the driver that returns the non-genuine-device string. I guess I'm lucky.

Not really lucky. They don't have the destructive version posted anywhere unless you go searching for it. It certainly is not in the auto-update path

Poking thru the MEFI-3 adx file i think i might be starting to understand the response format, sorta.

<ADXVALUE id="64" idhash="0xDE68F5B0" title="IAC Desired RPM">
    <units>RPM</units>
    <packetoffset>0x1B</packetoffset>

In the example I copied above, is it correct that the 0x1B (27th) byte in the reply is the Desired RPM?  Yes  Your example above lists the bytes of data starting at some additional offset so maybe the desired RPM is really at 0x1B+0x03 or +0x04? What part of the adx tells us where the header ends? 

  <ADXCLISTENPACKET id="COMMAND0LSN" idhash="0xD6AE9A5C" title="Reply - Mode 1 Message 0 ALDL  Request" flags="0x00000005">
    <listentimeout>300</listentimeout>
    <packetbodylength>64</packetbodylength>
    <packetoffsetinbody>3</packetoffsetinbody>
    <packetsize>61</packetsize>
  </ADXCLISTENPACKET>

This tells you the overall length of the response as 64 bytes, the offset (equal to the header length of 3 bytes) and the data length of 61 bytes. The actual header is not specified, although I think that should be important.

 

I am also curious about all the modes and messages listed in command areas of the adx. I am assuming that at least one of these commands tells the ECM to "shut-up" and then another tells it to send the data 64 bytes of data. I saw one of your posts on another forum where you said you had to send 3 shut-ups to make things work. I assume one of the "macros" does this?

The overall commands are in the ADX header section, in this case it contains :

  <ADXHEADER>
    <guid>06023c16-5584-4ea3-8b13-f99604c93917</guid>
    <flags>0x10001</flags>
    <objectcount>207</objectcount>
    <userversion>1.0</userversion>
    <author>GaryDoug</author>
    <desc>For MerCruiser MEFI3 ECU</desc>
    <baud>8192</baud>
    <DEFAULTS datasizeinbits="8" sigdigits="2" outputtype="3" baud="0" signed="0" lsbfirst="0" float="0" />
    <connectcmd>COMMAND4MAC</connectcmd>   .....requests the ECM to shutup
    <monitorcmd>COMMAND0MAC</monitorcmd>   .....requests Mode 0 Message 0 data
  </ADXHEADER>

See the macro section for details. Note that the macros call other commands. Also note that many of the macros and commands are never used, they are just there for future use or reference.

 

Note that this is not a real language in itself. It is more like a database file that the real program uses and is specific for a certain type of ECM. The main app, TunerPro, just uses it for direction in how to do the requests and the collection of data.

Now that you have the engine datalog file and the comms log file, you should be able to easily see the correlation between the two. The comms log file shows you exactly what has come back from the ecm and the engine data file shows you the result of taking that comms data and formatting it to be useful for display. The basic method of asking for and receiving the data is relatively simple. It is just the timing that has to be tweaked to prevent data loss or corruption. Sometimes an oscilloscope can come in very handy for viewing the timing of the signal packets.

Edited October 1, 2018 by GaryDoug