PicoTAC - using GM TAC module with Raspberry PI
Posted: Tue Nov 21, 2023 9:55 am
I've been doing a study on the GM TAC module with the hopes of using the TAC hardware in a standalone DBW application (1965 Corvair if you're interested...). The TAC is very affordable, very reliable and fully redundant. Why not?
Below is a summary of the ALDL message sent between PCM and TAC. At this point I have a raspberry PI Pico prototype that replaces the PCM and unlocks TAC functionality in my Corvair, including cruise control! I'm pretty psyched
If any is interested in this project let me know!
Request Message Format
byte 0 byte 1 byte 2
7 0 7 0 7 0
------------------------------------
|000abcdd|dddddddd|eeeeeeee|
------------------------------------
a: read variable operation, value 'e' will also be set
b: toggle bit, switches between 0 and 1 for each message (sync check?)
c: initialization request, set to 1 until 12 correct responses have been received
d: PCM calculated throttle position, 10 bit integer
e: variable address for read operation.
Startup sequence is to apply power to both PCM and TAC simultaneously. PCM will start sending messages (with bit 'c' set) until it receives 12 correct responses. Then after 12 exchanges with bit 'c' off, there will be four variable read requests. Suspect these are cruise control tuning variables specific to vehicle (weight, hp, wind resistance), but not possible to verify. Once init is complete, TAC begins to position throttle body per PCM request.
Response Message Format
byte 0 byte 1 byte 2 byte 3 byte 4 byte 5
7 0 7 0 7 0 7 0 7 0 7 0
---------------------------------------------------------------
|100ab0cc|cccccccc|dddddddd|eeeeeeee|00fghijj|jjjjjjjj|
---------------------------------------------------------------
a: read variable, follows bit in request message
b: toggle bit, follows bit in request message
c: actual pedal position sensor, 10 bit integer
d: error code if any (e.g. sensor 2 low)
e: variable value for read operation
f: cruise resume button
g: cruise set button
h: cruise on/off button
i: brake lights on
j: actual throttle position sensor
There were some interesting surprises along the way, as usual with a project of this type. Some interesting things about the TAC I've listed below.
1) Single wire uart interface confused me for a while! Two wires for uart interface means to me rx and tx. Live and learn...
2) The sensor reference voltages on the TAC connectors are driven by GPIO pins! These pins can only drive a single ttl load, so about 1.6ma. I expected them to be wired to +5...
3) TAC onboard 5v power regulator only puts out 180ma! Not much headroom here for adding circuitry!
4) TAC makes no decisions about throttle position, just validates connected sensors (pedal, throttle body, cruise inputs) and passes values to PCM.
5) TAC does not implement any cruise functionality. The PI implementation uses a PID (Proportional, Integral, Derivative) model for cruise.
6) Shortly after unit pcm requests 4 variables encoded in rom, possibly cruise control tuning parameters for different vehicles weight hp rolling resistance…
7) No flash memory in device, cpu 6430338f uses masked rom. TAC is a TAC is a TAC...
Below is a summary of the ALDL message sent between PCM and TAC. At this point I have a raspberry PI Pico prototype that replaces the PCM and unlocks TAC functionality in my Corvair, including cruise control! I'm pretty psyched
If any is interested in this project let me know!Request Message Format
byte 0 byte 1 byte 2
7 0 7 0 7 0
------------------------------------
|000abcdd|dddddddd|eeeeeeee|
------------------------------------
a: read variable operation, value 'e' will also be set
b: toggle bit, switches between 0 and 1 for each message (sync check?)
c: initialization request, set to 1 until 12 correct responses have been received
d: PCM calculated throttle position, 10 bit integer
e: variable address for read operation.
Startup sequence is to apply power to both PCM and TAC simultaneously. PCM will start sending messages (with bit 'c' set) until it receives 12 correct responses. Then after 12 exchanges with bit 'c' off, there will be four variable read requests. Suspect these are cruise control tuning variables specific to vehicle (weight, hp, wind resistance), but not possible to verify. Once init is complete, TAC begins to position throttle body per PCM request.
Response Message Format
byte 0 byte 1 byte 2 byte 3 byte 4 byte 5
7 0 7 0 7 0 7 0 7 0 7 0
---------------------------------------------------------------
|100ab0cc|cccccccc|dddddddd|eeeeeeee|00fghijj|jjjjjjjj|
---------------------------------------------------------------
a: read variable, follows bit in request message
b: toggle bit, follows bit in request message
c: actual pedal position sensor, 10 bit integer
d: error code if any (e.g. sensor 2 low)
e: variable value for read operation
f: cruise resume button
g: cruise set button
h: cruise on/off button
i: brake lights on
j: actual throttle position sensor
There were some interesting surprises along the way, as usual with a project of this type. Some interesting things about the TAC I've listed below.
1) Single wire uart interface confused me for a while! Two wires for uart interface means to me rx and tx. Live and learn...
2) The sensor reference voltages on the TAC connectors are driven by GPIO pins! These pins can only drive a single ttl load, so about 1.6ma. I expected them to be wired to +5...
3) TAC onboard 5v power regulator only puts out 180ma! Not much headroom here for adding circuitry!
4) TAC makes no decisions about throttle position, just validates connected sensors (pedal, throttle body, cruise inputs) and passes values to PCM.
5) TAC does not implement any cruise functionality. The PI implementation uses a PID (Proportional, Integral, Derivative) model for cruise.
6) Shortly after unit pcm requests 4 variables encoded in rom, possibly cruise control tuning parameters for different vehicles weight hp rolling resistance…
7) No flash memory in device, cpu 6430338f uses masked rom. TAC is a TAC is a TAC...