agreed, I don't think it is ALDL format. I do think it is 8192 UART, but it's own specific formatting. Although it does appear the PCM potentially outputs a 3 byte 'heartbeat' but really I think this is just some sort of handshake and it running the bus as a master. Without the PCM sending these messages, the TAC does nothing. I intend to connect directly to TAC without PCM and send it a few of the PCM messages on a reoccurring bias to see if I can get it to chatter back with me- just for fun.antus wrote:I am not sure about US cars, but in Australia the BCM was the ALDL bus master and sends out a heartbeat every so often. Thats 3 bytes long and every module in the car waits for the heart beat then I believe it has timing hard coded so that all modules in the car transmit one after the other. Then there is a short gap at the end, which is just long enough for a tool to detect 50ms silence, then send a silence chatter to take over the bus. This is for the ecm, bcm, abs, dash etc on the standard bus. Then for SRS, thats on its own bus, and a command is sent to the BCM to bridge the two ALDL busses to make it available for a short time. Being we are talking TAC module here, I would suspect its quite possible that its on its own bus, too. if it really is ALDL it should have ALDL checksums though, I cant see that something important like TAC would have no error detection. I raw dump of all serial traffic would be good, then check the frames by hand to see if the tools can be trusted, or what else is going on.
looking at the raw logs above, I dont think thats ALDL. ALDL is Device ID, Length ($55+length), mode, submode, payload, checksum and none of those look like they fit that format.
This guy was my initial tip off of the 8192 speed of the PCM-> TAC coms-
https://www.fiero.nl/forum/Archives/Arc ... 26679.html
and so far I'm confident the PCM-TAC coms are 8192 baud, but not ALDL format/structure. Maybe this is why the MDI fails to work. If it's preprogrammed for a standard format and we are working with an ad-hoc format here.
If I wanted to pursue a logging tool for this line, I think I can use the short gaps between messages to align the parsing. Evenso, my objective isn't really to understand this communication. Being that the communications aren't true ALDL, I don't think the TAC will ROM dump over the ALDL line, but I can try later on today to send it a few commands and see if I can get an answer.
Does anyone have an idea how to identify the chip on the TAC module? the 80pin...? I posted the numbers found on the chip in a previous post. As far as manufacturer, it just says Japan so I'm really not sure where to start looking to understand what datasheet might be applicable. Would really appreciate some assistances in ID'ing the chip. Thanks!