new $EE tuning thing!

[steveo]

i don't think it's your bin man i don't think eehack likes your serial interface. i betcha anything it's having trouble setting the irregular 8192 baud rate

[Terminal_Crazy]

there must be a universal method for this stuff, I know tunercat winflash doesn't have a special ybody mode.... it "just works". maybe it detects vehicle type based on idle traffic.

Have you tried feeding TC winflash back into your logger & recording what it does ?

Just a thought.

Mitch

[Terminal_Crazy]

When i wrote my ABS/datalogger (lots) years ago i just sent a shut up request before each message.

i got 80-90% good packets back & just discarded the bad frames.

There wasn't the same info around back then :-)

Certainly mS timing would have been well out of the question.


Mitch

[spfautsch]

there must be a universal method for this stuff, I know tunercat winflash doesn't have a special ybody mode.... it "just works". maybe it detects vehicle type based on idle traffic.

From what I've been able to log, winflash sends the F4 hush request, and listens for the ECM echo. Then it seems to listen for idle traffic for a bit and sends the F1 hush request if things don't quiet down. Also worth noting, the F1 hush does not appear to be echoed by the CCM. But this could be an erroneous assumption because I'm running it in an XP virtual and I've been unable to successfully put the ECM in programming mode while also logging serial data.

Another thing of interest - I was sure I'd read something like this when I asked if there was another BCM / CCM module in the Y bodies. From the DataMaster OBD1 Manual:

4.3.4.2
Options- Advanced- Disable ALDL Handshake
This option is provided to "seize" control of the ALDL communications link, bypassing the
standard ALDL protocols. On Corvettes, this will result in the dashboard, HVAC and active
suspension modules not receiving data updates as expected; thus the ASR light may be activated
during data collection. If this occurs, the next vehicle start cycle will clear the ASR light.

Having read that I messed with DM a bit, and noticed in the data acquisition function in v4.01, options for "Disable CCM Handshake" and "Disable Dash Refresh". But I haven't had much luck capturing serial data with DM.

I just got the throttlebody back on and found the battery sucked to death, so I probably won't be able to play much tonight. But I feel optimistic this will be a simple fix once I understand the protocol and command structure better.

[steveo]

that's great news you're looking into it. keep us updated

[spfautsch]

Don't worry, I will. After getting this to compile and run on Ubuntu I'm like a kid on christmas morning with this s**t.

One more question, in regards to this from your page on $EE ALDL Communications:

MODE8 – DISABLE CHATTER

Sending this causes the device to stop sending idle traffic.
This should be sent when a new device (such as a datalogger) is to become the new bus master, and to ensure that the device doesn’t “chat” at random and screw up datalogging or programming.
This is on a timer, it will automatically resume chatter after a predefined period of time.

Any chance you know where you found this info, and what that predefined period might be?

[steveo]

Any chance you know where you found this info, and what that predefined period might be?

wrote it myself

predefined period is device dependant. for the $EE ecm, it's roughly 3 seconds.

[spfautsch]

I guess it is critical to send shutup request, after receiving the broadcast message
f0 56 f4 - for PCM
f0 56 f1 - for CCM [It is also possible that the shutup request has other functional address]

I really need idle traffic scan from y-body.
It is also possible that you need to send periodic shutup request to ccm, if it has some timer related routine.

I completely overlooked this the other night, here's small chunk from a datamaster log. Key on engine off.

F2  00  4F  4E  01  00  46  1A  C3  88  00  42  FF  FF  00  A0  
 A0  9B  F0  56  F1  C9  10  59  08  4F  02  00  3E  40  57  FF  
 FF  6B  41  67  02  F2  00  4F  4E  01  00  46  1A  C3  88  00  
 42  FF  FF  00  A0  A0  9B  10  59  08  4F  02  00  3E  40  57  
 FF  FF  6B  41  67  02  F2  00  4F  4E  01  00  46  1A  C3  88  
 00  42  FF  FF  00  A0  A0  9B  10  59  08  4F  02  00  3E  40  
 57  FF  FF  6B  41  67  02  F2  00  4F  4E  01  00  46  1A  C3  
 88  00  42  FF  FF  00  A0  A0  9B  10  59  08  4F  02  00  3E  
 40  57  FF  FF  6B  41  67  02  F2  00  4F  4E  01  00  46  1A  
 C3  88  00  42  FF  FF  00  A0  A0  9B  10  59  08  4F  02  00  
 3E  40  57  FF  FF  6B  41  67  02  F2  00  4F  4E  01  00  46  
 1A  C3  88  00  42  FF  FF  00  A0  A0  9B  F0  56  F1  C9  10  
 59  08  4F  02  00  3E  40  57  FF  FF  6B  41  67  02  F2  00  
 4F  4E  01  00  46  1A  C3  88  00  42  FF  FF  00  A0  A0  9B  
 10  59  08  4F  02  00  3E  40  57  FF  FF  6B  41  67  02  F2  
 00  4F  4E  01  00  46  1A  C3  88  00  42  FF  FF  00  A0  A0  
 9B  10  59  08  4F  02  00  3E  40  57  FF  FF  6B  41  67  02  
 F2  00  4F  4E  01  00  46  1A  C3  88  00  42  FF  FF  00  A0  
 A0  9B  10  59  08  4F  02  00  3E  40  57  FF

I'll have to do more logging (i.e. engine running) to get a more complete picture.

I logged an eeprom read from winflash the other night and it appears once the CCM submits that it stays quiet until the key is cycled off or a resume command is received.

[steveo]

I logged an eeprom read from winflash the other night and it appears once the CCM submits that it stays quiet until the key is cycled off or a resume command is received.

if that's the case, we need to take extra steps to guarantee the CCM traffic resumes

[RobertISaar]

does a mode 9 request not accomplish that?

[spfautsch]

if that's the case, we need to take extra steps to guarantee the CCM traffic resumes

You kind of already have that handled. If you autodetect a CCM / BCM all that's needed is to replace the vehicle_type() checks with a tracking variable i.e. bool F1_detected or whatever.

void datastream::request_resume() {
  // we dont wait around for a response since this is only called on
  // disconnect, and if it fails. meh.
  if(config.get_vehicle_type() == VEHICLE_Y || config.get_vehicle_type() == VEHICLE_B) {
    // wake up ccm
    force_raw_resume_request(0xF1);
  }
  force_raw_resume_request(0xF4);
  post_delay_amount = 0;
  restart_garbage_collection();
}

[steveo]

it should, yeah.

but now we have a few logical scenarios to deal with.

in particular if we start requiring idle traffic to connect to a y-body, subsequent connection attempts may fail if eehack or its host computer crashes and that resume request never gets sent. sending a few mode9 requests to the ccm BEFORE connecting may be a solution to that.

[spfautsch]

in particular if we start requiring idle traffic to connect to a y-body, subsequent connection attempts may fail if eehack or its host computer crashes and that resume request never gets sent. sending a few mode9 requests to the ccm BEFORE connecting may be a solution to that.

There may be circumstances where you would have a point, but I think maybe you're over-thinking things. If you're going to get back on the horse you just fell off of, why kick it in the 'nads first? I suspect this is why the other softwares are listening for broadcast traffic for a pre-defined period before jumping in.

Is it safe to assume an ECM with an f-body bin begins broadcasting as soon as you connect the battery terminals?

I'm working on something that should tackle this effortlessly. See my PM about bus arbitration.

[spfautsch]

I guess it is critical to send shutup request, after receiving the broadcast message
f0 56 f4 - for PCM
f0 56 f1 - for CCM [It is also possible that the shutup request has other functional address]

I should really try reading things three times out loud instead of skimming and cherry picking. I "discovered" this on my own the hard way, just now. I think this is the answer to the problem. Thanks!

[steveo]

Is it safe to assume an ECM with an f-body bin begins broadcasting as soon as you connect the battery terminals?

I'm working on something that should tackle this effortlessly. See my PM about bus arbitration.

not without ignition power