That must have been a bin I dumped early on the test bench without a vats resistor, before finding the reman pin.
Probably not an issue though - it will still unlock without vats, though it sounds like the reman pin is disabling vats.
That must have been a bin I dumped early on the test bench without a vats resistor, before finding the reman pin.
Probably not an issue though - it will still unlock without vats, though it sounds like the reman pin is disabling vats.
This would make sense; you wouldn't want VATS getting in the way at a remanufacturing facility, or on the factory floor. VATS is for a car, which a new/reman CCM is not a part of.
I see what you're doing here. Pretty neat. Yes, the issue I had had on the original EEHack idle logs is that while it would display a gap time, there was never any gap time between actual messages (that is, there was never a gap between $10, $40 and $41 messages, only after those messages). This shows the actual gap timing. Whether n is nanoseconds or microseconds, it appears to average around 9. Very neat.
I apologize for not responding yesterday. Another race day meant I was out of commission. But I'm back so today I'll be experimenting more with the Arduino to see what's going on. To clarify again, when I mentioned that "the Arduino transmission doesn't appear on the line," I wasn't referring to plugging the Arduino TX directly in. That kills the line completely, which is a different problem (as steveo points out, the Arduino TX idling high is killing the line entirely). The problem I was having was that when I connected the TX line to the bus using a transistor array (which is a rough emulation of the CMOS open drain buffer setup GM uses), that transmission never appeared on the bus. EEHack recorded all the $10 and $40 messages without issue, so the line was live, but the transmissions never appeared.
I do not recall if I did idle logging with the Arduino connected via a diode. I did test the ultra-basic circuit (4.7k resistor between RX and bus, IN914A resistor between TX and bus with stripe towards TX) and the CCM still wasn't happy, but I do not recall if I actually did an idle log with EEHack while it was in that configuration. I will do just that today.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
You might want to do yourself a favor and just drop a delay(1); between the 40 broadcast receive and the transmit. You can use a timer later if you must, but the micro isn't going to be needing that 1ms.
I'm not sure why the 08 command is being echoed twice, but you can see it sleep for about 4 seconds and then wakes up and starts broadcasting again until the micro sees the F0 query / heartbeat, and then it shuts up for another 4 seconds. Without the delay the CCM ignored the message.Code:F1 56 00 B9 10 59 00 68 02 00 2D 40 57 4D BF 5D 10 59 00 68 02 00 2D 40 57 4D BF 5D 10 59 00 68 02 00 2D 40 57 4D BF 5D 10 59 00 68 02 00 2D 40 57 4D BF 5D 10 59 00 68 02 00 2D 40 57 4D BF 5D 3553 F0 56 F1 C9 F1 56 08 B1 F1 56 08 B1 F1 56 00 B9 10 59 00 68 02 00 2D 40 57 4D BF 5D 10 59 00 68 02 00 2D 40 57 4D BF 5D 10 59 00 68 02 00 2D 40 57 4D BF 5D 10 59 00 68 02 00 2D 40 57 4D BF 5D 10 59 00 68 02 00 2D 40 57 4D BF 5D 9625 F0 56 F1 C9 F1 56 08 B1 F1 56 08 B1 F1 56 00 B9 10 59 00 68 02 00 2D 40 57 4D BF 5D 10 59 00 68 02 00 2D 40 57 4D BF 5D 10 59 00 68 02 00 2D 40 57 4D BF 5D 10 59 00 68 02 00 2D 40 57 4D BF 5D 10 59 00 68 02 00 2D 40 57 4D BF 5D 15697 F0 56 F1 C9 F1 56 08 B1 F1 56 08 B1
I'll post the whole sketch when I have a chance to clean it up some.Code:if (msgfound) { // valid msg rcvd if (msg[0] == 0xF0 && msg[2] == 0xF1) { delay(1); transmit = 1; Serial1.write(silence, sizeof(silence)); Serial.println(millis()); transmit = 0; } printMsg(msg, sizeof(msg)); }
Without the delay before transmit, eehack sees the entire message, but the CCM doesn't reply / respond to it.
Please note if you try this sketch out I set the console baud to 115200 so the transmit buffer is cleared faster,Code:633ms to 645ms (12ms) :: 405700 ::: GAP4ms 649ms to 660ms (11ms) :: 4DBF5D5D ::: GAP132ms 792ms to 804ms (12ms) :: F056F1C9F15608B1 ::: GAP21ms 825ms to 836ms (11ms) :: 1059006802002D
It's because you didn't poison the receive buffer as soon as you matched the appropriate message, if I had to guess. That was the exact problem I made sure to avoid in my code; the Arduino runs so many orders of magnitude faster than the 8192 baud ALDL that it's entirely possible to go through the response code loop multiple times upon receipt of the correct message. So the first thing I do in my code upon matching the message I'm looking for is poison the first byte (oldest byte) of my 5-byte-wide sliding window. This way even if the code loops around again before the end, the contents of my buffer now start with 00, which won't match the checksum, which thus won't allow the code to enter the response loop anymore until the next time a full $40 message is received.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
regarding delay times, an aldl byte is 1.22ms long, so a 1ms delay is less than one byte worth of dead air after you just blocked events for >1.22ms*pkt length, the cost is insignificant
Bookmarks