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
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
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
'95 Z28 M6 -Just the odd mod.
'80 350 A3 C3 Corvette - recent addition.
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:
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.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.
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.
that's great news you're looking into it. keep us updated
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:
Any chance you know where you found this info, and what that predefined period might be?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.
I completely overlooked this the other night, here's small chunk from a datamaster log. Key on engine off.
I'll have to do more logging (i.e. engine running) to get a more complete picture.Code: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 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 resumesI 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.
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.
Code: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(); }
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.
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.
Bookmarks