Right off the bat, I'm assuming this one might make some folks uneasy, as anything to do with Accelerator Pedal manipulation by it's vary nature could result in unintended acceleration. I'm well aware of various techniques for protecting against those situations and plan to implement them before testing with an actual vehicle.
With that out of the way, I'd like to run the general idea by the group here and see what the thoughts are, along with how I might transfer this from prototype, to a small volume "production" solution.
In this particular application we are swapping an Engine and it's PCM into a different manufacturers vehicle, but we are keeping the stock Transmission and TCM that are already in this particular vehicle.
Currently the folks that do this will add the accelerator pedal from the swapped engine, and mechanically link it to the pedal from the stock vehicle. This is needed as the stock vehicle TCM needs an engine torque to manage the shift points, and it will fall back to the pedal value in the event of other engine sensors failing. (In this case, since the stock engine is no longer there, all it has is the pedal info to fall back on, along with engine speed and wheel speed.) It's also needed as the voltages outputted by the two pedals are different. So the swapped PCM needs to see different voltages than stock TCM needs.
Additionally, the folks that do this swap currently need to lift off the pedal when a shift is going to occur at high load so as to not destroy the transmission. In the OEM configuration the TCM sends a torque reduction command over CAN to the PCM.
For now I am looking to read in the stock vehicle throttle pedal voltages and convert them to the voltage slopes required by the swapped PCM. Just a simple read in via two ADCs, and output to two DACs. Just as in the OEM configuration I plan to keep separate 5V references and plan to have the DAC outputs be ratiometric with the individual 5V references (hence the 2 separate DAC cores required).
I also plan to use one of the CAN channels to read in the torque reduction request from the TCM and momentarily chop the throttle by a specific amount. This will require some tuning of course to get it right, and there's TONs of variables here to manage, but I believe I can get a quick and dirty solution that will allow the driver to keep their foot planted and not have the trans blow up.
Ideally I'd like to figure out the torque reduction request interface of the swapped PCM and just handle it that way. I'd use a second CAN channel for that.
So, all of that being said, I've landed on a T4.0 as my development platform. Looking forward to if I get this working as I intend and want to spin a single board in a nice automotive grade sealed enclosure, I like the idea of using the MKL02 bootloader IC. However, I have slight worries around these parts not being "automotive" grade parts. I'm aware of how to protect the I/O and power from the harsh automotive electrical environment, but as far as part "ratings" themselves, I'm not 100% sure how critical it will be in this case. This controller could very likely be located in the cab, so as not to be exposed to the wide temperature swings of the engine bay.
Am I worrying too much there, or should I start with a different platform that I will easily be able to port code to automotive grade parts?
Thanks,
Austin
With that out of the way, I'd like to run the general idea by the group here and see what the thoughts are, along with how I might transfer this from prototype, to a small volume "production" solution.
In this particular application we are swapping an Engine and it's PCM into a different manufacturers vehicle, but we are keeping the stock Transmission and TCM that are already in this particular vehicle.
Currently the folks that do this will add the accelerator pedal from the swapped engine, and mechanically link it to the pedal from the stock vehicle. This is needed as the stock vehicle TCM needs an engine torque to manage the shift points, and it will fall back to the pedal value in the event of other engine sensors failing. (In this case, since the stock engine is no longer there, all it has is the pedal info to fall back on, along with engine speed and wheel speed.) It's also needed as the voltages outputted by the two pedals are different. So the swapped PCM needs to see different voltages than stock TCM needs.
Additionally, the folks that do this swap currently need to lift off the pedal when a shift is going to occur at high load so as to not destroy the transmission. In the OEM configuration the TCM sends a torque reduction command over CAN to the PCM.
For now I am looking to read in the stock vehicle throttle pedal voltages and convert them to the voltage slopes required by the swapped PCM. Just a simple read in via two ADCs, and output to two DACs. Just as in the OEM configuration I plan to keep separate 5V references and plan to have the DAC outputs be ratiometric with the individual 5V references (hence the 2 separate DAC cores required).
I also plan to use one of the CAN channels to read in the torque reduction request from the TCM and momentarily chop the throttle by a specific amount. This will require some tuning of course to get it right, and there's TONs of variables here to manage, but I believe I can get a quick and dirty solution that will allow the driver to keep their foot planted and not have the trans blow up.
Ideally I'd like to figure out the torque reduction request interface of the swapped PCM and just handle it that way. I'd use a second CAN channel for that.
So, all of that being said, I've landed on a T4.0 as my development platform. Looking forward to if I get this working as I intend and want to spin a single board in a nice automotive grade sealed enclosure, I like the idea of using the MKL02 bootloader IC. However, I have slight worries around these parts not being "automotive" grade parts. I'm aware of how to protect the I/O and power from the harsh automotive electrical environment, but as far as part "ratings" themselves, I'm not 100% sure how critical it will be in this case. This controller could very likely be located in the cab, so as not to be exposed to the wide temperature swings of the engine bay.
Am I worrying too much there, or should I start with a different platform that I will easily be able to port code to automotive grade parts?
Thanks,
Austin