FS: VR - VY BCM Simulator
-
- Posts: 471
- Joined: Thu May 03, 2012 10:50 pm
- cars: HZ One Tonner
VE Ute - Location: Castlemaine, Vic
Re: FS: VR - VY BCM Simulator
So you want to be able to independently swap the cluster to the LPG fuel sender/dist to empty, while keeping the PCM on petrol? (Or keep the PCM on LPG but make the cluster use petrol sender)
Re: FS: VR - VY BCM Simulator
Something like that. With aftermarket LPG the system uses the standard petrol maps and injector drivers to drive the LPG injectors.
So the PCM always thinks it is delivering petrol. The aftermarket ECU manages the injection length to manage the LPG fuel injection close to the PCM petrol map.
The factory LPG is carburetted so the PCM turns off the injectors, turns on the tank and swaps the dash to LPG. ect. It also tells the dash to swap fuel senders ect. In the factory tank the sender is closely calibrated to the petrol sender. There is also a map in the dash for the LPG 0,1/4,12/3/4, and full just like petrol. The problem with the factory system is it is very restrictive and decreases the engine power output considerably.
I looked at trying to disassemble the pcm code and find the relevant bits, but its not that easy with a 128K bin. Particularly the reassembly.
Thats when I stumbled across your device and thought that might be a potential option.
So I was thinking, If I can intercept the PCM message, change the code dependent on an input which would be linked to using LPG I could get back the functionality of the dash, which is way better than the 3 leds you get on the aftermarket system to indicate level.
I'm happy to do most of the work, Just hoping for some pointers in the right direction with circuit diagrams and code ect.,
So the PCM always thinks it is delivering petrol. The aftermarket ECU manages the injection length to manage the LPG fuel injection close to the PCM petrol map.
The factory LPG is carburetted so the PCM turns off the injectors, turns on the tank and swaps the dash to LPG. ect. It also tells the dash to swap fuel senders ect. In the factory tank the sender is closely calibrated to the petrol sender. There is also a map in the dash for the LPG 0,1/4,12/3/4, and full just like petrol. The problem with the factory system is it is very restrictive and decreases the engine power output considerably.
I looked at trying to disassemble the pcm code and find the relevant bits, but its not that easy with a 128K bin. Particularly the reassembly.
Thats when I stumbled across your device and thought that might be a potential option.
So I was thinking, If I can intercept the PCM message, change the code dependent on an input which would be linked to using LPG I could get back the functionality of the dash, which is way better than the 3 leds you get on the aftermarket system to indicate level.
I'm happy to do most of the work, Just hoping for some pointers in the right direction with circuit diagrams and code ect.,
-
- Posts: 471
- Joined: Thu May 03, 2012 10:50 pm
- cars: HZ One Tonner
VE Ute - Location: Castlemaine, Vic
Re: FS: VR - VY BCM Simulator
When I get a chance I'll post up some more info that should help you
-
- Posts: 471
- Joined: Thu May 03, 2012 10:50 pm
- cars: HZ One Tonner
VE Ute - Location: Castlemaine, Vic
Re: FS: VR - VY BCM Simulator
Heres an ALDL read function. Credit goes to VL400 for this.
Heres how to use it in the main program loop:
Code: Select all
#define ALDL_BUFFER_SIZE 170 //255-0x55 => 255-85 => 170 max frame length
#define ALDL_BASE_LENGTH 0x55 //base size for message length (2nd byte)
HardwareSerial &ALDLserial = Serial1;
byte bufferRX[ALDL_BUFFER_SIZE];
unsigned long _lastActivity; //last ALDL bus activity (for detecting bus silence etc)
boolean ALDL_read() {
static int RXchecksum = 0;
static byte ByteCount = 0;
static byte PayloadCount = 0;
static boolean ChecksumOnly = false;
if ((millis() - _lastActivity) > 100) { //If there have been no bytes received for 100ms, assume no receive activity and reset. Helps bus sync
ByteCount = 0;
}
while (ALDLserial.available() > 0) {
_lastActivity = millis();
byte inByte = ALDLserial.read();
if (ByteCount == 0) { //Device ID byte
bufferRX[ByteCount] = inByte;
RXchecksum = inByte;
ByteCount = 1;
ChecksumOnly = false;
} else if (ByteCount == 1) { //Packet length byte
if (inByte < ALDL_BASE_LENGTH) { //invalid byte, packet length byte below minimum
ByteCount = 0;
return false;
} else if (inByte > (ALDL_BASE_LENGTH + ALDL_BUFFER_SIZE - 1)) { //packet will be too big for our buffer
ChecksumOnly = true;
}
bufferRX[ByteCount] = inByte;
RXchecksum = RXchecksum + inByte;
PayloadCount = inByte - (ALDL_BASE_LENGTH - 1);
ByteCount++;
} else if (ByteCount > 1) {
bufferRX[ByteCount] = inByte;
RXchecksum = RXchecksum + inByte;
PayloadCount--;
if (ChecksumOnly == false) {
ByteCount++; //will just write to same byte over and over if its too big for our buffer
}
if (PayloadCount == 0) { //upto checksum
if (byte(RXchecksum) == 0) { //Valid checksum
ByteCount = 0;
if (ChecksumOnly == false) {
return true;
}
} else {
//checksum was bad
ByteCount = 0;
}
}
}
}
return false;
}
Code: Select all
if (ALDLserial.available()) {
if (ALDL_read()) {
ALDL_process(); //Process a received ALDL frame with your function here
}
}
-
- Posts: 471
- Joined: Thu May 03, 2012 10:50 pm
- cars: HZ One Tonner
VE Ute - Location: Castlemaine, Vic
Re: FS: VR - VY BCM Simulator
Heres a send function
To use it basically load up a frame in bufferTX, you don't have to worry about calculating and adding the checksum, then call the function with CSpos where the checksum should go. If it returns true it sent, if false it didn't send.
It could be made even simpler. You could remove the option to send without adding checksum and have a hard coded amount of silence before sending. You could have it calculate the checksum position from the 2nd byte (message length) in the buffer so you don't have to specify it each time you call the function.
Code: Select all
byte bufferTX[ALDL_BUFFER_SIZE];
boolean ALDLactive = true; //this can be set to false to prevent sending frames (I use it when something has requested BCM silence on my BCM simulator)
boolean ALDL_send(byte CSpos, boolean CSskip = false, byte waitTime = 3) {
//send data in TX buffer. returns true if sent, false if send failed.
//CSpos = Checksum position in the buffer (frame length)
//CSskip = Normally checksum is calculated and added automatically, if this is true that wont be the case
//waitTime = how many milliseconds of bus inactivity before we should start sending
byte checksum = 0;
if (CSpos < 2 or CSpos > ALDL_BUFFER_SIZE) {
//Invalid packet length
return false;
}
for (byte i = 0; i < CSpos; i++) {
checksum += bufferTX[i];
}
checksum = 0x100 - (byte(checksum) % 0xFF);
if (CSskip) { //don't add the checksum
if (checksum != bufferTX[CSpos]) {
//The calculated checksum doesn't match what is already in the buffer (checksum is invalid - you would be sending an invalid frame)
}
} else { //add the checksum
bufferTX[CSpos] = checksum;
}
if (ALDLactive) {
while ((_lastActivity + waitTime) > millis()) { //wait for our period of inactivity (default 3ms since last frame)
if (ALDLserial.available()) {
//something else has started transmitting. At this stage you have to let it go back to the main loop and read new frame before trying again
return false;
}
}
ALDLserial.write(bufferTX, (CSpos + 1));
ALDLserial.flush(); //wait until sent
_lastActivity = millis();
return true;
} else {
//Transmitting is disabled
}
return false;
}
It could be made even simpler. You could remove the option to send without adding checksum and have a hard coded amount of silence before sending. You could have it calculate the checksum position from the 2nd byte (message length) in the buffer so you don't have to specify it each time you call the function.
-
- Posts: 471
- Joined: Thu May 03, 2012 10:50 pm
- cars: HZ One Tonner
VE Ute - Location: Castlemaine, Vic
Re: FS: VR - VY BCM Simulator
Heres the UART-ALDL interface circuit:
https://electronics.stackexchange.com/q ... low-enough
The receive control pin can be set high when you are sending (inside the ALDL_send function) so that you won't get the echo received back. I'm not worried about that so its permanently joined to ground. But that could be useful for you.
You can remove the one transistor, 100 ohm resistor and LED if you don't want an activity LED
I can't find where I originally found it but here's where I found someone who had the same problem as me (and hence the solution):
https://electronics.stackexchange.com/q ... low-enough
The receive control pin can be set high when you are sending (inside the ALDL_send function) so that you won't get the echo received back. I'm not worried about that so its permanently joined to ground. But that could be useful for you.
You can remove the one transistor, 100 ohm resistor and LED if you don't want an activity LED
-
- Posts: 27
- Joined: Mon Sep 09, 2019 9:59 pm
- cars: Commodore VR Series II SS
Commodore VF Series II SSV Redline
Re: FS: VR - VY BCM Simulator
Transistors used in the receive portion of ALDL interface circuits can give unpredictable and sometimes frustrating results, as described by pman92 and the link he referred to.
The transmit portion is usually no problem; an open-collector NPN will always drive the bus reliably by switching fully to ground.
I've used the following comparator-based circuit for many ALDL projects and it has proven absolutely reliable. Both comparators in the 8-pin package are referenced to 2.5V, with positive feedback around the initial stage to provide a degree of hysteresis. The second stage simply maintains polarity of the received bus logic state.
There's no hardware gating to suppress echo, as I deal with this if necessary in my software.
The transmit portion is usually no problem; an open-collector NPN will always drive the bus reliably by switching fully to ground.
I've used the following comparator-based circuit for many ALDL projects and it has proven absolutely reliable. Both comparators in the 8-pin package are referenced to 2.5V, with positive feedback around the initial stage to provide a degree of hysteresis. The second stage simply maintains polarity of the received bus logic state.
There's no hardware gating to suppress echo, as I deal with this if necessary in my software.
- Attachments
-
- ALDL interface.jpg (134.22 KiB) Viewed 21599 times
- hsv08
- Posts: 547
- Joined: Thu May 09, 2013 6:50 pm
- cars: (EX) VT SENATOR 355 STROKER
(EX) VT SS 304 MANUAL
NOW VX V6 HACK
Re: FS: VR - VY BCM Simulator
Ive got a customer with a complete VY SS conversion done into a Chevy Apache truck including dash cluster, running factory BCM, security bcm controlled alarm and windows etc. however needs to get it through compliance.
Will this simulate the ABS module and SRS module data packets if the BCM is still in use? Pretty sure the comms on the UART line to cluster only receives data from the CTS for the temp gauge and and all other comms from SRS and ABS and CE through the UART. could be a possibility of running a standalone alone comms to the cluster if need be?
Will this simulate the ABS module and SRS module data packets if the BCM is still in use? Pretty sure the comms on the UART line to cluster only receives data from the CTS for the temp gauge and and all other comms from SRS and ABS and CE through the UART. could be a possibility of running a standalone alone comms to the cluster if need be?
-
- Posts: 471
- Joined: Thu May 03, 2012 10:50 pm
- cars: HZ One Tonner
VE Ute - Location: Castlemaine, Vic
Re: FS: VR - VY BCM Simulator
No it won't currently work with another BCM on the data bus as it is, HOWEVER I could easily enough make a one off unit that only simulates ABS / SRS modules. You wouldn't have to run a separate data line to the cluster, just connect the module to the existing ALDL line between BCM and Cluster and connect an ignition + and earth.
As you said the cluster only receives coolant temperature, as well as warning light status (Check engine, ABS light, SRS light, PWR/ECON light etc) from the ALDL connection. Everything else is hard wired (speedo, tacho etc).
I'm guessing you just want something to turn off the ABS and SRS warnings on the cluster?
Let me know if your interested and I'll put something together
Cheers
As you said the cluster only receives coolant temperature, as well as warning light status (Check engine, ABS light, SRS light, PWR/ECON light etc) from the ALDL connection. Everything else is hard wired (speedo, tacho etc).
I'm guessing you just want something to turn off the ABS and SRS warnings on the cluster?
Let me know if your interested and I'll put something together
Cheers
- hsv08
- Posts: 547
- Joined: Thu May 09, 2013 6:50 pm
- cars: (EX) VT SENATOR 355 STROKER
(EX) VT SS 304 MANUAL
NOW VX V6 HACK
Re: FS: VR - VY BCM Simulator
Yeah that sounds like it would work. Easy enough to wire into the back of the cluster so that it can still be keeped nice and tidy.pman92 wrote:No it won't currently work with another BCM on the data bus as it is, HOWEVER I could easily enough make a one off unit that only simulates ABS / SRS modules. You wouldn't have to run a separate data line to the cluster, just connect the module to the existing ALDL line between BCM and Cluster and connect an ignition + and earth.
As you said the cluster only receives coolant temperature, as well as warning light status (Check engine, ABS light, SRS light, PWR/ECON light etc) from the ALDL connection. Everything else is hard wired (speedo, tacho etc).
I'm guessing you just want something to turn off the ABS and SRS warnings on the cluster?
Let me know if your interested and I'll put something together
Cheers
There used to be a cluster bin file around for a ute that had no ABS so the cluster never went looking for it, but I cant recall what model it was In. I do alot of custom ecu conversion for guys here in NZ and getting the factory dashes to work in non commodore has come up a few times now.
I'll have a chat with him, however would still like to go ahead.
What's your price if you were to say build 3 units? And time frame?
Thanks mate