Logging with a BCM ALDL bus master

[charlay86]

Has anyone tried using the mode 7 commands while logging to keep the BCM / SRS / ETC / Dash happy?
I was reading through some of the US car ALDL data stream definition files on Moates.net and I noticed that all the vehicles with the BCM as the bus master say something like this...

BCM OVERVIEW
The BCM is the master of ALDL. When an ALDL tester is used to gather ALDL data, it should gain master ship of ALDL by issuing
a mode 8 to the BCM. Once the tester has gained mastership, it's the testers responsibility to schedule and command normal mode messages
(see normal mode message schedule) from the BCM to maintain normal system functionality while gathering ALDL data from any module on
the data link.

MODE 7 (COMMAND MESSAGE)
ALDL REQUEST:
- MESSAGE ID = $F1
- MESSAGE LENGTH = $57
- MODE = $07
- MESSAGE CODE
- CHECKSUM

THE BCM RESPONDS BY TRANSMITTING THE SELECTED NORMAL MODE MESSAGE

--------------------------------------------------------------------

MASTER MODULE NORMAL MODE MESSAGES TO BE COMMANDED DURING MODE 1 COMMUNICATIONS WITH ANY CONTROLLER ON THE DATA LINK WITH THE MASTER.
THESE MESSAGES ARE TO BE COMMANDED WITH A MODE 7 COMMAND.

COMMAND ID LISTEN ID MES LENGTH

$10 $10 1 HVAC PROGRAMMER MESSAGE
$20 $21 x IP MESSAGES
$22 $22 x
$30 $31 x ECCP/CRT MESSAGE
$40 $41 x ECM MESSAGE

COMMAND ID: THIS IS THE ID OF THE NORMAL MODE MESSAGE TO BE COMMANDED BY A MODE 7 TO THE MASTER.

LISTEN ID : WHEN THE MODE 7 IS SENT TO THE MASTER, THE MASTER TRANSMITS THE REQUESTED NORMAL MODE MESSAGE WHICH MAY OR MAY NOT CAUSE A
RESPONSE MESSAGE TO BE GENERATED BY ANOTHER MODULE. IN ORDER TO MAINTAIN PROPER SYNCHRONIZATION WITH TRAFFIC ON THE DATA LINK, THE
LISTEN ID SHOULD BE THAT OF THE RESPONSE MESSAGE IF ONE IS GENERATED OR THE COMMAND ID IF NO RESPONSE IS GENERATED BY THE
NORMAL MODE MESSAGE.

MES LENGTH: IF THE RESPONSE MESSAGE ID IS THE SAME AS THE COMMANDED MESSAGE ID THE MESSAGE LENGTH IS USED TO DIFFERENTIATE THE RESPONSE MESSAGE FROM THE TRANSMIT MESSAGE.

So I guess you would log the bus chatter to find out what normal mode messages are responded to on your car,
then alter the .adx to periodically send a mode 7 frame requesting one of the normal mode messages to keep each device happy, and then listen for the replies before continuing to send mode 1 requests to the PCM.

I'm not sure if you could just send the normal mode message to each device and still satisfy the BCM, but that would save a little bit of time since you dont have to wait for the BCM to then request the message from the other device.

[VL400]

Never tried this but sounds interesting I had wondered what the scan tools did to the bus as generally you get all vehicle functions still working. Data rate must suffer a bit, but depends on how often you need to schedule things.

On the logger I have a passive mode that just uses the 128mS silence after the heartbeat and before the start of the next message block. You only get ~3Hz throughput though as its a 300mS schedule. There is some info here on what the VT bus has .. https://pcmhacking.net/forums/viewtopic.php?f=10&t=724

[charlay86]

Yeah that thread is the one that inspired me to hunt around through the US datastreams to find potentially find a similar one to ours so I could make a better adx for the other bus devices.
The BCM obviously has a few extra messages that it sends to devices not present, so you could ignore them, and then see what the maximum interval that you can get away with before each module gets upset, since when you start logging it takes a little while before the SRS light and the high speed fan etc. come on, so there must be a fair bit of leeway.