When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
I tried using a serial stream capture app while logging, but it seems like it was a port conflist. I have maotes aldl usb setup and can log using tunercat. If I had more understanding of which capture tools will work I would love to be able to mirror the project on a 93 LT1 AT. These ECUs are very basic even comparing to the FSM there are only a dozen or so actual PIDs of interest. How can I capture serial streaming?
It was pretty simple with an Arduino. Arduino only has one UART (hardware required to read a serial datastream), so I used a simple sketch to set up software serial on pins 2 and 3 (software serial uses the CPU to decode the datastream; works just fine at this low baud rate). The sketch prints the serial to the Arduino IDE serial monitor, but that's not a super nice format, so I wrote a short Python script to capture that datastream and write it to file. With these two pieces of code, the process is this:
Upload sketch to Arduino
Unplug Arduino
Run jumper wires from pins 2 and 3 to the proper pins on the ALDL port (think I've specified somewhere above which one goes to which)
Connect the Arduino back to your computer's USB
Run the Python script
When finished, hit Ctrl + C to interrupt the script
View your results in the generated file
Here's the Arduino sketch:
Spoiler
#include <SoftwareSerial.h>
SoftwareSerial softSerial(2, 3); // RX, TX
void setup() {
Serial.begin(115200);
while (!Serial) {
;
}
Serial.println("USB serial initialized.");
softSerial.begin(8192);
softSerial.println("Software serial initialized.");
}
void loop() {
if (softSerial.available())
//Serial.println(softSerial.read(), HEX);
Serial.println(softSerial.read());
}
and the Python script:
Spoiler
from datetime import datetime
import serial
# from matplotlib import pyplot as plt
from pathlib import Path
# Set this path to wherever you want the output file dumped; Path.home() is C:/Users/<username
root = str(Path.home()).replace('\\','/') + '/'
with serial.Serial() as arduino, open(root + fname + '.txt', 'w') as f_out:
arduino.baudrate = 115200
# Might need to find the Arduino in Device Manager to get the right COM port. Think it's probably COM3 or COM4.
arduino.port = 'COM4'
arduino.open()
ser_byte = None
synced = False
# fig, (ax1, ax2) = plt.subplots()
try:
while True:
line = ''
if not synced:
msg_id = find_id_byte(arduino, known_message_ids)
else:
msg_id = read(arduino)
msg_len = read(arduino)
msg = [msg_id, msg_len]
if msg_len < 3 or msg_len > 255:
synced = False
line = 'ERROR: Message length - '
else:
while len(msg) < int(msg_len, 16) - 0x52:
msg.append(read(arduino))
checksum = sum([int(byte, 16) for byte in msg]) % 0x100
if checksum != 0:
synced = False
line = 'ERROR: Checksum - '
The one tricky part is that you need to know at least one valid message ID so that the script can sync itself to the datastream. I currently have known_message_ids populated with values I've found from my car, but I'm not sure if these will apply to yours. You might just set the list equal to ['F0'] and see if that gets you data without a bunch of message length/checksum errors.
I plan to polish this script up and make it plot the data real-time, but it will be awhile before I can get to that.
Originally Posted by Bill Chase
How is the science experiment going?
I've mostly parked this as I've been figuring out details for the standalone. Today I might see if I can finish the real-time plotting code and hook the Arduino back up. I just need to figure out a way to keep the leads stuffed into the ALDL port. That's honestly been the most frustrating part about this whole project.
I realized I messed up when I tweaked the ADX to read running total fuel. Here's a plot with it corrected. If this were truly a running total of fuel, you'd expect it to relate to the integral of RPM and injector BPW. That is, more injection events per second increases fuel consumption, as does a larger pulsewidth for a given injection frequency. I added this quantity (scaled so the slope matches and offset vertically so they're not stacked on top of each other) to the plot, and it closely follows the running total fuel consumption.
Again, it seems odd that the ECM would be calculating this value if it's not used in MPG calculations, and the fact that the datastream calls it "IPFUEL" makes me think it would be used for the instrument panel fuel display. That said, I don't see anything like this in the usual serial datastream, so I guess it's a moot point.
I've mostly parked this as I've been figuring out details for the standalone. Today I might see if I can finish the real-time plotting code and hook the Arduino back up. I just need to figure out a way to keep the leads stuffed into the ALDL port. That's honestly been the most frustrating part about this whole project.
There's no reason to give bad-faith replies the time of day.
There's no reason to give bad-faith replies the time of day.
Eh, figured I'd give him the benefit of the doubt. Maybe he's really just curious.
While trying to think through what the $41 bytes each are, I remembered the ECM has a calibration value for VSS pulses per mile. It would make sense that it sends this to the CCM like it does the injector flow rate ($41 byte 11), but none of the bytes fit. Byte 13 is constant over my log, but its value is 1, whereas the VSS PPM is 0xE6 in the tune. Byte 4 is also constant, but its value is 0, which doesn't make sense either.
I previously noticed the similarity between $10 B5 (which is known to be speed) and $41 B12. It almost looks like $41 B12 is an unfiltered version of $10 B5. I don't see why the CCM would have a VSS input if it gets speed from the ECM, but there are three options here:
The ECM sends the CCM the calibration value. This would make the most sense, but it does not seem to be the case. I guess it's possible the ECM sends this value just one time on startup or something, but that would not match its behavior with the injector scalar.
The ECM sends the CCM the calculated vehicle speed. In this case, the CCM VSS input would be useless?
The calibration value does nothing. I can test this by changing the calibration value and seeing how $41 B12 responds.
I've still got a lot of bytes to decode: 3-10, 12, and 13. I'm going to try to make a systematic testing plan to figure them out.
Eh, figured I'd give him the benefit of the doubt. Maybe he's really just curious.
While trying to think through what the $41 bytes each are, I remembered the ECM has a calibration value for VSS pulses per mile. It would make sense that it sends this to the CCM like it does the injector flow rate ($41 byte 11), but none of the bytes fit. Byte 13 is constant over my log, but its value is 1, whereas the VSS PPM is 0xE6 in the tune. Byte 4 is also constant, but its value is 0, which doesn't make sense either.
I previously noticed the similarity between $10 B5 (which is known to be speed) and $41 B12. It almost looks like $41 B12 is an unfiltered version of $10 B5. I don't see why the CCM would have a VSS input if it gets speed from the ECM, but there are three options here:
The ECM sends the CCM the calibration value. This would make the most sense, but it does not seem to be the case. I guess it's possible the ECM sends this value just one time on startup or something, but that would not match its behavior with the injector scalar.
The ECM sends the CCM the calculated vehicle speed. In this case, the CCM VSS input would be useless?
The calibration value does nothing. I can test this by changing the calibration value and seeing how $41 B12 responds.
I've still got a lot of bytes to decode: 3-10, 12, and 13. I'm going to try to make a systematic testing plan to figure them out.
You should be checking your FSM. If you check the Electrical Diagnostic section for the VSS (8A-33 for my 94-95), you'll see that the raw VSS signal goes to the ECM/PCM, the ECM/PCM then operates on it to create a uniform 4000 PPM output signal, and it's that output signal that's wired to the "VSS" lines on the CCM, cruise control module, and radio control head (for speed-compensated volume control).
Right you are. Somehow I missed that on my previous read-through, but the VSS raw output goes to the ECM, which then passes a 4k PPM signal to the CCM and a couple other systems.
I wonder why the $10 message has a filtered speed output, while $41 has unfiltered. I'm still not quite sure how/why the $10 and $41 messages are different. They both appear to be broadcast data from the ECM, so I don't see why they would need to be separate messages.
Last edited by C4ProjectCar; Mar 17, 2021 at 12:41 PM.
Right you are. Somehow I missed that on my previous read-through, but the VSS raw output goes to the ECM, which then passes a 4k PPM signal to the CCM and a couple other systems.
I wonder why the $10 message has a filtered speed output, while $41 has unfiltered. I'm still not quite sure how/why the $10 and $41 messages are different. They both appear to be broadcast data from the ECM, so I don't see why they would need to be separate messages.
If I were to float a theory, I'd say it's in the name of the connector itself--Assembly Line Diagnostic Link. It may not be particularly useful to one of us, but it could be useful for the people who were building and testing them originally.
