Corvette CCM Reverse Engineering Anyone?

[spfautsch]

So why would something creating an additional, not-accounted-for delay require increasing the existing delay? That's the only thing I'm confused about.

Not the existing delay - with the ALDL and debugging being echoed to the serial console as well as capturing and writing diy-ltcc debugging, I was able to maintain semi-reliable comms with a OCR3A value as low as 18 (1.152ms). I worked up to the current 28 / 1.78ms after a good bit of trial and error.

That said I'm using 2ms already in my own code so, hey, close enough.

I was only sharing the timer code in case you wanted to be able to do something else in those 2ms. Your application can probably live without it. Mine needs to service the diy-ltcc logging on uart2 as well as writing to the sd card over spi.

It would be interesting to see if using your timer ISR set to 1 tick would be sufficient when the code isn't doing anything else during transmission. Though as another note, even though their waveform diagram shows 20 microseconds, and their SXR (discrete IC) shows 20 microseconds, the diagram using a non-SXR circuit specifies a minimum of 108.1 microseconds and a maximum of 147.1 microseconds. It's not explained in the text where this discrepancy is coming from.

I can experiment, but I think there may be additional unpublished timing requirements for the protocol - this is definitely not just a matter of the electrical characteristics of the bus. Even with > 2.0ms transmit delay I'm still seeing intermittent reply message "lethargy" for lack of a better term. In what testing I've been able to do I've seen the PCM message timeout (at the time ~200ms) exceeded immediately after going into closed loop - the last message in the log is literally the only one with the BLM Learn bit set. I'm not sure I haven't formatted the SD and lost this one, but I'm sure it happened.

I'll keep posting updates since it seems to be valuable info for you. Yesterday was mostly spent moving stuff to and setting up my storage unit. I did manage to add debug logging of the logger itself to a file, as well as timezone rules and a callback to the RTC so file timestamps are correct. Hopefully today will be more productive on the timing and reliability side.

I mistakenly ordered the wrong solid state relay, waiting for the correct one from DigiKey so the power-on latch circuit can be completed and system will be ready for final debugging. The idea is to power the logger on from the courtesy lamp circuit as well as the switched ignition, and then let the arduino hold the same relay on with a digital pin and then shut itself off after it sees that the CCM has gone to sleep. This satisfies my other need which is feedback that the CCM has shut the hell up after a drive cycle instead of sitting and draining my battery.

[NomakeWan]

Oh, no no, don't take my reply the wrong way; I was in no way being critical of your code or suggesting that my method was better or anything like that. I was just noticing that I had a larger delay than your code already, so we were pretty close to one another in terms of the existing "settle" delay. Nothing more, nothing less.

Anyway it definitely sounds like I need to buy myself a 'scope in 2022. It's really getting to the point where I can't go much further in researching these sorts of old cars without one. I'm working on another unrelated project for the GT-R related to solenoid feedback that is also going to need a 'scope anyway, so yeah, I'm way overdue. Hopefully that'll both help try to figure out what's going on with 8192 ALDL, and maybe even what's so different about the '94 Vette's "dirty" bus versus my '95s "clean" one. More than worth it.

As for your latching relay thing, I was thinking of handling it without one. I mean with a latching relay you can go to completely 0 power draw, I agree, but the power draw of an Arduino-based chip in full sleep is what, 10 microamps or something? Why not just set an interrupt for the RX pin going from low to high to wake it, and have the Arduino just go into full smash sleep mode after a certain time of the CCM dropping offline?

[spfautsch]

Oh, no no, don't take my reply the wrong way; I was in no way being critical of your code

Not taken that way at all. Just making sure we're on the same page. I wanted to push the timing envelope while servicing other devices in the main loop and that required a hardware timer.

As for your latching relay thing, I was thinking of handling it without one. I mean with a latching relay you can go to completely 0 power draw, I agree, but the power draw of an Arduino-based chip in full sleep is what, 10 microamps or something? Why not just set an interrupt for the RX pin going from low to high to wake it

Tried that and it does work. But the SD card in particular, the miscellaneous smc leds and the dual voltage regulators on the mega board draw a lot - 75ma in idle mode according to my best meter with all but uart1 (ALDL) turned off. Not worth designing my own board so I'll just flip the breaker after the CCM goes to sleep. It adds some code and component complexity but the last thing I need is to trade convenience for more parasitic draw on the battery.

As always life happened today so didn't make as much progress as I'd hoped to. Still need to resolve an occasional CCM timeout after killing the ignition (and power to the PCM).

[NomakeWan]

Have you tried shutting down all the ADC registers before dropping into sleep? Apparently just using

ADCSRA = 0;

reduces power consumption by three orders of magnitude. It'd be like Sketch J here: http://www.gammon.com.au/power

Apparently that sketch on a bog standard Arduino draws only 0.15 microamps while sleeping, which is two orders of magnitude less than I thought. Should work on the Mega.

[spfautsch]

Nick's examples were done using a 328p on a custom board without voltage regulators, leds, peripherals, etc.

The mega boards have two voltage regulators, one of which I believe is linear and therefor very inefficient. According to this [link] the lowest power consumption it's capable of while using the on-board regulators is ~27 ma. That's with the adc turned off and processor in PWR_SAVE mode. Meh. Add on the logger shield and sd card and it uses even more power.

Was able to clean up a few issues and it looks like latching relay will work as planned with the possible exception of key in + key on after the CCM has gone to sleep. But I don't generally sit in the car with the door closed without the key in the ignition.

[NomakeWan]

Ah, fair enough. Guess it's yet another thing for me to experiment with on my own. I enjoy that though so, hey!

It took me a second to figure out why "key-in+key-on after CCM sleeps" would be a problem, then I remembered that the logger was being triggered from the courtesy lights. Considering the use case for this device, I highly doubt that will be an issue. An errata to make sure to spell out in documentation, sure, but I think anyone who would have one of these left plugged in is going to get in and out of their car for drive cycles.

[spfautsch]

SSRs showed up a few days ago and I have the completed system ready to go in the car. The "joys" of x-mas shopping with the wife took up today but I hope to get on it tomorrow.

What is this "documentation" you speak of? ;-).