pcmhacking.net

This is an ALDL data simulator for VR-VY.
I came up with this after experimenting with ALDL on an Arduino. It was originally a BCM simulator only, but has since been revised and can do other things. Big thanks to this forum for a bucket load of information and VL400 who answered quite a few questions I had.

Features are:
- VR-VY VATS simulation, including automatically linking to PCM if required.
- Option to disable VATS with a manual kill switch so engine will not start.
- VS-VY low speed cooling fan relay control output.
- VT-VY oil pressure and engine malfunction warning lamp outputs.
- VT-VY A/C request input (retain the standard pressure transducer and have the PCM control the A/C compressor).
- Allows the use of VT-VY dash cluster (coolant temperature, warning light and fuel consumption data transmission from PCM to cluster).
- ABS/TC and SRS data simulation to prevent dash cluster warning lights.
- VT-VY Traction Control Torque Request PWM signal output, to connect to the PCM, to prevent a "requested torque out of range" DTC.
- VT-VY Low vehicle speed output (< 5km/h), that can be used to trigger anything when the vehicle is stationary (eg. a reverse lockout solenoid).
- PCM data simulation, for when the PCM is replaced with an aftermarket one, to prevent the instrument cluster warnings.
- Support for BCM 'Disable Chatter' commands, so it can be silenced like a real BCM.


It comes in a case 85x55x35mm with 2 mounting tabs.

It comes pre-configured as a BCM simulator that will work with any Delco PCM from VR to VY. If you need to change configuration its done by opening the case and changing dipswitches on the PCB (see the installation instructions).

Printed installation instructions are included, and also attached here as a PDF.

$199 which includes postage Australia wide

nice one!

so it runs on an arduino ?

It runs an Atmega328 (same microprocessor as an arduinp uno) on a dedicated PCB I had made for the purpose.
The development was initially done on an arduino and then on an atmega328 on a breadboard/bench setup I made.
The code itself was written in the Arduino IDE

Love it, this will be great for some of the conversions being done out there

I've made another improvement and updated the first post.

It will now simulate SRS/ABS/ECC messages so the warning lights do not illuminate and DTC's do not log if using a dash cluster.
This is currently hard coded, but once more PCB's arrive, future versions will have 2 removable jumpers to disable SRS and disable ABS/ECC. (So you can use it with a SRS, ABS or ECC module fitted)

Also had a question about how the VATS linking works:
At Ignition on it waits a short time for a VR or VS PCM to send it's VATS message. If none is received, it sends a VT-VY message 40 (PCM data request). If there's no response, it goes back to waiting for a VR/VS PCM for a short time. If a VT-VY PCM is connected, it will respond.
If it's the first use, the PCM won't be linked to the BCM simulator. The BCM simulator will see this in the message 41/pcm response data. The BCM simulator will then unlock the PCM and link to it automatically. Once linked it will resend a message 40 and should get a message 41 response with VATS OK, if not it will retry the link. This whole process takes less than a second and only happens at first use, after that VATS will pass instantly. It will redo it every time it finds the link is broken (a different PCM was fitted), so it isn't "locked" to only 1 PCM ever and can be reused indefinitely.
Once the BCM simulator sees VATS is OK it will start the BCM data simulations (heartbeat, all module requests, etc).

It only simulates VT-VY BCM data if connected to a VT-VY PCM. If it finds a VR/VS PCM it will stay quiet (only do VS low speed fan).

Nice bit of Kit, Tel me could you program it to sit between the PCM and the BCM and have it repeat the codes sent by the PCM but change slightly bases on an input.
eg when the BCM request information from the PCM your device sits between the BCM and PCU and requests the information from the PCM and repeats it as received ,or changes it slightly if a input is on?

That's absolutely possible but not just a matter of reprogramming it.
Firstly you would need to isolate the PCM and BCM/rest of car into 2 seperate ALDL lines. That means a seperate diagnostic connector for PCM and rest of car if you still want to be able to scan them all. That's easy enough.
Next you would need different hardware. This BCM simulator only has 1 ALDL to UART converter circuit on the PCB. Adding another would be do-able but it's probably easier to design a new PCB for the application. You could keep the same microprocessor but it only has a single hardware UART so you would have to implement the second in software (easily do-able at ALDL speeds).
3rd issue would be timing. It may not be an issue at all. You would have to respond to the BCM as soon as it requests, you can't wait to receive the full BCM request, then send it to PCM on the other bus, then receive PCM response, then send it to back to BCM on the first bus. You would have to store the previous response, and send it when the BCM makes the next request (while your also requesting PCM for its next one). So everything would be a fraction of a second outdated (Probably wouldn't be an issue)

pman92 wrote:That's absolutely possible but not just a matter of reprogramming it.
Firstly you would need to isolate the PCM and BCM/rest of car into 2 seperate ALDL lines. That means a separate diagnostic connector for PCM and rest of car if you still want to be able to scan them all. That's easy enough.
Next you would need different hardware. This BCM simulator only has 1 ALDL to UART converter circuit on the PCB. Adding another would be do-able but it's probably easier to design a new PCB for the application. You could keep the same microprocessor but it only has a single hardware UART so you would have to implement the second in software (easily do-able at ALDL speeds).
3rd issue would be timing. It may not be an issue at all. You would have to respond to the BCM as soon as it requests, you can't wait to receive the full BCM request, then send it to PCM on the other bus, then receive PCM response, then send it to back to BCM on the first bus. You would have to store the previous response, and send it when the BCM makes the next request (while your also requesting PCM for its next one). So everything would be a fraction of a second outdated (Probably wouldn't be an issue)

Yup can do the first bit.
The speed issue I dont think would be a problem because as I understand it the transactions all have to happen within 200mSec. That means information would be potentially 200 msec behind, which in the real world is nothing.
I know nothing about Arduino but i assume if it is a modern processor its processing speed should be in the Mhz, therefore it should be able to poll the pcm and respond to the PCM in under 200 msec. eg poll the PCM every 100msec to have the latest data. I might be showing my ignorance here though.
If you are interested in suggesting hardware and potential software code I would be interested in having a go. However bare in mind though I have never played with Arduino so it might be a long process.
I do work in industrial automation so I do understand the basics around comes ect.

The timing wouldn't be a big issue. I would just use the previous PCM response to the next BCM request so everything would be about 200ms behind (which as you say is nothing). The timing issue is more about the time frame you have to respond to the BCM message. The BCM schedules the bus is the same loop continuously. There is only a specific window of time after the BCM says "PCM send your data" for the PCM to actually send that data. You wouldn't have time to go and request the PCM data again, and then repeat it in that window.

An Arduino would definitely be a good way to do something like this.

There probably isn't much real use for it though. The dash cluster only uses it for coolant temperature, warning lights and fuel usage (L/100km etc). Everything else (speedo, tacho etc) are hard wired.

I have a specific use. in the dual fuel cars the PCM sends
41, 68, 12, 0, 0, 0, 33, 33, 0, 0, 70, F0, 15, 0, 0, 11, 0, 0, 0, 0, 0, 59 to the dash for petrol and
41, 68, 12, 0, 0, 0, 33, 33, 0, 0, 70, F0, 15, 0, 0, 10, 0, 0, 0, 0, 0, 5A for LPG. Note the 16th set of numbers change from 10 to 11. This swaps from the petrol sender to the LPG sender and calculates the fuel use and dist to go separately from petrol.
So I am trying to mimic this behavior.